PP
🚀 Platform Engineer Lektion 30/50 ~8 Min. Fortgeschritten

Package Layer: Helm, Kustomize, OCI Artifacts

Wiederverwendbare Plattform-Pakete und Artifact-Management.

#helm #kustomize
📝 Meine Notizen

Lernziele

Nach dieser Lektion kannst du erklären, warum eine Plattform eine eigene Package-Schicht braucht und wie Helm, Kustomize und OCI-Registries darin zusammenspielen. Du kannst das Muster „ein kuratiertes Standard-Chart für alle Services” gegen „jedes Team baut eigene Manifeste” abwägen und weißt, wie Versionierung, Signierung und Verteilung von Plattform-Paketen über eine OCI-Registry laufen.

Das Problem: 100 Teams, 100 Kopien derselben YAML

Stell dir die Plattform aus den letzten Lektionen vor: GitOps deployt, Policies validieren, Controller provisionieren. Aber was deployen die Teams eigentlich? Wenn jedes der hundert Teams seine Deployments, Services und Ingress-Ressourcen selbst schreibt, hast du hundert leicht unterschiedliche Varianten desselben Musters. Team A vergisst die Probes, Team B setzt veraltete Labels, Team C kopiert ein fünf Jahre altes Beispiel aus dem Internet. Jede Plattform-Änderung — neue Pflicht-Labels, geänderte Ingress-Klasse — bedeutet hundert Pull Requests in hundert Repos.

Die Policies aus Lektion 28 fangen die schlimmsten Verstöße ab, aber sie erzeugen keine gute Konfiguration. Was fehlt, ist eine Schicht wiederverwendbarer, versionierter Pakete: einmal richtig gebaut vom Plattform-Team, hundertfach konsumiert von den Stream-Teams. Das ist der Package Layer.

Das Workload-Chart: ein Chart für (fast) alle Services

Das wirkungsvollste Muster dieser Schicht ist das kuratierte Standard-Chart (oft „Workload-Chart” oder „Common Chart” genannt): ein Helm-Chart, das das Plattform-Team pflegt und das jeden typischen Service der Organisation abdeckt. Ein Team liefert nur noch Values:

# values.yaml des Teams — die gesamte Deployment-Konfiguration
image:
  repository: registry.internal/checkout/api
  tag: "2.4.1"
replicas: 3
ingress:
  host: checkout.internal.example.com
resources:
  tier: medium

Probes, securityContext, Labels nach Konvention, PodDisruptionBudget, ServiceMonitor — alles steckt im Chart und ist damit automatisch policy-konform (die Guardrails aus Lektion 28 sind eingepreist). Der Effekt auf die Plattform-Ökonomie ist enorm: Eine Änderung am Chart, ein Versions-Bump, und alle Teams ziehen nach — statt hundert PRs einer.

Die Grenze des Musters musst du ehrlich benennen: Das Chart wächst mit jedem Sonderwunsch. Wenn es irgendwann jede denkbare Topologie abdecken soll, hast du ein unwartbares Monster mit hunderten Values-Optionen gebaut. Die reife Antwort ist eine bewusste Abdeckungsgrenze — das Standard-Chart deckt die 80 % Standardfälle ab, Spezialfälle (Stateful-Workloads, exotische Deployment-Muster) bekommen eigene Charts oder rohe Manifeste als dokumentierten Escape Hatch.

Helm und Kustomize: Schichten, nicht Konkurrenten

Im Plattform-Kontext lösen die beiden Tools unterschiedliche Probleme, und meist brauchst du beide:

Helm ist das Paketformat: Templates plus Values, versionierbar, verteilbar, mit definierter Schnittstelle. Alles, was du an viele Konsumenten ausliefern willst — das Workload-Chart, Drittsoftware wie ingress-nginx oder cert-manager — ist sinnvollerweise ein Chart.

Kustomize ist das Patch-Werkzeug: Eine Base mit fertigen Manifesten, Overlays patchen pro Umgebung. Keine Template-Sprache, kein Paketkonzept — dafür kann es etwas, das Helm nicht kann: fremde Manifeste nachträglich ändern, ohne sie zu forken.

Das verbreitete Zusammenspiel: Helm rendert das Paket, Kustomize patcht die letzten organisationsspezifischen Details, die das Chart nicht konfigurierbar macht. GitOps-Tools unterstützen diese Kombination direkt — Flux über HelmRelease plus postRenderers, Argo CD über Config-Management-Plugins bzw. die kombinierte Helm+Kustomize-Rendering-Kette. Im Interview ist „Helm für Paketierung, Kustomize für Last-Mile-Patches” eine deutlich stärkere Antwort als eine Tool-Präferenz.

OCI-Registry: eine Verteilstation für alles

Bleibt die Frage der Verteilung. Klassische Helm-Repositories (HTTP-Server mit index.yaml) funktionieren, aber sie sind eine separate Infrastruktur neben der Container-Registry — mit eigener Authentifizierung, eigenem Hosting, eigener Zugriffskontrolle.

OCI-Artefakte lösen das elegant: Die OCI-Spezifikation, auf der Container-Registries basieren, kann beliebige Artefakt-Typen speichern. Helm unterstützt das nativ:

# Chart paketieren und in die Registry pushen
helm package workload-chart/
helm push workload-chart-1.4.0.tgz oci://registry.internal/platform/charts

