DSGVO und IT-Systeme — Technische Vorbereitung auf die Verordnung

Kubernetes YAML Manifests sind leistungsfähig, aber die Verwaltung Dutzender Dateien für jede Umgebung ist ein Albtraum. Helm ist der „Package Manager für Kubernetes” — es verpackt Manifests in wiederverwendbare Charts mit Parametrisierung. Helm 2.x ist 2018 der De-facto-Standard für Kubernetes Deployment.

Warum Helm¶

Stellen Sie sich eine typische Anwendung vor: Deployment, Service, ConfigMap, Secret, Ingress, HorizontalPodAutoscaler. Das sind 6 YAML-Dateien. Für 3 Umgebungen (Dev, Staging, Prod) mit geringen Unterschieden sind es 18 Dateien. Mit Helm haben Sie einen Chart und 3 Values-Dateien.

• Parametrisierung — ein Template, verschiedene Werte pro Umgebung
• Versionierung — jedes Release hat eine Version, Sie können zurückrollen
• Dependencies — ein Chart kann von anderen Charts abhängen (PostgreSQL, Redis)
• Ökosystem — stable/ und incubator/ Repositories mit fertigen Charts für Prometheus, Grafana, nginx-ingress, cert-manager

Anatomie eines Helm Charts¶

myapp/
├── Chart.yaml          # Chart-Metadaten (Name, Version, Beschreibung)
├── values.yaml         # Standardwerte
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   ├── _helpers.tpl    # Wiederverwendbare Template-Snippets
│   └── NOTES.txt       # Post-Install-Anweisungen
├── charts/             # Sub-Charts (Dependencies)
└── requirements.yaml   # Dependency-Deklarationen

Templates und Values¶

Helm verwendet die Go Template Engine. Werte aus values.yaml werden in Templates interpoliert:

# DSGVO und IT-Systeme — Technische Vorbereitung auf die Verordnung
replicaCount: 3
image:
  repository: registry.company.com/myapp
  tag: "1.4.2"
  pullPolicy: IfNotPresent
resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 100m
    memory: 128Mi
ingress:
  enabled: true
  host: api.company.com

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
  labels:
    {{- include "myapp.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "myapp.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "myapp.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Arbeiten mit Helm¶

# Chart installieren
$ helm install myapp ./myapp -f values-prod.yaml

# Upgrade mit neuen Werten
$ helm upgrade myapp ./myapp --set image.tag=1.4.3

# Rollback auf vorherige Version
$ helm rollback myapp 1

# Release-Historie
$ helm history myapp
REVISION  UPDATED                   STATUS      DESCRIPTION
1         Mon Oct 15 10:00:00 2018  SUPERSEDED  Install complete
2         Tue Oct 16 14:30:00 2018  SUPERSEDED  Upgrade complete
3         Wed Oct 17 09:00:00 2018  DEPLOYED    Rollback to 1

# Debug — Templates ohne Installation rendern
$ helm template myapp ./myapp -f values-staging.yaml

Dependencies — Charts zusammensetzen¶

Ihre Anwendung braucht PostgreSQL und Redis? Sie müssen sie nicht manuell definieren:

# requirements.yaml
dependencies:
  - name: postgresql
    version: "3.18.3"
    repository: "https://charts.helm.sh/stable"
    condition: postgresql.enabled
  - name: redis
    version: "5.1.3"
    repository: "https://charts.helm.sh/stable"
    condition: redis.enabled

Der Befehl helm dependency update lädt Sub-Charts in das charts/-Verzeichnis herunter. Werte für Dependencies konfigurieren Sie in der Haupt-values.yaml:

# values.yaml
postgresql:
  enabled: true
  postgresqlPassword: "secret"
  persistence:
    size: 10Gi
redis:
  enabled: true
  cluster:
    enabled: false

Helm in der CI/CD-Pipeline¶

Helm integriert sich hervorragend in CI/CD-Pipelines:

• Lint: helm lint ./myapp — Syntax-Validierung und Best Practices
• Dry-Run: helm upgrade --install --dry-run — Simulation ohne tatsächliches Deployment
• Diff: helm-diff Plugin zeigt, was sich im Vergleich zum aktuellen Zustand ändert
• Automatisierter Rollback: helm upgrade --atomic --timeout 5m — automatischer Rollback bei fehlgeschlagenem Deployment

Tiller — Sicherheitsproblem von Helm 2¶

Helm 2 verwendet eine serverseitige Komponente namens Tiller, die im Cluster mit Cluster-Admin-Rechten läuft. Das ist ein Sicherheitsrisiko — jeder mit Zugriff auf die Tiller API kann überall alles deployen.

Gegenmaßnahmen:

• Tiller pro Namespace mit eingeschränkten RBAC-Rechten
• --tiller-namespace Flag für Isolierung
• TLS zwischen Helm Client und Tiller

Die gute Nachricht ist, dass Helm 3 (derzeit in Alpha) Tiller vollständig entfernt. Release-Informationen werden als Kubernetes Secrets gespeichert. Wir erwarten ein stabiles Release 2019.

Best Practices¶

• Semantische Versionierung — Chart.yaml Version folgt SemVer (MAJOR.MINOR.PATCH)
• Immutable Tags — verwenden Sie nicht :latest in der Produktion, immer konkrete Tags
• Resource Limits — definieren Sie immer CPU/Memory Requests und Limits
• NOTES.txt — zeigt nach der Installation nützliche Informationen an (URL, Credentials)
• Helm Test — helm test myapp führt Test-Pods aus (Smoke Tests)
• Chart Repository — ChartMuseum oder GitHub Pages für das Hosting eigener Charts

Helm ist ein unverzichtbares Tool für Kubernetes¶

Ohne Helm ist die Verwaltung von Kubernetes Manifests für reale Anwendungen untragbar. Helm Charts bringen Parametrisierung, Versionierung, Dependencies und ein Ökosystem fertiger Lösungen. Beginnen Sie mit helm create, fügen Sie eigene Templates hinzu und integrieren Sie es in CI/CD. Und beobachten Sie Helm 3 — die Entfernung von Tiller wird ein Game Changer.