Kubernetes in Produktion: die Checkliste, die in den meisten Architektur-Grafiken fehlt
Die beliebten Grafiken zur Kubernetes-Produktionsarchitektur enden meist an der Registry. Diese Checkliste beginnt dort: Rollback, Secrets, TLS, Ressourcen, Backups mit Restore-Test, Sicherheit, Alarme, Upgrades und die Frage, wem der Cluster gehört.
Freitag, 17:40 Uhr. Das Release vom Mittag bricht den Checkout, und der Rollback scheitert an einer einfachen Frage: Welches Image lief vorher? Der Tag latest zeigt längst auf den kaputten Build. Gebaut hatte das Team seinen Cluster nach einer dieser Grafiken, die als „komplette Kubernetes-Produktionsarchitektur“ geteilt werden – Git, CI/CD, Registry, Cluster, Ingress, Pods, rechts oben ein Grafana-Logo. Alles darauf war vorhanden. Gefehlt hat, was nicht darauf vorkommt.
Eine Produktions-Checkliste für Kubernetes ist eine Liste von Betriebsfragen, die beantwortet und einmal ausprobiert sein müssen, bevor echte Kunden auf dem Cluster landen: wie man zurückrollt, wo Secrets liegen, wer nachts die Warnung bekommt. Sie zählt keine Komponenten auf, sondern Zustände, die man prüfen kann.
Die typische Grafik beschreibt den Weg des Codes: Commit, Build, Push in die Registry, Deployment, Ingress. Das ist der Teil, der am ersten Tag funktioniert. Was in Produktion wehtut, passiert danach – am Tag 60, wenn ein Zertifikat nicht erneuert wird, im zehnten Monat, wenn die Kubernetes-Version ausläuft, oder an dem Abend, an dem jemand eine Tabelle löscht. Die Liste unten ist nach Bereichen sortiert, jeder Punkt nennt seinen Grund. Haken Sie nur ab, was Sie schon einmal ausprobiert haben.
Deploy, Konfiguration, Netzwerk: Was muss vor dem ersten Kunden stehen?
Deploy und Rollback
- Images per Digest ausrollen (
image@sha256:…), nicht per Tag – ein Tag lässt sich verschieben, ein Digest nicht. - Die vorige Version kommt mit einem Schritt zurück, ohne neuen Build – und das wurde einmal geübt.
- Datenbank-Migrationen bleiben rückwärtskompatibel: Der alte Code muss das neue Schema eine Weile vertragen, sonst hilft der schnellste Rollback nichts.
- Readiness-Check und Timeout pro Service: Ein langsamer Start darf nicht als gescheiterter Deploy gelten.
Konfiguration und Secrets
- Keine Secrets als Base64 im Git-Repository – Base64 ist eine Kodierung, keine Verschlüsselung.
- Kubernetes legt Secrets standardmäßig unverschlüsselt in etcd ab; Verschlüsselung at rest und RBAC auf Secrets gehören zur Grundausstattung.
- Geänderte Konfiguration zeigt sichtbar „gespeichert, aber nicht ausgerollt“ – sonst gilt eine Änderung als erledigt, die nie in den Pods ankam.
Netzwerk und TLS
- cert-manager erneuert standardmäßig nach zwei Dritteln der Laufzeit. Überwachen Sie, ob die Erneuerung klappt, nicht nur, ob sie eingerichtet ist.
- Die echte Client-IP per Proxy Protocol durchreichen – sonst sehen Rate-Limits, Allowlists und Logs nur die Adresse des Load Balancers.
- Das Body-Size-Limit bewusst setzen: NGINX erlaubt ohne Einstellung 1 MB pro Request (
client_max_body_size), größere Uploads enden mit 413.
Ressourcen und Daten: Wie viel Puffer, welche Backups?
Ressourcen und Skalierung
- Requests für jeden Container: Der Scheduler verteilt Pods nach Requests, nicht nach tatsächlichem Verbrauch.
- Memory-Limits mit Abstand zum Normalverbrauch: Wer das Limit überschreitet, riskiert einen OOM-Kill, ein CPU-Limit drosselt dagegen nur.
- Autoscaling braucht einen CPU-Request, denn der HPA rechnet in Prozent davon. Was keinen Ausfall verträgt, läuft mit mindestens zwei Replicas.
- Puffer im Node-Pool: Fällt ein Node aus, müssen seine Pods auf die übrigen passen.
Daten
- Datenbank-Backups und regelmäßig getestete Wiederherstellungen – ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung.
- Wiederherstellen in eine neue Datenbank, nicht über die laufende: So bleibt der Zustand vor dem Restore erhalten.
- Volume-Snapshots nach Zeitplan und vor jedem Löschen eines Volumes.
- Bucket-Backups in einem anderen Projekt und einer anderen Region; Versionierung im selben Bucket ist kein Backup.
Wie Fristen, Restore-Tests und Nachweise zusammenspielen, zeigt die Seite Backups & Wiederherstellung.
Sicherheit: Wer kommt an Cluster und Daten?
- RBAC mit eigenen Rollen statt einer Admin-Kubeconfig, die auf drei Laptops liegt.
- Nodes ohne öffentliche IP im privaten Netz, ausgehender Verkehr über ein Gateway.
- Der API-Server ist nur von erlaubten Adressen erreichbar.
- Network Policies: Ohne sie nimmt jeder Pod Verbindungen von jedem anderen an – und sie wirken nur mit einem Netzwerk-Plugin, das sie umsetzt.
- Least Privilege auch für Maschinen: CI-Tokens und Operatoren mit genau den nötigen Rechten und einem Ablaufdatum.
Wie Rollen, Tokens und Netzzugriff zusammenhängen, beschreibt die Seite Sicherheit & Zugriff.
Beobachtbarkeit und Upgrades: Wer merkt es zuerst?
Beobachtbarkeit
- Logs über die Lebensdauer eines Pods hinaus: Wird er ersetzt, ist sein Log weg. Eine zentrale Ablage wie Loki oder OpenSearch bewahrt es.
- Uptime-Checks von außen auf die echten Hostnamen – „Pod läuft“ heißt nicht „Seite erreichbar“.
- Alarme, die eine Person erreichen: im Team-Chat oder per E-Mail, einmal pro Ereignis. Ein Dashboard, das niemand offen hat, alarmiert niemanden.
Upgrades
- Kubernetes pflegt die letzten drei Minor-Versionen, jede rund ein Jahr lang. Version 1.34 erreicht am 27. Oktober 2026 ihr Supportende (Stand Oktober 2026).
- Minor-Upgrades in Ruhe planen, Version für Version, mit Blick auf entfernte APIs – nicht erst, wenn der Anbieter drängt.
- Add-ons haben eigene Lebenszyklen: Ingress NGINX bekommt seit März 2026 keine Releases und keine Sicherheitsupdates mehr.
Wie ein Kapsule-Cluster ohne Schrecken aktuell bleibt, zeigt die Seite Cluster-Updates.
Wem gehört der Cluster um zwei Uhr nachts?
Die Punkte oben sind Technik. Der letzte Bereich ist Organisation – und der häufigste Grund, warum ein sauber gebauter Cluster nach einem Jahr verwildert.
- Mindestens zwei Personen können deployen, zurückrollen und einen Restore starten.
- Runbooks für die fünf häufigsten Störungen sind aufgeschrieben, bevor sie passieren.
- Ein Audit-Log zeigt, wer was wann geändert hat – auch, wenn es ein CI-Token war.
- Für Upgrades und Zertifikate ist benannt, wer sie verantwortet, auch während des Urlaubs.
Wie Clusterward einen Teil der Liste übernimmt
Auf Scaleway hakt Clusterward mehrere Punkte ab, ohne dass Sie sie selbst bauen. Neue Cluster entstehen mit Nodes ohne öffentliche IP und einem API-Server, der nur erlaubte Adressen annimmt; Proxy Protocol ist standardmäßig eingeschaltet. Images aus der Registry des Clusters werden per Digest ausgerollt, und jede frühere gesunde Version lässt sich wiederherstellen (Deployments). Secrets liegen verschlüsselt oder im Scaleway Secret Manager. Datenbank-Backups lassen sich in eine neue Datenbank zurückspielen, Volumes bekommen Snapshots nach Zeitplan, Buckets werden nachts gesichert und monatlich per Restore-Test geprüft. Uptime-Checks und Warnungen zu Wildcard-Zertifikaten erreichen per Webhook oder E-Mail eine Person, und das nächste Kubernetes-Minor-Upgrade läuft nach Ihrer Bestätigung.
Nicht abgedeckt: Logs über die Lebensdauer eines Pods hinaus, Canary-Deployments und ein Prometheus-Stack. Und die Runbooks schreibt Ihnen auch keine Software.
Fazit
Die Architektur-Grafik zeigt, wie Code in den Cluster kommt. Die Checkliste fragt, was passiert, wenn danach etwas schiefgeht. Gehen Sie sie einmal mit dem Team durch und markieren Sie jeden Punkt als „getestet“, „eingerichtet, nie getestet“ oder „fehlt“. Die mittlere Spalte ist meist die längste – und die gefährlichste.
Ihre Checkliste hat Lücken? Schreiben Sie uns, wie Ihr Cluster heute betrieben wird. Wir sagen Ihnen, welche Punkte zuerst dran sind. Frage stellen →
Quellen und weiterführende Links
Häufige Fragen
- Neun Bereiche: Deploy und Rollback, Konfiguration und Secrets, Netzwerk und TLS, Ressourcen und Skalierung, Daten mit getesteten Wiederherstellungen, Sicherheit, Beobachtbarkeit, Upgrades und Zuständigkeit. Jeder Punkt sollte nicht nur eingerichtet, sondern einmal ausprobiert sein – ein Rollback, ein Restore, ein Alarm, der wirklich bei einer Person ankommt.