# Konsumieren — ohne 'helm repo add'
helm install checkout oci://registry.internal/platform/charts/workload-chart \
  --version 1.4.0 -f values.yaml

Damit liegt das Chart in derselben Registry wie die Container-Images: gleiche Authentifizierung, gleiche Replikation, gleiches Vulnerability-Scanning-Ökosystem — und vor allem gleiches Signing. Mit cosign signierst du Charts wie Images und verifizierst die Signatur per Admission Policy (Kyverno aus Lektion 28 kann genau das): Nur Pakete, die nachweislich vom Plattform-Team gebaut wurden, dürfen in den Cluster. Das ist der Anschlusspunkt an Supply-Chain-Security, die später im Lernpfad vertieft wird.

Für die Package-Schicht heißt das konkret: SemVer-Disziplin (ein Breaking Change im Workload-Chart ist ein Major-Bump mit Migrationsnotizen, denn er betrifft alle Teams), ein Changelog, und Deprecation-Fenster statt stiller Änderungen. Du verwaltest hier eine interne Software-Lieferkette — mit denselben Pflichten wie ein Open-Source-Maintainer gegenüber seinen Nutzern.

Praxis: ein Mini-Workload-Chart bauen und per OCI verteilen

# 1. Chart-Gerüst erzeugen und anschauen
helm create workload
ls workload/templates/

# 2. Lokal rendern und prüfen — ohne Cluster
helm template my-service ./workload \
  --set image.repository=nginx --set image.tag=1.27 | less

# 3. Linting wie in einer Plattform-CI
helm lint ./workload

# 4. Lokale OCI-Registry starten und Chart durchschleusen
docker run -d -p 5000:5000 --name registry registry:2
helm package ./workload
helm push workload-0.1.0.tgz oci://localhost:5000/charts
helm install test oci://localhost:5000/charts/workload --version 0.1.0

Erweitere danach das Chart um einen Plattform-Standard, den helm create nicht mitbringt — etwa einen fest verdrahteten securityContext mit runAsNonRoot: true in templates/deployment.yaml — und bumpe die Version auf 0.2.0. Damit hast du den kompletten Zyklus einmal selbst durchlaufen: Standard einbauen, versionieren, verteilen.

Typische Stolperfallen

Das Über-Chart: Ein Workload-Chart, das jeden Sonderfall abdecken will, wird selbst zur Komplexitätsquelle. Abdeckungsgrenze definieren, Escape Hatch dokumentieren.

Charts ohne Versionsdisziplin: Wenn latest konsumiert wird oder Breaking Changes als Patch-Release kommen, bricht ein Chart-Update unkoordiniert hundert Services. Pinned Versions bei den Konsumenten, SemVer beim Producer.

Fork statt Patch bei Drittsoftware: Wer ein Upstream-Chart forkt, um zwei Werte zu ändern, pflegt den Fork für immer. Erst Values ausreizen, dann Kustomize-Post-Rendering — Fork ist das letzte Mittel.

Registry als Single Point of Failure unterschätzt: Wenn Charts, Images und Signaturen aus einer Registry kommen, ist deren Ausfall ein Deployment-Stopp für die gesamte Plattform. Replikation und Pull-Through-Cache gehören zur Package-Schicht dazu.

Interview-Vorbereitung

Auf „Wie organisierst du Deployment-Konfiguration für viele Teams?” antwortest du problem-first: Duplikationsproblem (n Teams × eigene Manifeste = Drift und unmögliche Plattform-Änderungen) → kuratiertes Workload-Chart (Teams liefern Values, Standards stecken im Chart) → Werkzeug-Schichtung (Helm paketiert, Kustomize patcht die letzte Meile) → Verteilung (OCI-Registry, SemVer, Signierung mit Verifikation am Admission-Punkt).

Typische Follow-ups:

  • „Was tust du, wenn ein Team etwas braucht, das das Standard-Chart nicht kann?” — Erst prüfen, ob es ein 80 %-Fall ist (dann Chart erweitern), sonst dokumentierter Escape Hatch; das Chart nicht für Einzelfälle aufblähen.
  • „Warum OCI statt klassischem Chart-Repository?” — Eine Infrastruktur für Images und Charts: gleiche Auth, gleiches Scanning, gleiches Signing; kein separater Index-Server.
  • „Wie rollst du einen Breaking Change im Workload-Chart aus?” — Major-Version parallel anbieten, Migrationsnotizen, Deprecation-Frist, Adoption tracken — wie ein externer Library-Maintainer.
  • „Helm-Templates oder Kustomize-Overlays für Umgebungsunterschiede?” — Innerhalb eines verteilten Pakets Values/Templates; für nachträgliche Anpassung fremder Manifeste Kustomize.

Zusammenfassung

Der Package Layer macht aus hundertfach kopierter YAML versionierte, kuratierte Pakete: Ein Standard-Workload-Chart trägt die Organisationsstandards, Teams liefern nur Values; Kustomize patcht, was Pakete nicht konfigurierbar machen; OCI-Registries verteilen Charts neben Images mit gemeinsamer Auth und Signierung. Versionsdisziplin ist dabei keine Formalie, sondern der Vertrag mit allen Teams. Damit ist die Automation-Schicht der Plattform komplett — die nächsten Lektionen wechseln die Perspektive zu den Services, die darauf laufen: zuerst die Frage, wie viel Kubernetes Entwickler überhaupt sehen sollten, wenn sie ein Environment anfordern.