Kubernetes Platform Build

Wann ein Build der richtige Schritt ist

• Eine Migration in die Cloud ist beschlossen, und niemand im Haus hat je eine Plattform gebaut, die danach jemand betreiben muss.
• Ein Cluster ist irgendwann entstanden, trägt inzwischen Produktion, und niemand traut sich, ihn neu aufzubauen.
• Jedes Team baut sich seinen eigenen Weg in die Produktion, und keine zwei sehen gleich aus.
• Kubernetes ist gesetzt — vom Konzern, vom Kunden oder von der Regulierung —, und ihr wollt nicht bei null anfangen.
• Der Betrieb hängt an einer Person, die alles im Kopf hat. Ihr wollt das auflösen, bevor sie geht.
• Zugänge werden von Hand vergeben, Secrets liegen im Klartext in Repositories, und niemand kann sagen, wer heute auf die Produktion kommt.
• Ihr wollt die Plattform fertig haben, bevor die erste Anwendung migriert wird — nicht nebenbei während der Migration.

Wann er es nicht ist

• Ihr habt bereits eine Plattform, sie klemmt nur bei der Auslieferung. Dann ist der Platform Recovery Sprint der kürzere Weg.
• Ihr betreibt eine Anwendung mit einem Team. Dann ist eine Managed Runtime beim Cloud-Anbieter der ehrlichere Vorschlag als ein eigener Cluster.
• Ihr wisst noch nicht, ob Kubernetes für euch das richtige Werkzeug ist. Das klärt eine Analyse in Tagen, nicht ein Build in Wochen.
• Ihr sucht jemanden, der die Plattform dauerhaft betreibt. Wir übergeben am Ende — darauf ist der ganze Zuschnitt ausgelegt.
• Es gibt niemanden, der die Plattform nach der Übergabe übernimmt. Dann bauen wir etwas, das nach zwölf Wochen niemandem gehört.

Wenn die Plattform bereits steht und nur die Auslieferung klemmt, ist der kürzere Weg woanders beschrieben: Zum Recovery Sprint

Dauer und Umfang

Dauer

12 Wochen mit festem Start- und Endtermin, in vier Abschnitten zu je drei Wochen. Darin liegen 36 Tage unserer Arbeitszeit, verteilt auf drei Tage pro Woche. Die übrige Zeit gehört eurem Team: es entscheidet, reviewt und übernimmt.

Umfang

Gebaut wird genau eine Plattform: 2 Umgebungen — eine vor der Produktion und die Produktion selbst — und 2 Workloads aus euren Teams, die darauf laufen. Den ersten schalten wir gemeinsam auf, den zweiten schaltet euer Team nach der schriftlichen Anleitung selbst auf. Was zum Umfang gehört, steht unten Baustein für Baustein; was nicht dazugehört, steht genauso ausdrücklich daneben.

Was gebaut wird — und woran ihr es prüft

„Produktionsreif“ ist hier keine Eigenschaft, sondern eine Liste: 10 Bedingungen, je eine pro Baustein. Jede ist am letzten Tag wahr oder falsch, und jede wird vorgeführt, geprobt oder gemessen — keine gilt, weil ein Dokument sie behauptet. 9 der 10 prüft euer Team, nicht wir.

1. Cluster-Grundlage

   vorgeführtwir prüfen gemeinsamgeprüft in Abschnitt 1 · Woche 1–3

   Ergebnis: Beide Umgebungen vollständig als Code: Netzwerk, Node-Pools, Ingress, Zertifikate, Backups, Cluster-Upgrades. Kein Klick, den niemand nachvollziehen kann.

   Produktionsreif, wenn: Ein Cluster wird im Build einmal aus dem Repository in einem leeren Konto neu aufgebaut — nicht behauptet, sondern gemeinsam vorgeführt.

2. Identitäten und Zugriff

   vorgeführteuer Team prüftgeprüft in Abschnitt 1 · Woche 1–3

   Ergebnis: Zugriff auf Cluster und Plattformwerkzeuge über euren Identity Provider: Gruppen statt persönlicher Sonderrechte, Rollen je Umgebung, ein dokumentierter Notfallzugang.

   Produktionsreif, wenn: Wer im Identity Provider aus einer Gruppe entfernt wird, verliert damit den Cluster-Zugriff. Einmal an einer echten Person vorgeführt, von euch.

