Manifestes Helm supplémentaires

Déploiement d’objets Kubernetes personnalisés avec le chart Helm ClickStack à l’aide d’additionalManifests

Version 2.x du chart uniquement

La fonctionnalité additionalManifests est disponible uniquement dans le chart Helm v2.x basé sur des sous-charts.

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

• Guide principal de Helm - Installation de base
• Guide de configuration - Clés API, secrets et Ingress
• Déploiements Cloud - Configurations GKE, EKS et AKS
• Dépôt des charts Helm ClickStack - Code source du chart et référence des valeurs