Zum Inhalt

ConfigMaps

Der ConfigMaps-Helper erstellt Kubernetes ConfigMaps für Anwendungskonfiguration.

Übersicht

ConfigMaps speichern nicht-sensible Konfigurationsdaten als Key-Value-Paare oder als Dateien. Sie sind ideal für:

  • Konfigurationsdateien (YAML, JSON, INI, etc.)
  • Umgebungsvariablen
  • Kommandozeilen-Argumente
  • Feature-Flags

Basis-Konfiguration

configs:
  - name: app-config
    namespace: production
    values:
      config.yaml: |
        server:
          host: 0.0.0.0
          port: 8080

Mehrere Keys

Eine ConfigMap kann mehrere Keys (Dateien) enthalten:

configs:
  - name: app-config
    namespace: production
    values:
      config.yaml: |
        server:
          host: 0.0.0.0
          port: 8080
        database:
          host: postgres
          port: 5432

      logging.yaml: |
        level: info
        format: json

      features.json: |
        {
          "newUI": true,
          "darkMode": false
        }

Key-Value Paare

Für einfache Key-Value-Konfigurationen:

configs:
  - name: app-env
    namespace: production
    values:
      APP_ENV: production
      LOG_LEVEL: info
      FEATURE_FLAG_X: "true"
      MAX_CONNECTIONS: "100"

dontOverrideOnUpdate

Mit dontOverrideOnUpdate: true bleiben Änderungen bei helm upgrade erhalten:

configs:
  # Standard: Wird bei jedem Upgrade überschrieben
  - name: app-config
    namespace: production
    dontOverrideOnUpdate: false
    values:
      config.yaml: |
        server:
          port: 8080

  # Benutzer-Änderungen bleiben erhalten
  - name: user-settings
    namespace: production
    dontOverrideOnUpdate: true
    values:
      settings.yaml: |
        theme: light
        language: de

Wann dontOverrideOnUpdate verwenden?

  • false (Standard): Für Konfigurationen, die mit dem Code versioniert sind
  • true: Für Konfigurationen, die Benutzer zur Laufzeit ändern können

Mehrere ConfigMaps

configs:
  # Haupt-Konfiguration
  - name: api-config
    namespace: production
    values:
      config.yaml: |
        server:
          port: 8080

  # Nginx Konfiguration
  - name: nginx-config
    namespace: production
    values:
      nginx.conf: |
        server {
          listen 80;
          location / {
            proxy_pass http://localhost:8080;
          }
        }

  # Prometheus Konfiguration
  - name: prometheus-config
    namespace: monitoring
    values:
      prometheus.yml: |
        global:
          scrape_interval: 15s
        scrape_configs:
          - job_name: 'api'
            static_configs:
              - targets: ['api:8080']

Verwendung in Containern

Als Volume mounten

configs:
  - name: app-config
    namespace: production
    values:
      config.yaml: |
        server:
          port: 8080

chart:
  container:
    image: myapp:latest
    volumeMounts:
      - name: config
        mountPath: /etc/app

  deploymentVolume:
    volumes:
      - name: config
        configMap:
          name: app-config

Einzelne Datei mounten

chart:
  container:
    volumeMounts:
      - name: config
        mountPath: /etc/app/config.yaml
        subPath: config.yaml

  deploymentVolume:
    volumes:
      - name: config
        configMap:
          name: app-config

Als Umgebungsvariablen

configs:
  - name: app-env
    namespace: production
    values:
      LOG_LEVEL: info
      MAX_CONNECTIONS: "100"

chart:
  container:
    envFrom:
      - configMapRef:
          name: app-env

Vollständiges Beispiel

# Chart.yaml
apiVersion: v2
name: my-app
version: 1.0.0

dependencies:
  - name: ohmyhelm
    alias: app
    repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
    version: 1.13.0
# values.yaml
app:
  # ConfigMaps
  configs:
    - name: api-config
      namespace: production
      values:
        config.yaml: |
          server:
            host: 0.0.0.0
            port: 8080
            timeout: 30s
          database:
            host: {{ .Values.dbHost }}
            port: 5432
            name: myapp
          cache:
            host: redis
            port: 6379
            ttl: 3600

    - name: nginx-config
      namespace: production
      values:
        default.conf: |
          upstream backend {
            server localhost:8080;
          }
          server {
            listen 80;
            location / {
              proxy_pass http://backend;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
            }
          }

  # Deployment
  chart:
    enabled: true
    fullnameOverride: "my-api"

    container:
      image: myapp/api:latest
      ports:
        - name: http
          containerPort: 8080
      volumeMounts:
        - name: config
          mountPath: /etc/app

    sidecar:
      enabled: true
      image: nginx:alpine
      volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d

    deploymentVolume:
      volumes:
        - name: config
          configMap:
            name: api-config
        - name: nginx-config
          configMap:
            name: nginx-config

Helm Templating in ConfigMaps

Sie können Helm-Templates in ConfigMaps verwenden:

configs:
  - name: app-config
    namespace: production
    values:
      config.yaml: |
        environment: {{ .Values.environment }}
        replicas: {{ .Values.replicaCount }}
        features:
          {{- range .Values.features }}
          - {{ . }}
          {{- end }}

Best Practices

  1. Trennung von Konfiguration und Code - ConfigMaps ermöglichen Konfigurationsänderungen ohne Rebuild
  2. Versionierung - Fügen Sie Versionierung in ConfigMap-Namen für Rollbacks hinzu
  3. Größenlimit beachten - ConfigMaps sind auf 1 MiB begrenzt
  4. Keine Secrets - Verwenden Sie ConfigMaps nur für nicht-sensible Daten
  5. Immutable ConfigMaps - Für Production können Sie immutable: true setzen

Troubleshooting

ConfigMap prüfen

# ConfigMap anzeigen
kubectl get configmap app-config -n production -o yaml

# Einzelnen Key ausgeben
kubectl get configmap app-config -n production -o jsonpath='{.data.config\.yaml}'

# Im Pod prüfen
kubectl exec -it <pod> -n production -- cat /etc/app/config.yaml

Änderungen nicht übernommen

Pods laden ConfigMaps nur beim Start. Nach Änderungen:

# Rolling Restart
kubectl rollout restart deployment/my-api -n production

Siehe auch