STACKIT · Kubernetes Engine (SKE)
Managed Kubernetes auf STACKIT SKE
SKE nimmt Ihnen die Control Plane ab, nicht den Betrieb darüber. SKAFFON baut und betreibt die Schicht aus Zonen-Layout, GitOps, Add-ons, Monitoring und Recovery.
- Control Plane verwaltet und hochverfügbar
- Cluster als Code, Auslieferung per GitOps
- Betrieb rund um die Uhr (24/7) auf Wunsch
01Ausgangslage
Der Cluster läuft, und trotzdem fehlt jemand, der ihn betreibt
SKAFFON richtet Kubernetes-Cluster auf der STACKIT Kubernetes Engine (SKE) ein und betreibt sie auf Wunsch dauerhaft: Zugriffsmodell, GitOps, Add-ons, Monitoring, Backup und Updates. Die Seite richtet sich an Plattformverantwortliche und IT-Leitung, die SKE einsetzen oder einführen und klären wollen, was STACKIT erledigt, was bei Ihnen bleibt und was ein Dienstleister übernehmen kann.
Laut STACKIT-Dokumentation ist die Control Plane der Cluster verwaltet und hochverfügbar. Kubernetes- und Betriebssystemversionen werden automatisch aktualisiert, Probleme automatisch behoben, Pods und Nodes lassen sich automatisch skalieren, und Cluster können zeitgesteuert in den Ruhezustand versetzt werden. Angelegt werden sie über Portal, API, STACKIT CLI oder den Terraform Provider.
Offen bleiben die Dinge oberhalb der Control Plane: wer ein Update freigibt, welche Add-ons laufen und wer sie pflegt, wie Anwendungen ausgeliefert werden, was bei einem Zonenausfall mit den Volumes passiert und wer nachts auf einen Alarm reagiert. Genau diese Schicht bauen und betreiben wir.
02Verantwortung
Was SKE erledigt und was bei Ihnen bleibt
Die Spalte „STACKIT / SKE“ beschreibt, was die Produktdokumentation (Stand der Prüfung: 13.11.2026) als Verhalten der Plattform ausweist. Die Spalte „SKAFFON“ gilt nur bei beauftragtem Betrieb. Die endgültige Aufteilung legt der Vertrag fest.
| Aufgabe | STACKIT / SKE | Kunde | SKAFFON (bei Betrieb) |
|---|---|---|---|
| Control Plane betreiben | verwaltet, hochverfügbar | I | I |
| Patch-Updates von Kubernetes | automatisch im Wartungsfenster, wenn eine unterstützte Version vorliegt | Wartungsfenster festlegen | Fenster vorschlagen, Ergebnis prüfen |
| Minor-Upgrade (z. B. 1.x auf 1.y) | nur manuell angestoßen; Pflichtupdate, wenn eine Version ausläuft | Freigabe | Breaking Changes prüfen, Upgrade durchführen, Add-ons nachziehen |
| Betriebssystem-Updates der Nodes | rollierender Austausch der Nodes | Freigabe | Wirkung auf Workloads und PodDisruptionBudgets prüfen |
| Node-Pools, Zonen, Größen festlegen | stellt Optionen bereit | Anforderungen | Entwurf und Umsetzung als Code |
| Add-ons (Ingress, cert-manager, Monitoring, Backup) | nicht Teil von SKE | Anforderungen | Auswahl, Installation, Pflege |
| Auslieferung der Anwendungen (GitOps) | nicht Teil von SKE | Manifeste und Charts der Anwendungen | GitOps-Plattform betreiben |
| Zugriffsmodell (Rollen, Service Accounts) | stellt Mechanismen bereit | fachliche Entscheidung, wer was darf | technische Umsetzung |
| Backup und Restore-Test | stellt Velero-Anleitung bereit | Datenverantwortung | einrichten, Restore regelmäßig testen |
| Störung im Workload | nicht zuständig | R/A | konsultiert |
| Verträge, Verfügbarkeitszusagen, Support für die Plattform | Vertrag mit STACKIT | Vertragspartner | nicht beteiligt |
Die Matrix ist abgeleitet aus der STACKIT-Dokumentation zu Updates, Wartungsfenstern und Topologie. Das Upgrade-Verfahren im Detail beschreibt Managed Kubernetes.
Updates
Kein Downgrade: Der Rückweg ist ein gesicherter Zustand
Zwei Punkte aus der Dokumentation zu Version-Updates prägen die Planung. SKE kann nicht garantieren, dass ein gestarteter Wartungsvorgang innerhalb des Wartungsfensters endet; bei großen Clustern kann das Stunden dauern. Und Kubernetes-Downgrades sind nicht unterstützt. Ein Rückweg ist deshalb ein gesicherter Zustand (Backup, vorab aufgebautes Cluster), nicht ein Rückschritt der Version.
03Topologie
Ein Node-Pool über drei Verfügbarkeitszonen
Region eu01 (Deutschland) und eu02 (Österreich) haben laut STACKIT-Regionsdokumentation jeweils mindestens drei physisch getrennte Verfügbarkeitszonen.
04Pool-Layout
Zonen und Volumes: Was sich später nicht mehr korrigieren lässt
Ein Node-Pool kann eine oder mehrere Zonen umfassen. Das konfigurierte Maximum der Nodes muss mindestens der Zahl der gewählten Zonen entsprechen, und Zonen lassen sich einem bestehenden Pool hinzufügen, aber nicht wieder entfernen (Topologien). Das hat Folgen für den Entwurf.
- Anwendungen mit eigener Hochverfügbarkeit (zum Beispiel Datenbank-Operatoren mit Replikaten) verteilen wir über Zonen mit Pod Topology Spread Constraints.
- Volumes lassen sich nicht an Nodes anderer Zonen anhängen. Anwendungen ohne eigene HA, die persistente Volumes brauchen, gehören laut Dokumentation in die Metro-Zone (eu01-m), die synchrone Speicherreplikation über die Zonen bietet.
- Pool-Layouts entwerfen wir vor dem ersten Cluster, weil das spätere Entfernen einer Zone einen neuen Pool und Volume-Migration bedeutet.
05Plattform
Sieben Bausteine, die aus einem SKE-Cluster eine Plattform machen
-
GitOps mit Argo CD
Der gewünschte Zustand liegt im Git-Repository; Änderungen laufen über Pull Requests. Einführung: GitOps mit Argo CD.
-
Helm und Add-ons
Ingress, cert-manager für Zertifikate, die Monitoring-Komponenten und Backup werden als versionierte Charts ausgeliefert. Welche Add-ons Sie brauchen, hängt von Ihrer Plattform ab; wir installieren nur, was begründet ist.
-
Identität und Zugriff
SKE bietet Anleitungen zu Zugriffskontrolle, Workload Identity, Rotation von Zugangsdaten und Audit-Logging des Clusters. Für Automatisierung empfiehlt die STACKIT-Dokumentation Service Accounts mit föderierter Identität statt statischer Schlüssel; wir setzen das so um.
-
Netzwerk
Private Cluster, Load Balancer mit bestehenden Public IPs, ALB-Ingress und Netzwerkbereiche sind dokumentierte Optionen. Das Netzwerkmodell folgt der Landing Zone.
-
Monitoring
Prometheus und Grafana im Cluster oder Anbindung an STACKIT Observability über OpenTelemetry; beides ist in der SKE-Dokumentation beschrieben. Betrieb und Alarmierung: Managed Monitoring und Observability.
-
Recovery
Velero-Backups von Cluster-Ressourcen und Volumes, mit regelmäßigem Restore-Test. Datenbanken sichern wir nicht per Volume-Snapshot, sondern mit dem Verfahren der Datenbank, siehe Datenbanken auf STACKIT.
-
Bootstrap mit kubara
STACKIT verweist für den Aufbau einer Plattform auf SKE auf das Werkzeug kubara. Ob es für Ihr Vorhaben passt, bewerten wir im Entwurf; es ist keine Voraussetzung.
06Verfügbarkeit
Was die 99,9 % von STACKIT abdecken und was nicht
STACKIT beschreibt die Control Plane als „managed and highly available“ (STACKIT Docs, Kubernetes Engine). Die Einführungsseite der SKE-Dokumentation nennt als einzigen Service Level Indicator die Verfügbarkeit des Kubernetes-API-Servers mit einem SLA-Wert von 99,9 % (STACKIT Docs, SKE Introduction). Verletzt ist die Zusage laut Dokumentation, wenn der API-Server des Clusters nicht von außen erreichbar ist; Ausfälle von Pods oder Nodes im Cluster sind ausgenommen. Das betrifft also die Erreichbarkeit der Control Plane, nicht Ihre Workloads.
Verbindlich sind Berechnung, Messzeitraum und Rechtsfolgen im Vertrag mit STACKIT; die Dokumentation verlinkt kein separates SLA-Dokument, und wir haben keines geprüft. Für unseren Betrieb gilt: rund um die Uhr (24/7); die Reaktionszeiten je Prioritätsstufe ergeben sich aus dem Servicelevel-Modell unter Managed Services und werden je Vertrag vereinbart.
07Vorgehen im Projekt
Vom Zonen-Layout zum geprobten Ausfall
Bestehende Cluster in anderen Umgebungen überführen wir nach dem Muster der Migration zu STACKIT.
- 01
Entwurf
Ergebnis: ZielbildAnforderungen, Zonen- und Pool-Layout, Netzwerkmodell, Add-on-Auswahl, Zugriffsmodell.
- 02
Aufbau als Code
Ergebnis: Cluster im RepositoryCluster, Pools und Add-ons mit Terraform/OpenTofu und GitOps, Review über Pull Requests (Infrastructure as Code).
- 03
Absicherung
Ergebnis: Rechte und PoliciesZugriffsrechte, Netzwerkrichtlinien, Policies (Kubernetes Security).
- 04
Validierung
Ergebnis: geprobter ErnstfallZonenausfall-Übung, Restore-Test, Probealarm.
- 05
Betrieb oder Einweisung
Ergebnis: Runbooks, BetriebRunbooks, Einweisung Ihres Teams oder Betrieb nach Managed Kubernetes.
08Passung
Für wen sich ein SKE-Betrieb durch SKAFFON eignet
Das passt
- Sie setzen SKE ein oder führen es ein und wollen die Schicht oberhalb der Control Plane als Code, mit GitOps, Monitoring und Restore-Test aufgebaut oder betrieben haben.
- Sie wollen die Cluster-Plattform nicht nur einmalig bauen lassen, sondern auch im Alltag mit Updates, Alarmen und Restore-Tests betreut wissen.
Das passt nicht
- Sie wollen ausschließlich STACKIT-Herstellersupport zur Plattform: Support für SKE selbst erhalten Sie über Ihren Vertrag bei STACKIT.
- Ihr Workload braucht Managed Services, die STACKIT nicht anbietet, und Sie wollen daran festhalten: Dann ist die Cloud-Plattformwahl der bessere Einstieg.
- Sie wollen Anwendungsbetrieb pauschal auslagern, ohne dass die Anwendung bekannt ist.
09
Häufige Fragen
Brauche ich neben SKE noch einen Dienstleister für Updates?
SKE aktualisiert Patch-Versionen automatisch im Wartungsfenster. Minor-Upgrades, Add-on-Kompatibilität und die Frage, wann ein Update Ihre Workloads trifft, bleiben Aufgabe Ihres Teams oder unseres Betriebs.
Wann lohnt sich ein eigener Entwurf vor dem ersten Cluster?
Immer dann, wenn Persistenz oder Hochverfügbarkeit gefragt ist. Zonen lassen sich einem Pool nur hinzufügen, nicht entfernen, und Volumes bleiben an ihre Zone gebunden. Ein falsches Layout korrigiert später nur ein neuer Pool mit Volume-Migration.
Was kostet das?
Den Aufwand bestimmen Zahl der Cluster und Umgebungen, Pool-Layout, Add-ons, Verfügbarkeits- und Wiederherstellungsziele sowie Änderungsvolumen. Preise für SKE selbst nennt STACKIT.