Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs
49.6kGet Started

Manifestes Helm supplémentaires

View as MarkdownEdit this pageReport an issueSet up docs MCP

La valeur additionalManifests vous permet de déployer des objets Kubernetes arbitraires avec le chart ClickStack. Utilisez-la pour les ressources que le chart ne prend pas en charge nativement, comme NetworkPolicy, HorizontalPodAutoscaler, ServiceAccount, PodMonitor, des objets Ingress personnalisés ou tout autre objet de l'API Kubernetes.

Fonctionnement

Chaque entrée dans additionalManifests est une définition complète de ressource Kubernetes. Le chart :

  1. Parcourt chaque entrée de la liste
  2. Convertit l'entrée en YAML (toYaml)
  3. Évalue les expressions de template dans ce YAML à l'aide de tpl dans Helm

Les expressions de template peuvent faire référence à :

  • .Release.Name, .Release.Namespace
  • include "clickstack.fullname" . et les autres helpers du chart
  • .Values.*
additionalManifests:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name: '{{ include "clickstack.fullname" . }}-custom'
    data:
      release: '{{ .Release.Name }}'

Contraintes des fichiers values

additionalManifests se configure dans un fichier values, et les fichiers values sont analysés comme du YAML avant l’exécution de tpl.

  • Toute occurrence de {{ ... }} dans un fichier values doit se trouver dans une chaîne entre guillemets
  • Les blocs de template structurels ne sont pas valides dans un YAML de fichier values (par exemple, {{- include ... | nindent ... }} seul)
  • Pour les champs non textuels (par exemple, les ports numériques), utilisez des valeurs littérales ou des ports nommés
  • Si vous avez besoin de templating structurel, utilisez le template d’un wrapper chart plutôt qu’un fichier values brut
# Valid in values.yaml
name: '{{ include "clickstack.fullname" . }}-app'

# Invalid in values.yaml (unquoted template expression)
name: {{ include "clickstack.fullname" . }}-app

# Invalid in values.yaml (structural template block)
labels:
  {{- include "clickstack.labels" . | nindent 2 }}

Helpers de chart disponibles

Ces helpers sont définis dans templates/_helpers.tpl :

Helper Description Utilisation dans le fichier values
clickstack.name Nom du chart (tronqué à 63 caractères) Sans risque dans les scalaires entre guillemets
clickstack.fullname Nom qualifié par la release Sans risque dans les scalaires entre guillemets
clickstack.chart Nom du chart + version Sans risque dans les scalaires entre guillemets
clickstack.selectorLabels Bloc de labels du selector Uniquement dans les templates de wrapper chart
clickstack.labels Bloc de labels standard Uniquement dans les templates de wrapper chart
clickstack.mongodb.fullname Nom de la CR MongoDB Sans risque dans les scalaires entre guillemets
clickstack.clickhouse.fullname Nom de la CR ClickHouse Sans risque dans les scalaires entre guillemets
clickstack.otel.fullname Nom du collector OTel Sans risque dans les scalaires entre guillemets

Exemples

ServiceAccount

additionalManifests:
  - apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: '{{ include "clickstack.fullname" . }}'
      namespace: '{{ .Release.Namespace }}'
      labels:
        app.kubernetes.io/name: '{{ include "clickstack.name" . }}'
        app.kubernetes.io/instance: '{{ .Release.Name }}'
      annotations:
        eks.amazonaws.com/role-arn: "arn:aws:iam::123456789:role/my-role"

NetworkPolicy

Limitez le trafic entrant à destination des pods HyperDX :

additionalManifests:
  - apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: '{{ include "clickstack.fullname" . }}-allow-ingress'
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: '{{ include "clickstack.name" . }}'
          app.kubernetes.io/instance: '{{ .Release.Name }}'
      policyTypes:
        - Ingress
      ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: ingress-nginx
          ports:
            - protocol: TCP
              port: 3000
            - protocol: TCP
              port: 8000

HorizontalPodAutoscaler

additionalManifests:
  - apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: '{{ include "clickstack.fullname" . }}-hpa'
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: '{{ include "clickstack.fullname" . }}-app'
      minReplicas: 2
      maxReplicas: 10
      metrics:
        - type: Resource
          resource:
            name: cpu
            target:
              type: Utilization
              averageUtilization: 75

PodMonitor (Prometheus Operator)

additionalManifests:
  - apiVersion: monitoring.coreos.com/v1
    kind: PodMonitor
    metadata:
      name: '{{ include "clickstack.fullname" . }}'
      labels:
        release: prometheus
    spec:
      selector:
        matchLabels:
          app.kubernetes.io/name: '{{ include "clickstack.name" . }}'
          app.kubernetes.io/instance: '{{ .Release.Name }}'
      podMetricsEndpoints:
        - port: app
          interval: 30s

Ingress ALB sur AWS

Si vous utilisez l’AWS Load Balancer Controller, désactivez l’Ingress nginx intégré au chart et définissez un Ingress ALB personnalisé :

hyperdx:
  ingress:
    enabled: false

additionalManifests:
  - apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: '{{ include "clickstack.fullname" . }}-alb'
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: ip
        alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:us-east-1:123456789:certificate/abc-123"
        alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
        alb.ingress.kubernetes.io/ssl-redirect: "443"
        alb.ingress.kubernetes.io/group.name: clickstack
        alb.ingress.kubernetes.io/healthcheck-path: /api/health
    spec:
      ingressClassName: alb
      rules:
        - host: clickstack.example.com
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: '{{ include "clickstack.fullname" . }}-app'
                    port:
                      name: app

Pour un exemple complet de configuration ALB, y compris l’Ingress interne du collecteur OTel et le HPA, consultez les valeurs d’exemple ALB.

TargetGroupBinding

Pour les scénarios ALB nécessitant des ressources TargetGroupBinding explicites :

additionalManifests:
  - apiVersion: elbv2.k8s.aws/v1beta1
    kind: TargetGroupBinding
    metadata:
      name: '{{ include "clickstack.fullname" . }}-tgb'
    spec:
      serviceRef:
        name: '{{ include "clickstack.fullname" . }}-app'
        port: app
      targetGroupARN: "arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123"
      targetType: ip

Avancé : templates de wrapper chart

Si vous avez besoin d’helpers structurels comme include "clickstack.labels" . | nindent 4, générez-les à partir d’un template de wrapper chart (templates/*.yaml) au lieu de placer directement ces blocs dans les fichiers values.

Exemple d’extrait de template de wrapper chart :

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "clickstack.fullname" . }}-extra
  labels:
    {{- include "clickstack.labels" . | nindent 4 }}
data:
  appPort: "{{ .Values.hyperdx.ports.app }}"

Astuces

Hooks de Helm

Chaque entrée additionalManifests est générée sous forme de document YAML distinct. Vous pouvez ajouter des annotations de hook Helm pour contrôler l’ordre d’installation et de mise à niveau :

additionalManifests:
  - apiVersion: batch/v1
    kind: Job
    metadata:
      name: post-install-job
      annotations:
        helm.sh/hook: post-install
        helm.sh/hook-delete-policy: hook-succeeded
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: migrate
              image: my-migration-image:latest
              command: ["./migrate.sh"]

Ordre des CRD

Si vos manifests supplémentaires incluent des ressources personnalisées (par exemple, PodMonitor), les CRD doivent déjà exister dans le cluster avant l’installation ou la mise à niveau.

Combiner plusieurs ressources

additionalManifests est une liste. Les éléments sont rendus dans l’ordre de la liste, et chaque élément devient un document YAML distinct.

Étapes suivantes

Navigation