Passer au contenu principal
Version 2.x du chartCette page documente le chart Helm v2.x basé sur des sous-charts. Si vous utilisez encore le chart v1.x à modèles intégrés, consultez Helm cloud deployments (v1.x). Pour les étapes de migration, consultez le guide de mise à niveau.
Ce guide présente les configurations spécifiques au Cloud pour déployer ClickStack sur des services Kubernetes managés. Pour l’installation de base, consultez le guide principal de déploiement avec Helm.

​
Google Kubernetes Engine (GKE)

Lors d’un déploiement sur GKE, il peut être nécessaire de surcharger certaines valeurs en raison d’un comportement réseau spécifique au cloud.

​
Problème de résolution DNS du LoadBalancer

Le service LoadBalancer de GKE peut provoquer des problèmes internes de résolution DNS, où la communication entre pods est résolue vers des IP externes au lieu de rester dans le réseau du cluster. Cela affecte en particulier la connexion du OTel collector au serveur OpAMP. Symptômes :
  • Les logs du OTel collector affichent des erreurs “connection refused” avec des adresses IP du cluster
  • Échecs de connexion à OpAMP du type : dial tcp 34.118.227.30:4320: connect: connection refused
Solution : Utilisez le nom de domaine pleinement qualifié (FQDN) pour l’URL du serveur OpAMP : 
helm install my-clickstack clickstack/clickstack \
  --set hyperdx.frontendUrl="http://your-external-ip-or-domain.com" \
  --set hyperdx.config.OPAMP_SERVER_URL="http://my-clickstack-clickstack-app.default.svc.cluster.local:4320"

​
Exemple de valeurs pour GKE

# values-gke.yaml
hyperdx:
  frontendUrl: "http://34.123.61.99"  # Use your LoadBalancer external IP

  config:
    OPAMP_SERVER_URL: "http://my-clickstack-clickstack-app.default.svc.cluster.local:4320"

clickhouse:
  keeper:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "pd-ssd"
        resources:
          requests:
            storage: 5Gi
  cluster:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "pd-ssd"
        resources:
          requests:
            storage: 10Gi

​
Amazon EKS

Pour les déploiements sur EKS, tenez compte de ces configurations courantes : 
# values-eks.yaml
hyperdx:
  frontendUrl: "https://hyperdx.yourdomain.com"

  ingress:
    enabled: true
    host: "hyperdx.yourdomain.com"
    tls:
      enabled: true

clickhouse:
  keeper:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "gp3"
        resources:
          requests:
            storage: 5Gi
  cluster:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "gp3"
        resources:
          requests:
            storage: 10Gi
Pour les configurations d’Ingress ALB sur AWS, consultez le guide des manifests additionnels et les valeurs d’exemple pour ALB.

​
Azure AKS

Pour les déploiements sur AKS : 
# values-aks.yaml
hyperdx:
  frontendUrl: "https://hyperdx.yourdomain.com"

clickhouse:
  keeper:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "managed-csi"
        resources:
          requests:
            storage: 5Gi
  cluster:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "managed-csi"
        resources:
          requests:
            storage: 10Gi

​
Checklist de déploiement cloud en production

Avant de déployer ClickStack en production chez un fournisseur de cloud :
  • Configurez correctement hyperdx.frontendUrl avec votre domaine ou IP externe
  • Configurez l’ingress avec TLS pour un accès en HTTPS
  • Remplacez l’URL du serveur OpAMP par un FQDN si vous rencontrez des problèmes de connexion (en particulier sur GKE)
  • Configurez les classes de stockage pour les volumes persistants de ClickHouse et Keeper
  • Définissez des requêtes et des limites de ressources appropriées
  • Activez le monitoring et les alertes
  • Configurez la sauvegarde et la reprise après sinistre
  • Mettez en place une gestion appropriée des secrets via hyperdx.secrets ou des secrets externes

​
Bonnes pratiques en production

​
Gestion des ressources

hyperdx:
  deployment:
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: "2"
        memory: 4Gi

otel-collector:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 256Mi

​
Haute disponibilité

hyperdx:
  deployment:
    replicas: 3
    topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app.kubernetes.io/name: clickstack

  podDisruptionBudget:
    enabled: true
    minAvailable: 1

​
Stockage persistant

Assurez-vous que des volumes persistants sont configurés pour la rétention des données dans les spécifications CR de l’opérateur : 
clickhouse:
  keeper:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "fast-ssd"
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi
  cluster:
    spec:
      dataVolumeClaimSpec:
        storageClassName: "fast-ssd"
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi

mongodb:
  spec:
    statefulSet:
      spec:
        volumeClaimTemplates:
          - metadata:
              name: data-volume
            spec:
              storageClassName: "fast-ssd"
              accessModes: ["ReadWriteOnce"]
              resources:
                requests:
                  storage: 10Gi
Classes de stockage spécifiques au cloud :
  • GKE: pd-ssd ou pd-balanced
  • EKS: gp3 ou io2
  • AKS: managed-premium ou managed-csi

​
Notes sur la compatibilité des navigateurs

Pour les déploiements en HTTP בלבד (développement/test), certains navigateurs peuvent afficher des erreurs liées à l’API de chiffrement, car ils exigent un contexte sécurisé. Pour les déploiements en production, utilisez toujours HTTPS avec des certificats TLS appropriés via la configuration de l’ingress. Consultez la configuration de l’ingress pour obtenir les instructions de configuration de TLS.

​
Prochaines étapes

Dernière modification le 25 juin 2026