3. GitOps

   vorgeführteuer Team prüftgeprüft in Abschnitt 1 · Woche 1–3

   Ergebnis: Ein Repository, aus dem der Zustand beider Umgebungen abgeglichen wird, mit Review-Pflicht, nachvollziehbarer Historie und einem Weg zurück auf den vorherigen Stand.

   Produktionsreif, wenn: Eine von Hand am Cluster vorbei gemachte Änderung wird zurückgesetzt, eine gemergte Änderung kommt an. Beides führt ihr einmal selbst vor.

4. Secret Management

   geprobteuer Team prüftgeprüft in Abschnitt 2 · Woche 4–6

   Ergebnis: Ein Weg für Secrets von der Quelle bis in den Pod, ohne Klartext im Repository, mit einem Rotationsverfahren, das aufgeschrieben ist.

   Produktionsreif, wenn: Euer Team rotiert im Build ein Secret, während die Workloads laufen — nach dem Verfahren, ohne uns an der Tastatur.

5. Observability

   gemesseneuer Team prüftgeprüft in Abschnitt 2 · Woche 4–6

   Ergebnis: Logs, Metriken und Alarme für die Cluster und für die aufgeschalteten Workloads, mit Dashboards, für die eine Person zuständig ist.

   Produktionsreif, wenn: Ein ausgelöster Testalarm erreicht die benannte Bereitschaft über den vereinbarten Weg, und die Metriken des betroffenen Workloads sind in derselben Sitzung auffindbar.

6. Sicherheitskontrollen

   vorgeführteuer Team prüftgeprüft in Abschnitt 2 · Woche 4–6

   Ergebnis: Grundregeln im Cluster: Trennung nach Namespaces, Netzwerkregeln, Pod-Sicherheitsstandards, Herkunft der Images, regelmäßige Updates der Basis-Images.

   Produktionsreif, wenn: Ein Deployment, das gegen die Grundregeln verstößt, wird vom Cluster abgelehnt — nicht von einem Review. Mit einem absichtlich fehlerhaften Manifest gezeigt.

7. Workloads aufschalten

   vorgeführteuer Team prüftgeprüft in Abschnitt 3 · Woche 7–9

   Ergebnis: Der Weg, den danach jeder Workload nimmt: Repository-Vorlage, Pipeline, Deployment-Manifeste, Alarme — dazu die schriftliche Anleitung, an der entlang ein Team das ohne uns tun kann.

   Produktionsreif, wenn: Den zweiten Workload schaltet euer Team nach dieser Anleitung selbst auf. Wir sehen zu und greifen nicht ein; was dabei fehlt, wird an der Anleitung repariert.

8. Runbooks

   geprobteuer Team prüftgeprüft in Abschnitt 3 · Woche 7–9

   Ergebnis: Runbooks für die Fälle, die euch treffen werden: Node fällt aus, Zertifikat läuft ab, Deployment muss zurück, Cluster-Upgrade, Wiederherstellung aus dem Backup.

   Produktionsreif, wenn: Jedes Runbook wird im Build einmal von eurem Team ausgeführt, die Wiederherstellung aus dem Backup gegen eine echte Umgebung.

9. Schulung

   geprobteuer Team prüftgeprüft in Abschnitt 4 · Woche 10–12

   Ergebnis: Vier Termine für die Menschen, die die Plattform danach betreiben: Cluster-Grundlagen, der Weg einer Änderung, Alarme und Bereitschaft, Upgrade und Wiederherstellung — an eurer Plattform, nicht an Beispielen.

   Produktionsreif, wenn: Jede Person, die danach Bereitschaft hat, hat die Übungen an eurer Plattform selbst durchgeführt. Zusehen zählt nicht.

10. Übergabe der Verantwortung

    vorgeführteuer Team prüftgeprüft in Abschnitt 4 · Woche 10–12

    Ergebnis: Eine Verantwortlichkeitskarte: jeder Baustein mit benannter Person, Vertretung und Eskalationsweg, bestätigt von genau diesen Personen — dazu das schriftliche Restbacklog mit Begründung.

    Produktionsreif, wenn: Unsere Zugänge werden am letzten Tag entzogen, und die Plattform läuft weiter. Jeder Baustein hat eine Person, die die Zuordnung bestätigt hat.

