Platform Bootstrap und Day-2 Operations

Lernziele

Nach dieser Lektion kannst du den Lebenszyklus eines Plattform-Clusters von der Geburt bis zur Abschaffung beschreiben: das Bootstrap-Henne-Ei-Problem und seine Lösung, die Addon-Schichtung mit Sync-Reihenfolge, Upgrade-Strategien (in-place vs. Blue-Green auf Cluster-Ebene) und die Day-2-Routinen, die eine Plattform betreibbar machen. Du kannst begründen, warum „Cluster als Vieh, nicht als Haustier” die Leitentscheidung hinter allem ist.

Das Problem: Der zweite Cluster entlarvt den ersten

Den ersten Cluster baut jedes Team irgendwie: ein Terraform-Run, dann zwei Tage helm install und kubectl apply nach einer halb dokumentierten Checkliste. Es funktioniert — bis der zweite Cluster gebraucht wird (neue Region, neuer Tenant-Tier aus Lektion 19, Ersatz nach einem Ausfall) und niemand mehr weiß, welche der 40 Handgriffe in welcher Reihenfolge nötig waren. Der erste Cluster ist ein Haustier: einzigartig, handgepflegt, nicht reproduzierbar.

Die Plattform-Disziplin verlangt das Gegenteil: Cluster als Vieh — jederzeit aus Code neu erzeugbar, untereinander identisch bis auf deklarierte Parameter. Das ist keine Ästhetik, sondern die Voraussetzung für fast alles aus den vorherigen Lektionen: Fleet-Konsistenz (Lektion 25), Blue-Green-Upgrades, Disaster Recovery und glaubwürdige Staging-Umgebungen (Lektion 23). Der Maßstab ist eine einzige Frage: Wie lange dauert es, einen Produktions-Cluster aus dem Nichts wiederherzustellen — und wie oft habt ihr das geübt?

Bootstrap: das Henne-Ei-Problem und seine Auflösung

GitOps verwaltet den Cluster-Inhalt (Lektion 25) — aber ein frischer Cluster hat noch keinen GitOps-Controller. Irgendetwas muss den Verwalter installieren, bevor der Verwalter verwaltet. Die etablierte Auflösung ist eine dreistufige Kette mit genau einem imperativen Moment:

1. Infrastruktur per IaC: Terraform/OpenTofu (oder Crossplane, Lektion 16) erzeugt den Cluster selbst — Control Plane, Node-Pools, Netzwerk, IAM-Bindungen. Output: ein leerer, erreichbarer Cluster.
2. Der eine imperative Schritt: Dieselbe Automatisierung installiert den GitOps-Controller und zeigt ihn auf das Plattform-Repo — bei Flux heißt dieser Schritt wörtlich flux bootstrap, bei Argo CD ist es ein Helm-Install plus eine Root-Application. Das ist der einzige Moment, in dem etwas von außen in den Cluster pusht.
3. Selbstaufbau: Ab jetzt zieht der Controller alles Weitere aus Git — Addons, Policies, Tenant-Namespaces. Der Cluster „weiß” über sein Verzeichnis im Plattform-Repo (bzw. seine ApplicationSet-Generator-Einträge), was er zu sein hat.

Damit ist „neuer Cluster” ein Pipeline-Lauf plus Wartezeit — und exakt derselbe Pfad ist dein Disaster-Recovery-Plan für die Plattform-Schicht (die Daten der Workloads sind ein eigenes Thema).

Innerhalb des Selbstaufbaus braucht es Schichtung mit Reihenfolge, denn Addons hängen voneinander ab: CNI und CSI zuerst (ohne Netzwerk-Plugin wird kein Pod ready), dann Kern-Addons (Cert-Manager, External Secrets, Ingress), dann Policy-Engine (Kyverno/OPA — bevor Tenant-Workloads starten, sonst entstehen ungeprüfte Ressourcen), dann Observability, zuletzt Tenants. GitOps-Tools bilden das ab: Argo CD mit Sync-Waves (annotierte Reihenfolge), Flux mit dependsOn zwischen Kustomizations. Diese Abhängigkeitskette explizit zu machen ist der Unterschied zwischen einem Bootstrap, der durchläuft, und einem, der in Race Conditions hängt.

Upgrades: die wiederkehrende Mutprobe

Kubernetes released drei Minor-Versionen pro Jahr, unterstützt jeweils etwa ein Jahr — Stillstand ist keine Option, und jede Version bringt API-Deprecations mit. Zwei Strategien auf Cluster-Ebene:

