Kubernetes-Checkliste: produktionsreif?
Diese Checkliste stellt vierundzwanzig Aussagen über einen Cluster auf, der bereits in Produktion läuft — geordnet nach den acht Bereichen, mit denen wir „produktionsreif“ definieren. Ihr hakt ab, was heute stimmt. Neben jeder Aussage, die offen bleibt, steht der erste Schritt, den ihr ohne Budget und ohne uns gehen könnt.
Direkt herunterladen, kein Formular, keine E-Mail-Adresse. Und was ihr auf dieser Seite anklickt, bleibt im Browser: Wir erfahren, dass die Liste benutzt wurde, nicht was darin steht.
Für wen sie gedacht ist
Für die Menschen, die den Cluster betreiben, und für die, die dafür geradestehen: Plattform- und Betriebsteams, technische Leitung, und wer entscheiden muss, ob die nächste Anwendung schon dorthin darf. Geht sie zu zweit oder zu dritt durch — jemand aus dem Betrieb, jemand aus der Entwicklung, und die Person, die im Ernstfall nachts geweckt wird.
So benutzt ihr sie
Hakt nur ab, was heute schon so ist — nicht, was im Ticket steht, geplant ist oder in einem Repository liegt, das seit Monaten niemand angefasst hat. Antwortet für die Produktion, nicht für die beste Umgebung, die ihr habt. Bei Uneinigkeit gilt eine Aussage als offen: Dass zwei Leute sie unterschiedlich beantworten, ist selbst schon ein Befund.
Was von eurer Version abhängt
Stand:
Einige Punkte hängen an der Kubernetes-Version, die ihr fahrt: APIs verschwinden mit Minor-Versionen, und was in einer Version noch funktioniert, ist in der nächsten entfernt. Die Hinweise auf dieser Seite sagen deshalb, wann sich etwas geändert hat — nicht, welche Version heute noch Patches bekommt. Diese Frage beantwortet die Release-Seite des Projekts, und sie beantwortet sie aktueller, als eine Seite von uns es je könnte. Das Datum bei jedem Hinweis ist der Stand unserer letzten fachlichen Prüfung.
Wie diese Liste geprüft wurde
Die Punkte kommen aus dem Betrieb von Clustern in Produktion und sind gegen die veröffentlichte Dokumentation des Projekts gegengelesen; die Quellen stehen darunter. Geprüft hat sie die Person, die auch die Arbeit macht — ein externes Gremium war daran nicht beteiligt, und die Liste ist kein Standard, sondern unser Maßstab. Wenn ihr einen Punkt für falsch haltet, schreibt uns: Eine begründete Korrektur ändert die Liste.
Die Checkliste
Upgrades sind geplante Arbeit
Wenn das offen istSchreibt Cluster-Version und Support-Ende in dasselbe Dokument wie eure anderen Fristen. Bei einem verwalteten Angebot gilt zusätzlich dessen eigener Zeitplan — der ist meistens der frühere von beiden.
VersionshinweisStand: Das Projekt veröffentlicht etwa alle vier Monate eine Minor-Version und versorgt jede davon rund vierzehn Monate mit Patches. Anbieter verwalteter Cluster setzen eigene Fristen darüber, oft kürzere.
Wenn das offen istLasst pluto oder kubent einmal gegen euren aktuellen Stand laufen. Was dabei herauskommt, ist die Arbeitsliste für das nächste Upgrade, und sie wird nicht kürzer, wenn ihr wartet.
VersionshinweisStand: APIs verschwinden mit Minor-Versionen: PodSecurityPolicy, policy/v1beta1 PodDisruptionBudget und batch/v1beta1 CronJob sind mit 1.25 entfernt worden. Was eure Zielversion streicht, steht in deren Migrationshinweisen.
Wenn das offen istSchreibt eure Add-ons auf — CNI, Ingress-Controller, cert-manager, CSI-Treiber, Monitoring — und daneben, welche Cluster-Versionen sie unterstützen. Die kürzeste Spanne bestimmt euren Upgrade-Pfad, nicht der Cluster selbst.
Der Sollzustand steht in Git
Wenn das offen istVergleicht einmal, was im Cluster läuft, mit dem, was im Repository steht. Was abweicht, ist entweder Drift oder eine Absicht, die niemand aufgeschrieben hat — beides gehört auf dieselbe Liste.
Wenn das offen istSchaltet die Drift-Anzeige eures Auslieferungswerkzeugs ein und legt fest, wer sie ansieht. Eine Anzeige, für die niemand zuständig ist, ist keine Anzeige.
Wenn das offen istSucht im Repository nach Secret-Manifesten mit eingebetteten Werten. Wenn ihr fündig werdet, ist der erste Schritt nicht die Rotation, sondern die Entscheidung, woher Secrets künftig kommen.
Wiederherstellung ist geprobt
Wenn das offen istPlant das Leeren eines Nodes in einer Nebenzeit und schaut zu. Wenn dabei ein Dienst wegbricht, fehlen ihm mehrere Replicas, ein PodDisruptionBudget oder die Verteilung über Ausfallzonen.
Wenn das offen istNehmt die jüngste Sicherung und stellt einen einzelnen Namespace in einer Testumgebung wieder her. Wie lange das dauert, ist eure tatsächliche Wiederanlaufzeit — alles andere ist eine Schätzung.
Wenn das offen istGeht eure StatefulSets und PersistentVolumeClaims durch und schreibt neben jedes, wer die Daten sichert und wohin. Was leer bleibt, ist ungesichert, egal wie oft der Cluster gesichert wird.
Zugriff ist beantwortbar
Wenn das offen istZählt, wie viele kubeconfig-Dateien mit administrativen Rechten im Umlauf sind. Jede davon ist ein Zugang ohne Namen, und beim Austritt einer Person bleibt er bestehen.
Wenn das offen istListet die Bindings auf die Administratorrolle auf und schreibt neben jedes, warum es existiert. Was sich nicht begründen lässt, ist der erste Kandidat zum Entfernen.
Wenn das offen istSetzt Pod Security Admission zuerst im Warn-Modus auf einen Namespace und lest mit, was anschlägt. Erst wenn die Liste kurz ist, wird durchgesetzt.
VersionshinweisStand: PodSecurityPolicy ist mit 1.25 entfernt worden; Pod Security Admission ist der eingebaute Nachfolger. Wer damals nur die alte Vorgabe abgeschaltet hat, hat an dieser Stelle heute meistens gar keine mehr.
Observability beantwortet Fragen
Wenn das offen istNehmt euren wichtigsten Dienst und beantwortet mit den vorhandenen Anzeigen die Frage, ob er gerade für die Nutzer funktioniert. Wenn ihr dafür mehrere Dashboards braucht, fehlt genau eine Anzeige.
Wenn das offen istSucht den letzten Vorfall in euren Logs, ohne euch auf einen Node zu verbinden. Wo das nicht geht, fehlt entweder die Sammlung oder die Aufbewahrung — beides merkt man immer erst hinterher.
Wenn das offen istVergleicht für zwei, drei Workloads die angeforderten Ressourcen mit dem tatsächlichen Verbrauch. Der Abstand erklärt eure Cloud-Rechnung und euer Scheduling gleichzeitig.
Jeder Alarm hat einen Empfänger
Wenn das offen istGeht die Alarmregeln durch und streicht die, auf die im letzten Vierteljahr niemand reagiert hat. Das ist kein Verlust an Sicherheit, sondern das Ende einer Gewöhnung.
Wenn das offen istZählt die Alarme der letzten Bereitschaftswoche und markiert, welche zu einer Handlung geführt haben. Das Verhältnis sagt euch, ob eure Bereitschaft arbeitet oder nur wach ist.
Wenn das offen istFragt die nächste Person in der Bereitschaft, was sie beim Ausfall eures Ingress-Controllers zuerst tut. Wenn die Antwort ein Name ist und kein Handgriff, fehlt das Runbook.
Workloads kommen über einen dokumentierten Weg
Wenn das offen istSchreibt auf, was beim letzten Onboarding tatsächlich passiert ist, und macht daraus eine Vorlage. Der zweite Durchlauf zeigt euch, was in der ersten Fassung gefehlt hat.
Wenn das offen istSucht die Deployments ohne Ressourcenanforderungen. Ohne sie plant der Scheduler blind, und die erste Lastspitze verteilt die Folgen zufällig über eure Nodes.
Wenn das offen istSchaut euch die Container mit den meisten Neustarts an. Eine Liveness-Probe, die auf eine überlastete Abhängigkeit anspringt, verstärkt eine Störung, statt sie zu beheben.
Mindestens zwei Personen können es
Wenn das offen istNehmt den Handgriff, bei dem euch die Antwort am schwersten fällt, und lasst ihn in den nächsten zwei Wochen von der zweiten Person ausführen, mit der ersten daneben.
Wenn das offen istLasst die nächste kleine Störung von jemandem bearbeiten, der das Runbook nicht kennt, mit der erfahrenen Person als Zuschauer. Die Rückfragen sind eure Lücken.
Wenn das offen istLegt eine Seite mit diesen vier Angaben an und schreibt sie beim nächsten Upgrade fort. Wenn sie beim übernächsten immer noch stimmt, habt ihr keinen Zettel, sondern einen Vorgang.
Was bei euch offen ist
— / 24 offene Punkte
Alle Kästchen sind angehakt. Diese Liste findet bei euch nichts mehr — das ist etwas anderes als produktionsreif. Was hier fehlt, sind die Fragen, die man erst mit Blick in den Cluster stellen kann.
Die Auswertung entsteht in eurem Browser. Wir erfahren, dass jemand die Liste durchgegangen ist, nie welche Punkte offen sind — und ihr bekommt kein Zertifikat, sondern eine Arbeitsliste.
Wie ihr das Ergebnis lest
Gezählt werden die offenen Punkte, nicht die abgehakten. Wichtiger als die Summe ist, wo sie sitzen: Drei offene Punkte bei der Wiederherstellung wiegen schwerer als drei über acht Bereiche verteilt, weil sie zusammen einen Ausfall beschreiben, aus dem ihr nicht wieder herauskommt.
0 bis 3 offen
Einzelne Lücken, meist an einer Stelle. Das ist Instandhaltung: Nehmt die offenen Punkte einzeln, in der Reihenfolge der Bereiche. Und lest den Absatz darunter — eine leere Liste heißt nicht produktionsreif.
4 bis 10 offen
Ein erkennbares Muster. Schaut zuerst nach, ob die offenen Punkte in einem oder zwei Bereichen zusammenliegen. Dann gibt es meistens eine gemeinsame Ursache, und die zu beheben ist billiger als zehn Einzelmaßnahmen.
11 und mehr offen
Der Cluster läuft, aber er trägt noch nichts. Hier entscheidet die Reihenfolge: erst der Weg zurück — Wiederherstellung, Rollback, Zugriff — dann der Weg nach vorn. Wer zuerst automatisiert, automatisiert einen Zustand, den er nicht wiederherstellen kann.
Was sie nicht leistet
Diese Liste ist kein Audit, kein Zertifikat und keine Freigabe. Sie sieht euren Cluster nicht, kennt eure Last nicht und weiß nicht, welchen Ausfall ihr euch leisten könnt — sie kennt nur, was ihr anklickt. Alle Kästchen angehakt heißt: Diese Fragen finden nichts mehr. Es heißt nicht, dass euer Cluster produktionsreif ist, denn die Fragen, die hier fehlen, sind genau die, die man ohne Blick in die Umgebung nicht stellen kann.
Passende Engineering-Leistungen
Manifeste, Rollen, Alarme, Sicherungen und Deployments gehören zur Kubernetes-Beratung. Nutzt die ersten Schritte neben den Aussagen selbstständig. Für offene technische Fragen könnt ihr uns direkt kontaktieren.
Offen geblieben, wo es weh tut?
Schickt uns die Bereiche, in denen die meisten Kästchen leer geblieben sind, dazu zwei Sätze über euren Cluster. Ihr bekommt eine Einschätzung, was zuerst dran ist — und ob ihr uns dafür überhaupt braucht.