Projekt · Kubernetes-Plattform
Kubernetes Platform Foundation – produktionsbereit eingerichtet
Ihre Teams sollen auf Kubernetes produktiv arbeiten, nicht erst das Fundament bauen. SKAFFON richtet die Plattform ein, weist Deployment und Wiederherstellung nach und übergibt sie standardisiert.
- GitOps mit Argo CD
- Deployment- und Restore-Test
- Übergabe mit Runbooks
01Projektauftrag
Ein Cluster, auf dem Ihre Teams am Montag ausliefern können
Die Kubernetes Platform Foundation ist ein abgegrenztes Projekt mit benannten Ergebnissen: Cluster-Basis, Auslieferung per GitOps, Zertifikate, Geheimnisverwaltung, Richtlinien, Backup, ein Deployment-Test und ein Wiederherstellungstest. Sie richtet sich an IT-Leitung und Plattformverantwortliche, die einen konkreten Projektauftrag suchen statt einer allgemeinen Beratung.
Das Projekt liegt zwischen drei Nachbarn. Ob und welches Kubernetes zu Ihnen passt, klärt die Kubernetes-Beratung. Ein Entwicklerportal mit Self-Service ist Platform Engineering. Den dauerhaften Betrieb übernimmt auf Wunsch Managed Kubernetes. Hier entsteht die geprüfte, wiederholbare Grundlage dazwischen.
02Zusammenspiel
Vom Commit bis zum Restore: der Weg durch die Plattform
Eine Änderung im Git-Repository läuft durch die Pipeline, Argo CD gleicht den Cluster ab, und die Baseline wird per Velero in einen Backup-Speicher gesichert.
03Baseline
Sieben Bausteine, je mit eigenem Abnahmetest
Die Werkzeuge sind unsere Standardvorschläge. Wo Ihre Umgebung andere Bausteine vorgibt, ersetzen wir sie im Entwurf; die Aufgaben bleiben.
| Aufgabe | Werkzeug (Standardvorschlag) | Was wir festlegen | Abnahmetest |
|---|---|---|---|
| Auslieferung | Argo CD: GitOps-Controller, der Live-Zustand mit dem Git-Zustand vergleicht und Abweichungen als „OutOfSync“ markiert | Repository-Struktur, Synchronisationsregeln, Rechte je Team | Änderung im Repository erscheint im Cluster; manuelle Abweichung wird erkannt |
| Zertifikate | cert-manager: stellt TLS-Zertifikate aus und erneuert sie vor Ablauf, aus Quellen wie Let's Encrypt oder privater PKI | Aussteller, Zuständigkeit für die Domain, Verhalten bei Ausfall des Ausstellers | Zertifikat wird ausgestellt und automatisch erneuert (im Test mit kurzer Laufzeit) |
| Geheimnisse | External Secrets Operator: holt Geheimnisse aus externen Speichern und legt sie als Kubernetes-Secrets ab | Welcher Geheimnisspeicher, Rotation, Zugriff je Namespace | Geheimnis im Speicher ändern führt zur Aktualisierung im Cluster; kein Geheimnis im Git |
| Richtlinien | Kyverno: Policy-Engine mit Prüfen, Ändern, Erzeugen und Bildprüfung | Mindestregeln (etwa keine privilegierten Container, Pflichtlabel, erlaubte Registries), Ausnahmeprozess | Verbotene Konfiguration wird abgelehnt (Negativtest je Regel) |
| Backup | Velero: sichert und stellt Kubernetes-Ressourcen und persistente Volumes wieder her, auch zur Migration auf andere Cluster | Was gesichert wird, Intervall, Ablageort, Aufbewahrung, Weg für Volume-Daten (abhängig vom Speichersystem) | Wiederherstellung in sauberem Cluster, Anwendung funktioniert |
| Zugriff | Rollenbasiert (RBAC), Anmeldung über Ihre Identitätsquelle | Rollen je Team, Notfallzugang | Zugriff ohne Rolle wird verweigert |
| Beobachtung | Metriken, Logs, Alarme; Ausbau siehe SRE und Observability | Mindest-Signale und Alarme | Testalarm erreicht die Bereitschaft |
Zu Sicherheitshärtung darüber hinaus: Kubernetes Security.
04GitOps
Der Soll-Zustand liegt in Git, nicht im Kopf eines Admins
Cluster und Umgebungen entstehen als Code, reproduzierbar je Umgebung (Infrastructure as Code). Den gewünschten Zustand der Anwendungen hält das Repository; Argo CD gleicht Cluster und Repository ab. Entscheidungen im Entwurf werden dokumentiert, offene Punkte benannt.
- Entwurf: Cluster-Topologie, Knotenpools, Netzwerk und Zugriffsmodell, Namespace- und Rollenkonzept, Update-Strategie
- Bereitstellung: je Umgebung aus Code, nicht aus Klickpfaden
- Auslieferung: Änderungen laufen über das Repository und lassen sich über Git zurückrollen
05Ablauf
Sieben Arbeitspakete vom Entwurf bis zur Übergabe
- 01
Entwurf
Ergebnis: EntscheidungenTopologie, Knotenpools, Netzwerk, Zugriffsmodell, Namespace- und Rollenkonzept, Update-Strategie. Offene Punkte werden benannt.
- 02
Bereitstellung als Code
Ergebnis: Umgebungen als CodeCluster und Umgebung per Infrastructure as Code, je Umgebung wiederholbar.
- 03
Plattform-Baseline
Ergebnis: StandardkomponentenDie Bausteine der Matrix oben, jeweils mit festgelegten Regeln.
- 04
Auslieferung per GitOps
Ergebnis: Git als QuelleArgo CD gleicht Cluster und Repository ab, Rechte sind je Team geregelt.
- 05
Deployment-Test
Ergebnis: Pipeline nachgewiesenEine Beispielanwendung wird über die vorgesehene Pipeline ausgeliefert.
- 06
Backup- und Restore-Test
Ergebnis: Restore belegtDie Wiederherstellung in eine saubere Umgebung wird durchgespielt und die Dauer festgehalten.
- 07
Standardisierte Übergabe
Ergebnis: ÜbergabeprotokollRunbooks, Architekturdokumentation, Einweisung und Übergabeprotokoll. Weiterbetrieb in Ihrem Team oder bei SKAFFON.
Abnahme
„Produktionsbereit“ gilt erst nach bewiesener Wiederherstellung
Backup und Wiederherstellung werden nicht angenommen, sondern getestet. Die Dauer der Wiederherstellung halten wir fest und vergleichen sie mit Ihrer Vorgabe; die Zahlen dafür legen Sie fest, wir weisen nach, ob die gebaute Lösung sie einhält.
Backup und Disaster Recovery06Abnahmedrehbuch 1
Deployment-Test: fünf Schritte vom Commit bis zum Rollback
- Beispielanwendung im Git-Repository ablegen, Pipeline läuft durch
- Argo CD synchronisiert; Anwendung erreichbar, TLS-Zertifikat gültig
- Geheimnis aus dem externen Speicher wird von der Anwendung gelesen
- Verbotene Variante (zum Beispiel privilegierter Container) wird von der Richtlinie abgelehnt
- Änderung zurückrollen: Zustand kehrt über Git zur Vorversion zurück
07Abnahmedrehbuch 2
Restore-Test: Namespace löschen, aus dem Backup zurückholen
- Beispielanwendung mit Daten im persistenten Volume erzeugen
- Backup anstoßen und Abschluss prüfen
- Anwendung und Namespace löschen (im Testcluster)
- Wiederherstellen in einen sauberen Cluster oder Namespace
- Daten und Funktion prüfen; Dauer der Wiederherstellung festhalten und mit Ihrer Vorgabe vergleichen
- Ergebnis im Übergabeprotokoll festhalten
08Zielumgebung
Wo die Plattform laufen kann
Die Wahl treffen Sie vorher oder gemeinsam mit uns.
-
STACKIT SKE
Verwaltetes Kubernetes auf STACKIT.
-
Verwaltetes Kubernetes eines Hyperscalers
Die Baseline-Aufgaben bleiben, die Bausteine passen wir an die Umgebung an.
-
Eigene Cluster auf Proxmox
Cluster auf Ihrer eigenen Virtualisierung.
-
Bare metal
Zum Beispiel mit Talos Linux und Omni.
09Eingaben
Was wir von Ihnen vor dem Entwurf brauchen
- Die ersten Anwendungen und ihre Anforderungen (Zustand, Speicher, Zugriff von außen)
- Identitätsquelle für die Anmeldung am Cluster
- Git-Plattform und CI/CD-Umgebung
- Anforderungen an Backup, Wiederherstellungszeit und Aufbewahrung
- Wer das Cluster danach betreibt: Ihr Team, SKAFFON oder geteilt
- Zielumgebung, falls schon entschieden
10Grenzen
Was die Foundation liefert und was bewusst nicht dazugehört
Das gehört dazu
- Rollenbasierte Zugriffe für den Aufbau, mit Ihnen abgestimmt und nach Projektende zurückgenommen.
- Geheimnisse im externen Speicher, nicht im Repository.
- Test von Deployment, Backup und Wiederherstellung als Teil der Abnahme.
Das gehört nicht dazu
- Ein Sicherheitsnachweis: Die Baseline ist eine Grundlage. Zusätzliche Anforderungen, etwa aus NIS2, werden gesondert bewertet.
- Ihre Anwendungen: Die Containerisierung bestehender Software behandelt Containerisierung.
- Der laufende Betrieb. Die Foundation ist ein Projekt; wer danach Updates, Alarme und Störungen übernimmt, klären wir vor dem Entwurf (Ihr Team oder Managed Kubernetes).
- Die Grundsatzfrage, ob Sie Kubernetes überhaupt wollen: Beginnen Sie mit der Kubernetes-Beratung.
Scoping
Zielumgebung, erste Anwendungen, Wiederherstellungsziel: das genügt für den Start
Nennen Sie uns diese drei Punkte und wer danach betreibt. Das Angebot entsteht nach einem Scoping-Gespräch, mit Phasen, Ergebnissen und Annahmen.