In-Place-Upgrade: Control Plane aktualisieren (bei Managed Kubernetes ein API-Call), dann Node-Pools rollierend erneuern — neue Nodes mit neuer Version hochfahren, alte cordon + drain, Workloads wandern. Voraussetzungen, die in der Praxis entscheiden: PodDisruptionBudgets bei den Tenants (sonst reißt der Drain Verfügbarkeit ab), Surge-Kapazität (der Betriebs-Headroom aus Lektion 24) und vorab geprüfte API-Kompatibilität — Tools wie kubent oder Pluto finden Manifeste, die deprecated APIs nutzen, bevor das Upgrade sie bricht.

Blue-Green auf Cluster-Ebene: Neben dem alten Cluster (blue) entsteht per Bootstrap-Kette ein neuer mit Zielversion (green); Workloads synct GitOps auf beide; Traffic wandert gesteuert (DNS-Gewichte, Load-Balancer) hinüber; blue bleibt als Rollback-Pfad, bis green sich bewährt hat, dann wird er abgerissen. Teurer (doppelte Kapazität während der Migration) und anspruchsvoll bei Stateful-Workloads — aber mit echtem Rollback und ohne Risiko für den laufenden Betrieb. Genau hier zahlt sich „Vieh statt Haustier” aus: Blue-Green ist nur möglich, wenn Cluster reproduzierbar sind.

Die reife Praxis kombiniert: In-Place für Routine-Upgrades (erst Staging-Cluster, dann Prod-Wellen — die Sync-Staffelung aus Lektion 25 gilt auch hier), Blue-Green für riskante Sprünge und als regelmäßig geübter Ernstfall-Pfad. Dieselbe Wellen-Logik gilt für Addon-Upgrades — ein fehlerhafter Cert-Manager- oder CNI-Rollout hat Cluster-weiten Blast Radius und verdient dieselbe Sorgfalt wie die Kubernetes-Version selbst.

Day-2: der Katalog der unspektakulären Pflichten

„Day-2 Operations” ist alles nach dem Go-Live — unspektakulär, aber hier entscheidet sich, ob die Plattform trägt:

• Zertifikats- und Credential-Rotation: Cluster-interne CAs, Webhook-Zertifikate, Cloud-Credentials der Operatoren. Automatisieren (Cert-Manager, kurzlebige Cloud-Identitäten via Workload Identity) — abgelaufene Zertifikate sind eine der peinlichsten und häufigsten Ausfallursachen.
• Backup mit Restore-Übung: etcd bzw. die Ressourcen-Ebene (Velero) plus Persistent Volumes. Ein Backup, dessen Restore nie geprobt wurde, ist eine Hoffnung, kein Plan — der Bootstrap-Pfad ersetzt Manifest-Backups weitgehend (alles steht in Git), aber nicht die Daten.
• Node-Lifecycle: OS-Patches durch regelmäßiges Node-Recycling statt In-Place-Patching — wer Nodes ohnehin alle paar Wochen austauscht (automatisiert, mit Drain-Disziplin), hat Patch-Management nebenbei gelöst und beweist permanent, dass Drain funktioniert.
• Kapazitäts- und Kosten-Routinen: die Forecast- und Rightsizing-Schleifen aus Lektion 21 und 24, als wiederkehrender Kalendereintrag statt als Projekt.
• Inventar und Versionsstand der Fleet: Welcher Cluster läuft auf welcher Kubernetes- und Addon-Version? Bei zehn Clustern braucht das ein Dashboard, kein Bauchgefühl — sonst entsteht Versions-Sprawl, der jedes folgende Upgrade verteuert.

Praxis: das Henne-Ei-Problem einmal selbst lösen

Baue die Bootstrap-Kette lokal mit kind und Flux (GitHub-Account und Personal Access Token mit Repo-Rechten vorausgesetzt):

# 1. "Infrastruktur": ein frischer Cluster
kind create cluster --name bootstrap-lab

# 2. Der eine imperative Schritt: Flux installieren + Repo verbinden
export GITHUB_TOKEN=<dein-token>
flux bootstrap github \
  --owner=<dein-user> --repository=platform-lab \
  --branch=main --path=clusters/lab --personal

# 3. Selbstaufbau beobachten:
flux get kustomizations --watch

Flux hat jetzt ein Repo platform-lab erzeugt (oder genutzt) und verwaltet sich selbst daraus. Ergänze im Repo unter clusters/lab/ eine HelmRelease für ein Addon (z. B. ingress-nginx) plus eine Kustomization mit dependsOn, committe — und sieh zu, wie der Cluster sich den Zustand zieht, ohne dass du ihn anfasst. Der Lerneffekt-Test: Lösche den Cluster (kind delete cluster --name bootstrap-lab), führe Schritt 1–2 erneut aus und stoppe die Zeit, bis der identische Zustand wiederhergestellt ist. Diese Zahl — und dass du sie kennst — ist Day-2-Reife in einer Metrik.

