08 Helm, Kustomize und Template-Strategie
Helm paketiert Kubernetes-Ressourcen als Chart mit Values. Kustomize arbeitet patch-basiert mit Overlays. Beide sind gängige Wege, OpenShift-Objekte wiederverwendbar zu beschreiben.
Fachliche Erklärung
Helm ist stark, wenn ein Produkt als wiederverwendbares Paket mit Parametern verteilt wird.
Kustomize ist stark, wenn eine Basis fast gleich bleibt und Umgebungen nur gezielt gepatcht werden.
OpenShift-spezifische Ressourcen wie Route, BuildConfig oder ImageStream können in beiden Varianten verwaltet werden.
Entscheidungshilfe
Helm: gut für Produkte, Versionierung, Abhängigkeiten, Chart-Repositories.
Kustomize: gut für GitOps-Overlays, geringe Template-Magie, nachvollziehbare Patches.
Nicht mischen ohne Regel: Entweder Helm rendert alles und Argo CD wendet an, oder Kustomize verwaltet Overlays.
Anti-Pattern
Values-Dateien mit hunderten unklaren Parametern.
Geheimnisse im Chart.
Umgebungsspezifische Logik im Application-Code statt in Config.
Ungetestete Templates, die erst im Cluster fehlschlagen.
Ausführliches Enterprise-Beispiel
Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.
Fachlicher Ablauf
- Kunde bestellt über Portal.
- order-api validiert Auftrag.
- billing-api erzeugt Rechnung.
- payment-api prüft Zahlung.
- Events informieren Lager und Reporting.
Technischer Ablauf
- Route nimmt HTTPS an.
- Service verteilt auf Pods.
- Pods lesen ConfigMaps und Secrets.
- Readiness schützt Rollout.
- Monitoring misst Fehlerquote und Latenz.
Konfigurations- und Codebeispiele
YAML
image:
repository: image-registry.openshift-image-registry.svc:5000/shop/order-api
tag: 1.0.0
replicaCount: 3
route:
enabled: true
host: order-api.apps.example.com
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: 1000m
memory: 1024Mi
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
seccompProfile:
type: RuntimeDefault
YAML
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patches:
- path: patch-replicas.yaml
- path: patch-route-host.yaml
images:
- name: order-api
newName: image-registry.openshift-image-registry.svc:5000/shop/order-api
newTag: 1.0.0
configMapGenerator:
- name: order-api-config
behavior: merge
literals:
- LOG_LEVEL=INFO
BASH
helm template order-api ./charts/order-api -f values-dev.yaml
kustomize build overlays/dev
oc apply --dry-run=server -k overlays/dev
Typische Fehlerbilder und Diagnose
Pending Pods
Prüfe Ressourcen, Node-Selector, Taints, PVC und Quotas. Nicht sofort am Java-Code suchen.
CrashLoopBackOff
Prüfe Logs des vorherigen Containers, Config/Secrets, Port, JVM Memory und Health Endpoints.
Route erreichbar, App nicht
Prüfe Service-Selector, Endpoints, Readiness, TLS-Termination und NetworkPolicy.
Praxisaufgabe
Modelliere dieselbe Anwendung einmal als Helm Chart und einmal als Kustomize Base/Overlay. Vergleiche Lesbarkeit, Wiederverwendung und GitOps-Diff.
Merksätze
- Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
- Security und Betrieb gehören von Anfang an zum Deployment.
- Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
- Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.