Was nicht enthalten ist

Diese Liste ist so verbindlich wie die obere. Jeder Punkt sagt, was stattdessen passiert — damit ihr wisst, was nach dem Build noch offen ist.

Was ihr mitbringt

Was hier „vor dem Start“ trägt, muss vorliegen, bevor wir anfangen. Kommt es später, verschiebt sich der Starttermin — der Build verkürzt sich nicht.

• vor dem Start

  Ein Cloud-Konto, das euch gehört, mit einem Kostenrahmen, den ihr verantwortet, und Zugängen für uns ab dem ersten Tag.

• vor dem Start

  Einen vorhandenen Identity Provider — Entra ID, Google Workspace, Okta oder gleichwertig — und jemanden, der darin Gruppen anlegen darf.

• vor dem Start

  Eine benannte Person, der die Plattform nach der Übergabe gehört und die vom ersten Tag an mitarbeitet. Ohne sie fangen wir nicht an.

• vor dem Start

  Entscheidungen zu Netz und Namen: Adressbereiche, Anbindung an eure bestehenden Systeme, DNS-Zonen, die ihr selbst verwalten könnt.

• vor dem Start

  Etwa einen Tag pro Woche je beteiligtem Teammitglied, für Entscheidungen, Reviews und die Übungen. Ohne diese Zeit bleibt das Ergebnis bei uns.

• bis Abschnitt 2

  Eure Sicherheits- und Compliance-Vorgaben, schriftlich — oder eine Person, die sie im zweiten Abschnitt entscheiden darf.

• bis Abschnitt 3

  Zwei Workloads, benannt beim Zuschnitt, mit Teams, die im dritten Abschnitt Zeit haben. Der zweite wird von diesem Team selbst aufgeschaltet.

• bis Abschnitt 4

  Eine Entscheidung, wer nach der Übergabe Bereitschaft hat. Sie muss nicht am ersten Tag stehen, aber vor dem vierten Abschnitt.

Die zwölf Wochen

1. Abschnitt 1 · Woche 1–3

   Zugänge, offene Entscheidungen, Cluster-Grundlage, Identitäten und GitOps. Am Ende steht die Plattform als Code, und eine Änderung kommt nur noch über einen Pull Request hinein.

2. Abschnitt 2 · Woche 4–6

   Secrets, Observability und die Sicherheitskontrollen. Am Ende ist sichtbar, was auf der Plattform passiert, und was gegen die Grundregeln verstößt, kommt nicht mehr durch.

3. Abschnitt 3 · Woche 7–9

   Der erste Workload gemeinsam, der zweite von eurem Team allein — und die Runbooks, jedes einmal durchgespielt statt nur geschrieben.

4. Abschnitt 4 · Woche 10–12

   Schulung, Verantwortlichkeiten und der Durchgang durch alle Bedingungen, eine nach der anderen. Am letzten Tag werden unsere Zugänge entzogen.

Preis

Fester Preis für festen Umfang, kein Tagessatz: ein Build, der nach Aufwand abgerechnet wird, hat keinen festen Umfang mehr. Eine Preisliste veröffentlichen wir nicht — den Preis nennen wir im Angebot, zusammen mit dem Zuschnitt, bevor ihr euch festlegt. Cloud- und Lizenzkosten laufen getrennt über euer Konto.

Was danach kommt

Danach gibt es drei ehrliche Möglichkeiten: ihr macht allein weiter — das ist der Normalfall und der Zweck der Übergabe; ihr schaltet weitere Workloads auf und wir begleiten die ersten davon; oder ihr holt euch technische Führung auf Zeit ins Team. Keine dieser Möglichkeiten ist Teil des Builds, und keine ist Voraussetzung dafür, dass er funktioniert.

Ehrlich gesagt: Auf dieser Seite steht keine Zahl aus einem früheren Plattformaufbau. Dieses Angebot ist neu zugeschnitten, und was wir vorher gebaut haben, wurde nie so gemessen, dass es hier etwas beweisen würde. Woran wir gearbeitet haben, steht in den Referenzen — ohne Kennzahlen, weil wir sie nicht erhoben haben.