Managed Services · Kubernetes-Betrieb
Managed Kubernetes – Cluster und Plattform professionell betreiben
Wir betreiben Ihre Cluster und die Plattform darum, mit Upgrades, Patching, GitOps, Monitoring und getesteter Wiederherstellung. Betrieb und Support rund um die Uhr (24/7).
- Argo CD, Kyverno, Velero, Prometheus
- STACKIT, AWS, Azure, GCP, eigene Infrastruktur
01Dauerbetrieb
Kubernetes installieren ist der kleinere Teil
Der größere Teil ist der Betrieb danach: Das Projekt pflegt nur die jeweils neuesten drei Minor-Versionen und gibt etwa ein Jahr Patch-Support (kubernetes.io/releases, Stand der Prüfung 2026-11-13). Wer ein Cluster betreibt, muss also mehrmals jährlich upgraden, Add-ons kompatibel halten, Zertifikate erneuern und Sicherheitsmeldungen bewerten.
Genau diesen Teil übernehmen wir. Der Service richtet sich an IT-Leitung und Plattformverantwortliche, die Kubernetes produktiv nutzen oder einführen und den Betrieb mit klar geregelten Zuständigkeiten an einen Dienstleister geben wollen.
Architektur und Einführung beschreibt unsere Kubernetes-Beratung, den Aufbau interner Entwicklerplattformen Platform Engineering. Die übergeordnete Einordnung finden Sie unter Managed Services.
02Betriebsumfang
Acht Aufgaben, die an Ihrem Cluster laufend anfallen
-
Lifecycle
Cluster-Erstellung, Konfiguration und Erweiterung als Code; Node-Pools, Skalierung, Austausch von Knoten, geordnete Stilllegung.
-
Patching und Upgrades
Kubernetes-Minor- und Patch-Upgrades, Node-Betriebssystem, Container-Runtime und Add-ons, nach dem unten beschriebenen Verfahren.
-
Incident- und Change-Management
Strukturierte Störungsbearbeitung und freigegebene Änderungen, Details im Prozessabschnitt.
-
GitOps mit Argo CD
Der gewünschte Zustand liegt im Git-Repository, Änderungen laufen über Pull Requests und sind nachvollziehbar.
-
Policies und Sicherheit
Admission-Policies mit Kyverno, RBAC, Netzwerkregeln und Zertifikatsverwaltung mit cert-manager. Vertiefung unter Cloud Security und DevSecOps.
-
Monitoring
Prometheus und Grafana für Cluster- und Plattformmetriken, Alarmierung auf Plattformebene.
-
Recovery
Backup von Cluster-Ressourcen und persistenten Volumes mit Velero, dokumentierte und getestete Wiederherstellung.
-
Berichte
Regelmäßiger Betriebsbericht zu Störungen, Changes, Versionsstand und Kapazität.
04Zuständigkeiten
Wer bei Managed Kubernetes wofür geradesteht
R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung, vertraglich anpassbar.
| Tätigkeit | SKAFFON | Kunde |
|---|---|---|
| Cluster-Konfiguration als Code pflegen | R/A | C |
| Kubernetes-Upgrade planen und durchführen | R | A (Freigabe Fenster) |
| Node-Betriebssystem und Add-on-Updates | R/A | C |
| Monitoring und Plattform-Alarmierung betreiben | R/A | I |
| Plattform-Störung (Control Plane, Nodes, Netzwerk, Ingress) | R/A | I |
| Störung im Workload (Anwendungscode, Anwendungskonfiguration) | C | R/A |
| Argo-CD- und GitOps-Plattform betreiben | R/A | C |
| Anwendungs-Manifeste und Helm-Charts der Anwendungen | C | R/A |
| Policies (Kyverno) definieren: Regelwerk der Plattform | R | A |
| Fachliche Ausnahmen von Policies | C | R/A |
| RBAC-Modell umsetzen | R | A |
| Wer erhält welche Rechte (fachliche Entscheidung) | C | R/A |
| Zertifikatsverwaltung (cert-manager) betreiben | R/A | I |
| Velero-Backups einrichten, Restore-Tests durchführen | R/A | C |
| Daten in persistenten Volumes: Datenverantwortung | C | R/A |
| Kapazitätsplanung und Kostenberichte | R | A |
| Betriebsreview und Eskalation | R | A |
Die Verantwortung für die Anwendungen auf dem Cluster bleibt bei Ihnen oder Ihrem Entwicklungsdienstleister. Wir betreiben die Plattform, auf der sie laufen.
05Upgrade
Minor für Minor: so läuft ein Kubernetes-Upgrade bei uns
Upgrades werden schrittweise durchgeführt, jeweils eine Minor-Version; das Überspringen von Minor-Versionen ist laut Kubernetes-Dokumentation nicht unterstützt. Die Regeln zur Versionsverträglichkeit zwischen Komponenten stehen in der Version-Skew-Policy.
- 01
Vorbereitung
VorabRelease Notes und Deprecations prüfen, eingesetzte APIs und Add-ons auf Kompatibilität bewerten, Wartungsfenster mit Ihnen abstimmen.
- 02
Absicherung
VerbindlichFrisches Backup (Velero und Zustand der Control Plane, soweit vom Anbieter zugänglich), Prüfung der Restore-Fähigkeit, Rückfallkriterien festlegen.
- 03
Test
Upgrade zuerst in einem Nicht-Produktivcluster oder einer temporären Umgebung mit vergleichbarer Konfiguration, soweit vorhanden.
- 04
Control Plane
Aktualisierung der Control Plane bzw. beim Managed-Control-Plane-Anbieter Anstoß des Upgrades, Verifikation von API-Server, Controllern und Add-ons.
- 05
Nodes
Rolling-Upgrade der Node-Pools: Cordon, Drain unter Beachtung von PodDisruptionBudgets, Austausch, Verifikation.
- 06
Verifikation
Mit AbnahmeSmoke-Tests, Prüfung der Alarme und Dashboards, Abnahme durch Sie.
- 07
Rollback
Vorbereitet als Rückfall auf einen gesicherten Zustand, siehe unten. Die Variante wird vor dem Upgrade vereinbart.
- 08
Dokumentation
Ergebnis, Abweichungen und Lehren fließen in den Betriebsbericht und die Runbooks.
Rückfall heißt hier nicht Downgrade
Wir planen den Rückfall nicht als Downgrade der Control Plane, sondern als Rückfall auf einen gesicherten Zustand. Das bedeutet je nach Topologie: Node-Pools auf den vorherigen Stand zurücksetzen oder auf ein vorab aufgebautes Cluster zurückschalten, und Anwendungszustand aus dem Backup wiederherstellen. Genau deshalb ist die Absicherung vor dem Upgrade verbindlich.
06Tagesgeschäft
Störung, Änderung, Sicherheitsmeldung: drei Abläufe, drei Wege
Incident: Erkennung (Alarm oder Meldung), Priorisierung, Eingrenzung, Behebung oder Workaround, Statusinformation, Abschluss mit Ihrer Bestätigung, bei schwerwiegenden Störungen Ursachenanalyse mit Maßnahmen.
Change: Änderung als Pull Request im GitOps-Repository, Review, Einstufung als Standard- oder prüfpflichtiger Change, Freigabe durch Sie, Umsetzung durch SKAFFON, Verifikation, Rückfallplan vor Umsetzung.
Patch: Beobachtung von Sicherheitsmeldungen zu Kubernetes, Node-Betriebssystem und Add-ons; Bewertung der Relevanz für Ihre Umgebung; Test; Rollout im Wartungsfenster. Dringende Sicherheitsupdates werden mit Ihnen außerhalb des Regelzyklus abgestimmt.
- Reaktionszeiten und Eskalationskette legt der Vertrag fest
- Kontaktwege testen wir im Onboarding gemeinsam mit Ihnen
07Monitoring
Worauf unsere Alarme auf Plattformebene anschlagen
Prometheus sammelt Metriken zu Control Plane, Nodes, Workloads und Add-ons, Grafana stellt sie dar. Alarme auf Anwendungsebene können wir auf Wunsch aufschalten; die Zuständigkeit dafür legt die RACI fest. Ergänzend gibt es den Betriebsbericht mit Versionsstand der Cluster, Incidents, Changes, durchgeführten Patches, Kapazitätstrends und anstehenden Upgrades.
- Knoten nicht bereit
- Speicherknappheit
- Ablaufende Zertifikate
- Fehlgeschlagene Backups
- Nicht erreichbare API
08Wiederherstellung
Ein Backup gilt erst nach dem Restore-Test
Velero sichert Cluster-Ressourcen und, je nach Speicherlösung, Volume-Snapshots. Ein Backup gilt erst durch einen Restore-Test als belegt; wir führen ihn regelmäßig durch.
Für Datenbanken mit hohen Anforderungen reicht ein Volume-Snapshot oft nicht, dort ist ein datenbankeigenes Verfahren richtig, siehe Managed PostgreSQL. Wiederherstellungsziele (RPO/RTO) werden je Vertrag vereinbart und per Restore-Test nachgewiesen.
09Übernahme
Vom Bestandscluster zum geregelten Betrieb
Bestehende Cluster ohne Dokumentation sind möglich, benötigen aber eine gründlichere Bestandsaufnahme.
- 01
Bestandsaufnahme
Cluster mit Versionen, Add-ons, Netzwerk, Workloads und Risiken erfassen.
- 02
Betriebsplan
RACI und Wartungsfenster festlegen.
- 03
Konfiguration nach Git
Überführung des Bestands in GitOps.
- 04
Monitoring und Backup aufschalten
Probealarm und Restore-Test.
- 05
Regelbetrieb
DanachAb hier läuft der Betrieb nach Betriebsplan.
10Passung
Für welche Cluster sich der Betrieb durch SKAFFON eignet
Wir beginnen mit einer Bestandsaufnahme und legen daraus Leistungsumfang, RACI und Berichtsrhythmus fest.
Das passt gut
- Sie nutzen Kubernetes produktiv oder führen es ein und wollen den Betrieb mit klaren Zuständigkeiten abgeben.
- Sie können Zugriff und Dokumentation Ihrer Cluster bereitstellen.
- Bestehende Cluster sollen übernommen werden, nach einer Bestandsaufnahme.
Das passt eher nicht
- Sie wollen Anwendungsentwicklung und Anwendungsbetrieb pauschal mit auslagern, ohne dass die Anwendung bekannt ist.
- Ihr Workload ist mit Kubernetes nicht sinnvoll abbildbar; dann ist eine Beratung zur Zielarchitektur der bessere Anfang, siehe Cloud-Beratung.
- Sie möchten ein einzelnes Entwicklungs-Cluster ohne Betriebsanforderungen betreut haben.
11Angebot
Was Cluster-Betrieb aufwendiger macht
Aufwändiger wird der Betrieb vor allem durch die Zahl der Cluster und Umgebungen, die Größe und Heterogenität der Node-Pools, die Anzahl der Add-ons und Plattformkomponenten, die Anforderungen an Hochverfügbarkeit und Wiederherstellung sowie das Änderungsvolumen. Daraus ergibt sich Ihr individuelles Angebot; es legt Umfang, Annahmen und Preismodell fest.
12
Häufige Fragen
Betreiben Sie die Control Plane selbst oder nutzen Sie den Dienst des Cloud-Anbieters?
Beides ist möglich. Bei verwalteten Control Planes (etwa der Kubernetes-Dienst Ihres Cloud-Anbieters) betreiben wir alles darum herum; bei Eigenbetrieb auch die Control Plane. Die Wahl hängt von Plattform, Datenstandort und Anforderungen ab.
Wie oft wird Kubernetes aktualisiert?
Das richtet sich nach dem Release-Zyklus des Projekts und dem Support-Fenster Ihrer Version, siehe die oben verlinkte Release-Seite. Wir planen Upgrades gemeinsam mit Ihnen im Voraus.
Können Sie bestehende Cluster übernehmen?
Ja, nach einer Bestandsaufnahme.
Beschreiben Sie uns Ihre Cluster
Schildern Sie Cluster und Betriebsanforderungen, wir antworten mit einem Vorschlag für Umfang, RACI und Berichtsrhythmus. Rückfragen vorab über den Kontakt.