Typische Stolperfallen

Bootstrap dokumentiert statt automatisiert: Eine Checkliste im Wiki ist nach drei Monaten falsch und im Ernstfall um 3 Uhr nachts unbrauchbar. Wenn der Bootstrap nicht regelmäßig durch eine Pipeline läuft (z. B. weil jeder Staging-Cluster so entsteht), verrottet er ungetestet.

Addon-Reihenfolge implizit lassen: Ohne Sync-Waves/dependsOn funktioniert der Bootstrap oft zufällig — bis ein Timing sich ändert und die Policy-Engine nach den Workloads startet oder Cert-Manager-Webhooks Deployments blockieren, die vor ihm dran waren.

Upgrades aufschieben: Wer zwei Jahre sammelt, muss mehrere Minor-Versionen mit kumulierten API-Removals auf einmal springen — das Risiko wächst überlinear mit dem Rückstand. Kleine, häufige, eingeübte Upgrades sind die billigere Gesamtsumme.

Drain ohne PodDisruptionBudgets: Node-Recycling und Upgrades setzen voraus, dass Workloads Verdrängung tolerieren. PDBs (und mehr als ein Replica) gehören als Anforderung in den Golden Path und als Policy-Check in die Plattform — sonst wird jedes Upgrade zur Verhandlungsrunde mit vierzig Teams.

Interview-Vorbereitung

Auf „Wie bootstrappst und betreibst du Plattform-Cluster?” antwortest du entlang des Lebenszyklus: Leitentscheidung (Cluster reproduzierbar aus Code — Vieh, nicht Haustier; Maßstab: geübte Wiederherstellungszeit) → Bootstrap-Kette (IaC erzeugt den Cluster, ein imperativer Schritt installiert den GitOps-Controller, danach Selbstaufbau aus Git mit expliziter Addon-Reihenfolge) → Upgrades (in-place mit Drain-Disziplin, PDBs und API-Deprecation-Checks für die Routine; Blue-Green auf Cluster-Ebene für riskante Sprünge — möglich nur dank Reproduzierbarkeit) → Day-2-Katalog (Rotation, Backup mit Restore-Probe, Node-Recycling, Fleet-Inventar).

Wahrscheinliche Follow-ups:

• „Wie löst du das Henne-Ei-Problem von GitOps?” — ein einziger imperativer Bootstrap-Schritt (flux bootstrap / Argo-Install plus Root-App) aus derselben IaC-Pipeline, die den Cluster erzeugt; alles danach ist Pull.
• „In-Place oder Blue-Green-Upgrade?” — Routine in-place (billiger, eingeübt, gestaffelt über die Fleet), Blue-Green bei großen Sprüngen oder unklarem Risiko; ehrlich benennen: Blue-Green scheitert ohne Reproduzierbarkeit und ist bei Stateful-Workloads aufwendig.
• „Was prüfst du vor einem Kubernetes-Upgrade?” — deprecated APIs in allen Manifesten (kubent/Pluto), Addon-Kompatibilitätsmatrix, PDB-Abdeckung, Surge-Kapazität — und zuerst Staging mit identischem Stand.
• „Woher weißt du, dass dein DR-Plan funktioniert?” — weil er regelmäßig läuft: Cluster-Neuaufbau ist derselbe Pfad wie der Staging-Bootstrap, Restore von Daten wird als Übung terminiert; ungeprobte Pläne zählen nicht.

Zusammenfassung

Der Cluster-Lebenszyklus beginnt mit einer Architektur-Entscheidung: reproduzierbar aus Code statt handgepflegt. Der Bootstrap löst das Henne-Ei-Problem mit genau einem imperativen Schritt, danach baut der GitOps-Controller den Cluster in geordneten Schichten selbst auf; Upgrades werden durch Staffelung, Drain-Disziplin und — für die riskanten Fälle — Blue-Green auf Cluster-Ebene beherrschbar; Day-2 ist der Katalog automatisierter Routinen von Rotation über Backup-Proben bis zum Fleet-Inventar. Die eine Kennzahl, die alles zusammenfasst: Wie schnell steht ein Cluster aus dem Nichts wieder — und wann wurde das zuletzt geübt?

Damit ist das Betriebsmodell komplett. Die nächste Lektion geht eine Ebene tiefer in die Werkzeuge: IaC-Strategien — wie Terraform, Crossplane und Co. sich zu einer konsistenten Infrastruktur-Codebasis fügen.