Webinar // Cloud Native Computing Rheinland // 16. Juni 2020
Typisches Deployment: Container inkl. Sidecar- und Init-Container, Umgebungsvariablen, Volumes, Health Checks, Ressource Requests/Limits, ...
Zusätzlich: ConfigMaps, Secrets, Service, Ingress, RBAC, Network Policy, ...
Microservices?
Umgebungen: Hier entstehen die Varianten!
De-facto Standard
Package-Manager: Auslieferung von Charts, Plug&Play-UX
Templates mit Parametern, basierend auf go:text/template
Alles ist ein Parameter?
Viele Community Charts: https://github.com/helm/charts
"Plug & Play"-Setups inkl. Dependencies
Austausch von Charts, values.yaml als API
Chart zur Bündelung aller YAML-Files einer Anwendung
Neue "Sprache"
Schwer lesbare Dateien
Mäßiger IDE-Support
Deklarativ? Zu viele Kontrollstrukturen
Das Chart unterstützt das Feature nicht, was ich brauche! Und nun? Fork?
Kustomize should expose and teach native k8s APIs, rather than hide them.https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md
... provides a new, purely declarative approach to configuration customization that adheres to and leverages the familiar and carefully designed Kubernetes API.https://kubernetes.io/blog/2018/05/29/introducing-kustomize-template-free-configuration-customization-for-kubernetes/
kustomize lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.https://github.com/kubernetes-sigs/kustomize
Kein Paket-Manager: Leichtgewichtiges Tool zum Anpassen von K8s-YAML-Dateien. Verteilung von Anwendungspaketen ist nicht im Scope.
Keine Templates: Kustomize setzt auf eine Overlay-/Patch-Strategie
Kein Paket-Manager: Leichtgewichtiges Tool zum Anpassen von K8s-YAML-Dateien. Verteilung von Anwendungspaketen ist nicht im Scope.
Keine Templates: Kustomize setzt auf eine Overlay-/Patch-Strategie
Deklarativ: Jederzeit valide Kubernetes-YAML-Dateien ohne Platzhalter, volle IDE-Unterstützung inkl. Auto-Completion.
Praktische Features: Namespace, "Common-Label", ConfigMap/Secret-Änderungen
Flexibel und unabhängig: Das CLI-Tool kustomize rendert letztlich nur YAML-Output nach Stdout
$ kustomize build ~/someApp/overlays/production | kubectl apply -f -
Integration: Seit kubectl v.1.14 integriert
$ kubectl apply -k ~/someApp/overlays/production
Gut lesbare Dateien, mehr Transparenz, einfachere Wartung
Voller IDE-Support
Praktische Features (z.B. ConfigMap-Generator)
Maximale Flexibilität durch Low-Level-Modifikationen (z.B. JSON6902 Patches)
Community-Arbeit passiert meist in Helm
Eigene Lösung für Verteilung und Umgang mit Rollouts notwendig
Anwender muss wissen, wie Konfigurationen der Anwendung funktionieren (Doku!)
Streit-Thema: Kein Support für die Übergabe von Argumenten zur Laufzeit
$ mkdir ./base
$ helm template --values ./values.yaml stable/nginx-ingress \
> ./base/manifests.yaml
$ cat < ./base/kustomization.yaml
bases:
— manifests.yaml
EOF
# create your overlays based on the rendered Helm chart
$ kubectl apply -k ./overlays/prod/
Von Community-Projekten profitieren
Wartbare Anpassungen mit Kustomize vornehmen
Disclaimer: Stark generalisiert und vereinfacht.
Lasst uns gerne eure Anwendungsfälle diskutieren!
| Tool | Use Cases |
|---|---|
| Helm |
|
| Kustomize |
|
| Helm & Kustomize |
|
| Operators |
|