Managed Kubernetes mit Betriebsverantwortung: audit-fest, aus Deutschland
Wir übernehmen den Betrieb eures Clusters genau dort, wo das SLA der Plattformanbieter aufhört: Worker-Nodes, Patching, Upgrades und der Day-2-Alltag. Dokumentiert so, dass die Unterlagen einem NIS2- oder DORA-Audit standhalten. Ab 2.500 EUR im Monat, Servicezeit Mo-Fr 08:00-18:00 MEZ.
Pexon übernimmt den Betrieb eures Kubernetes-Clusters: Worker-Nodes, Upgrades, Patching und Day-2-Aufgaben, dokumentiert für NIS2- und DORA-Nachweise. Ab 2.500 EUR im Monat, Servicezeit Mo-Fr 08:00-18:00 MEZ. Im Unterschied zu Plattformanbietern endet unser Service nicht an der Control Plane.
Kern-Themen: Leistungsumfang je Stufe · Preise und Stufen · Wer verantwortet was · Ablauf der Übernahme · Was wir nicht machen · Häufige Fragen.
Unsere Lösungen
Der Leistungsumfang ist nach Stufen geschnitten, nicht nach Stunden. Was in einer Stufe steht, ist enthalten, auch wenn es in einem Monat mehr Arbeit macht als im nächsten. Was davon auf Überwachung entfällt, ist gesondert beschrieben: dort steht, wie ihr Cluster und Workloads überwachen lassen könnt.
| Leistung | Was wir übernehmen | Enthalten in Stufe |
|---|---|---|
| Worker-Nodes | Bereitstellung, Skalierung, Austausch defekter Nodes, Betriebssystem-Updates der Node-Images, Kapazitätsbeobachtung | L Operations und aufwärts |
| Patching und CVE-Behandlung | Feste Patch-Zyklen für Nodes und Cluster-Komponenten, Bewertung neuer Schwachstellen, Einordnung nach Dringlichkeit | L Operations und aufwärts |
| Cluster-Upgrades | Geplante Upgrades der Kubernetes-Version, Test in einer Vorstufe, Rückfallplan, Terminabstimmung mit eurem Release-Kalender | L Operations und aufwärts |
| Day-2-Betrieb | Zertifikats-Rotation, Backups mit regelmäßigem Restore-Test, Observability, Alarmierung und gepflegte Runbooks | L Operations und aufwärts |
| Plattform-Dienste | Ingress, Secrets-Verwaltung, Policies, Anbindung eurer CI/CD und ein GitOps-Repository als einzige Quelle des Soll-Zustands | ab L Platform |
| Mehrere Cluster und Umgebungen | Betrieb über mehrere Stages, Regionen oder Mandanten auf einem einheitlichen GitOps-Stand statt handgepflegter Einzelfälle | ab XL |
| Nachweis-Dokumentation | Änderungshistorie, Upgrade- und Patch-Protokolle, Zugriffsnachweise und ein monatlicher Bericht als Grundlage für Audits. Vertiefung: den Betrieb audit-fest machen | Day-2-Compliance-Retainer |
| Security-Prüfung | Konfigurations-Review von RBAC, Network Policies und Pod Security. Als eigenes Angebot buchbar: den Cluster gegen den CIS-Benchmark prüfen | separat, nicht im Retainer |
Nicht enthalten sind Leistungen, die wir bewusst nicht anbieten. Die Liste steht weiter unten unter Was wir nicht machen, damit ihr sie vor dem Gespräch kennt und nicht danach.
Wo euer Betrieb heute an die Grenze kommt
Der Betrieb hängt an einer Person, nachts ist niemand da, und die Nachweise fehlen. Drei Sätze aus Erstgesprächen, dieselbe Lücke aus drei Richtungen.
„Unser Kubernetes-Mensch geht, und niemand kann den Cluster noch absichern.“ Ein Freelancer-Kontakt ersetzt das nicht: er hat kein Vertretungsmodell. Sobald diese eine Person kündigt, ist Wissen weg, das nie in Runbooks stand.
„Nachts fiel der Cluster aus, und keiner konnte helfen.“ Der eigentliche Fehler passiert vorher: fehlende Redundanz, ungetestete Backups, kein Runbook. Betrieb heißt deshalb zuerst, den Ausfall unwahrscheinlich und beherrschbar zu machen. Welches Tool den Cluster-Schnitt sichert, steht im Lemma zu Velero Backup für Cluster-Objekte.
„Mein Bankkunde schickt mir einen DORA-Fragebogen, den ich nicht beantworten kann.“ Der Cluster läuft technisch sauber, aber es gibt keine Änderungshistorie, keine Upgrade-Protokolle und keinen Zugriffsnachweis, die man einem Prüfer vorlegen könnte.
Vollkosten für zwei Plattform-Engineers, gerechnet auf Basis von Bitkom- und StepStone-Gehaltsdaten. Das ist eine Schätzung aus fremden Gehaltsdaten, keine Pexon-Kalkulation. Zwei Stellen halten wir für die Untergrenze, wenn Urlaub, Krankheit und Kündigung abgedeckt sein sollen. Beide zu besetzen und zu halten ist der eigentliche Engpass, nicht das Budget.
Der Ablauf ist fast immer derselbe. Der Cluster entsteht in einem Projekt, läuft, und danach kümmert sich derjenige darum, der ihn gebaut hat. Das funktioniert, solange nichts Großes passiert und diese Person bleibt. Es funktioniert nicht mehr, sobald ein Kunde Nachweise verlangt, eine Kubernetes-Version aus dem Support läuft oder die Person das Unternehmen verlässt.
Der Plattform-Vergleich hilft an dieser Stelle weniger, als er verspricht. Die Anbieter, die ihr euch anschaut, verkaufen Infrastruktur mit einem SLA auf die Control Plane. Was darüber liegt, bleibt bei euch: die Worker-Nodes, das Patching, die Upgrades und die Frage, ob eure Anwendung läuft. Genau diese Ebene übernehmen wir. Im Alltag halten wir die ResourceQuota als Namespace-Deckel, damit ein Team den Node nicht ausräumt. Teilen sich Geschäftseinheiten oder SaaS-Mandanten denselben Cluster, ist dieser Deckel nur die erste von vier Schichten: Multi-Tenant auf Kubernetes nimmt Netz, RBAC und Admission dazu.
Preise und Stufen
2.500, 6.000 oder 9.000 EUR im Monat je nach Stufe, plus 4.500 bis 7.000 EUR im Monat, wenn ihr Nachweise braucht. Die Werte sind Orientierung für die Budgetplanung, kein verbindliches Angebot: was der Betrieb bei euch kostet, hängt an Cluster-Zahl, Umgebungen und Nachweistiefe. Möglich sind diese Preise, weil ein Senior-Engineer 30 bis 50 Cluster mit GitOps betreut.
L Operations
- Worker-Nodes, Patching, Upgrades
- Day-2 inklusive Backups und Restore-Test
- Observability und Alarmierung
- Runbooks und Übergabe-Dokumentation
L Platform
- Alles aus L Operations
- Ingress, Secrets, Policies
- GitOps-Repository als Soll-Zustand
- Anbindung eurer CI/CD-Strecke
XL
- Alles aus L Platform
- Mehrere Cluster und Umgebungen
- Einheitlicher GitOps-Stand über alle Stages
- Abgestimmter Upgrade-Kalender
Day-2-Compliance-Retainer
Der Aufsatz für alle, die den Betrieb nicht nur stabil, sondern belegbar brauchen: wenn ein Bankkunde einen DORA-Fragebogen schickt, ein Wirtschaftsprüfer nachfragt oder NIS2 im Haus zum Thema wird. Der Retainer liefert die Unterlagen, die aus dem laufenden Betrieb ohnehin entstehen, in prüfbarer Form.
- Änderungshistorie aus dem GitOps-Repository
- Upgrade- und Patch-Protokolle je Cluster
- Zugriffs- und Berechtigungsnachweise
- Monatlicher Bericht für eure Revision
Für die Einordnung braucht ihr keinen Termin. Der Konfigurator fragt fünf Dinge zu eurem Cluster ab und nennt Stufe und Preis sofort, ohne Mailadresse: den Preis für euren Cluster selbst ermitteln.
Alle Werte verstehen sich netto und je Monat. Wir nennen sie hier, weil eine Seite ohne Preis euch zwingt, ein Gespräch zu führen, nur um eine Größenordnung zu erfahren. Die verbindliche Zahl steht im Angebot, nach der Bestandsaufnahme.
Wer verantwortet was im Kubernetes-Betrieb
Bei den 15 untersuchten Plattformanbietern endet das SLA an der Control Plane (Stichprobe, Stand 18.08.2026). Das ist kein Vorwurf, sondern das Geschäftsmodell: verkauft wird Infrastruktur, nicht Betrieb. Die Tabelle zeigt, welche Ebenen dadurch bei euch liegen bleiben.
| Ebene | Hyperscaler | Managed-Plattform | Pexon |
|---|---|---|---|
| Control Plane | betrieben und abgesichert | betrieben und abgesichert | wir prüfen die Konfiguration, betreiben sie aber nicht selbst |
| Worker-Nodes | bei euch | in der Stichprobe überwiegend bei euch | bei uns |
| Patching | bei euch | teils Node-Images, die Anwendung des Patches bleibt bei euch | bei uns, in festen Zyklen |
| Upgrades | bei euch, mit Frist über das Versions-Supportende | Termin wird angekündigt, Durchführung und Test bleiben bei euch | bei uns, geplant und mit Rückfallplan |
| Anwendungsverfügbarkeit | ausgeschlossen | ausgeschlossen | wir betreiben die Plattform darunter und alarmieren auf eure Anwendungs-Metriken |
| Audit-Nachweis | Zertifikate der Plattform, nicht eures Betriebs | Zertifikate der Plattform, nicht eures Betriebs | Änderungshistorie, Upgrade- und Zugriffsnachweise aus eurem Betrieb |
Die Angaben zu den Fremdanbietern stammen aus einer eigenen Stichprobe von 15 Plattformanbietern, Stand 18.08.2026, und beschreiben nicht den gesamten Markt. Prüft im Zweifel euer konkretes Vertragswerk, die Zuschnitte ändern sich.
Servicezeit: Mo-Fr 08:00-18:00 MEZ. In dieser Zeit sind benannte Ansprechpartner erreichbar, die euren Cluster kennen. Reaktionszeiten und Verfügbarkeitswerte stehen erst im unterschriebenen Servicevertrag, nicht auf dieser Seite: eine Zahl, die wir hier versprechen und dort einschränken müssten, wäre keine Zusage, sondern Werbung.
Was wir nicht machen
Keine Anwendungsentwicklung, kein Dienst nachts und am Wochenende, kein Wiederverkauf von Cloud-Kapazität, keine Rechtsberatung. Wer eines davon braucht, ist bei uns falsch, und das früh zu wissen spart beiden Seiten Zeit.
Keine Anwendungsentwicklung
Wir betreiben die Plattform, auf der eure Software läuft. Den Code eurer Anwendung schreiben und verantworten weiterhin eure Entwickler. Wir bauen die Strecke, über die er ausgeliefert wird, und melden uns, wenn ein Deployment die Plattform in Schwierigkeiten bringt.
Kein Dienst außerhalb der Servicezeit
Unsere Servicezeit ist Mo-Fr 08:00-18:00 MEZ. Wir versprechen keine Nacht- und Wochenendabdeckung, weil wir sie nicht dauerhaft besetzen können. Wer sie zusagt, ohne sie zu besetzen, liefert im Ernstfall nicht. Wir investieren die Arbeit stattdessen davor: Redundanz, getestete Backups, Runbooks.
Kein Wiederverkauf von Cloud-Kapazität
Eure Cloud-Rechnung bleibt eure Cloud-Rechnung. Wir schlagen nichts auf Infrastruktur auf und verdienen nichts daran, wenn euer Cluster größer wird. Deshalb können wir euch zu kleineren Node-Pools raten, ohne gegen das eigene Umsatzinteresse zu argumentieren.
Keine Rechtsberatung
Ob ihr unter NIS2 oder DORA fallt und wer im Haus dafür haftet, ist eine juristische Frage. Die beantwortet eure Rechtsabteilung oder eine Kanzlei, nicht wir. Wir liefern die technischen Nachweise, mit denen diese Prüfung überhaupt geführt werden kann.
Wo wir das bereits betreiben
Ein laufender Betriebsvertrag und zwei veröffentlichte Projekte. Der erste Fall ist anonymisiert, weil die Freigabe des Kunden noch aussteht: lieber eine Referenz ohne Namen als einen Namen ohne Freigabe.
Betriebsübernahme für einen SaaS-Anbieter aus dem DACH-Raum
Ein Software-Anbieter aus dem DACH-Raum liefert sein Produkt auf einem eigenen Kubernetes-Cluster aus. Der Betrieb hing an einem sehr kleinen Team. Wir übernehmen den Cluster, überführen den Soll-Zustand nach GitOps und bringen den Upgrade- und Patch-Zyklus in einen festen Kalender. Die Übernahme läuft, sie ist nicht rückwirkend erzählt.
Ausgangslage vergleichen →On-Prem-Kubernetes im regulierten Umfeld
Für einen Genossenschaftsversicherer haben wir eine On-Premises-Kubernetes-Plattform mit Rancher und Spinnaker aufgebaut, ausgelegt auf die Anforderungen eines beaufsichtigten Hauses. Der Fall zeigt, dass Betrieb und Nachweisführung auch dort zusammengehören, wo aus regulatorischen Gründen keine öffentliche Cloud in Frage kommt.
Zur Case Study →Kubernetes-Operator für eine gewachsene Systemlandschaft
Für einen IT-Dienstleister des Bundes haben wir einen Kubernetes-Operator in Go entwickelt, der wiederkehrende Betriebsschritte über eine gewachsene Systemlandschaft hinweg vereinheitlicht. Solche Automatisierung ist die Voraussetzung dafür, dass ein Senior-Engineer bei uns 30 bis 50 Cluster mit GitOps betreut, statt einen einzelnen von Hand zu pflegen.
Zur Case Study →So läuft die Übernahme
Von der Bestandsaufnahme bis zur Abnahme vergehen 6 bis 10 Wochen, abhängig davon, wie viel des heutigen Betriebs nur in Köpfen steht. Ihr behaltet in jeder Phase den vollen Zugriff auf euer Cluster.
Bestandsaufnahme
Wir sehen uns Cluster, Versionsstand, Node-Pools, Backups und die vorhandene Dokumentation an und schreiben auf, was fehlt. Ergebnis ist eine Lückenliste mit Reihenfolge, nicht ein Angebot mit Pauschale.
Übergabe und Zugriffe
Zugriffe, Rollen und Eskalationswege werden festgelegt, der Soll-Zustand wandert in ein GitOps-Repository, die ersten Runbooks entstehen. Ab hier ist nachvollziehbar, wer welche Änderung ausgelöst hat.
Parallelbetrieb
Wir übernehmen den laufenden Betrieb, euer Team schaut mit. In dieser Phase fahren wir das erste geplante Upgrade und den ersten Restore-Test aus dem Backup, damit beides einmal unter Beobachtung passiert ist.
Abnahme
Abgenommen ist die Übernahme, wenn ein Cluster-Upgrade und ein Restore aus dem Backup ohne Zutun eures Teams durchgelaufen sind und beides protokolliert vorliegt. Vorher endet der Parallelbetrieb nicht.
Wo ihr mit Managed Kubernetes anfangt
Fünf Wege von hier aus: drei Leistungen, die etwas kosten, und zwei Einstiege, die nichts kosten. Welcher passt, hängt daran, wo euer Cluster läuft und ob ihr schon wisst, was euch heute fehlt.
Betrieb, den wir übernehmen
Kostenpflichtig, ab 2.500 EUR im Monat. Welche der drei Seiten ihr braucht, entscheidet sich daran, wo euer Cluster heute läuft.
Managed Kubernetes auf Azure
AKS unterstützt drei Kubernetes-Versionen gleichzeitig, je zwölf Monate ab Verfügbarkeit. Danach fällt der Cluster in den Platform-Support, ohne Security-Patches. Wir übernehmen Node-Images, Versionswechsel und die Protokolle darüber.
den Azure-Betrieb mit Upgrade-Verantwortung abgebenKubernetes-Hosting mit Betrieb
Hosting und Betrieb sind zwei getrennte Ebenen. Die Plattform-Miete für drei Nodes liegt bei rund 60 EUR bei Hetzner, 110 EUR bei STACKIT und 166 EUR bei GKE im Monat (eigene Messung, 18.08.2026). Die zweite Ebene deckt keine dieser Mieten ab.
Hosting und Betrieb aus einer Hand ansehenBare-Metal Kubernetes
Für alle, die nicht in die Public Cloud wollen oder dürfen. Hardware, Standort und Kosten bleiben bei euch, den Betrieb darüber übernehmen wir: Knoten, Patching, Upgrades, Backups und Nachweise.
den Bare-Metal-Cluster betreiben lassenKostet euch nichts
Kein Vertrag, keine Rechnung, kein Vertriebsanruf hinterher. Der Konfigurator kostet nicht einmal einen Termin.
SLA-Gap-Analyse
60 Minuten mit einem Kubernetes-Engineer, in denen wir euren bestehenden Vertrag gegen euren echten Betriebsbedarf prüfen. Danach habt ihr eine schriftliche Gap-Liste in der Hand, auch wenn ihr am Ende selbst weiterbetreibt.
prüfen lassen, was euer SLA nicht abdecktManaged-Kubernetes-Konfigurator
Fünf Fragen zu eurem Cluster, dann stehen Stufe und Preis sofort auf dem Bildschirm: L Operations ab 2.500 EUR im Monat, L Platform 6.000 EUR im Monat, XL 9.000 EUR im Monat. Ohne Mailadresse, ohne Termin.
Stufe und Preis selbst ermittelnHäufige Fragen zu Managed Kubernetes
Aus Erstgesprächen mit CTOs, Plattform-Verantwortlichen und IT-Leitungen im DACH-Raum.
Was kostet Managed Kubernetes im Monat?
Was ist in einem Managed-Kubernetes-SLA typischerweise nicht enthalten?
Wer betreibt Kubernetes-Cluster für SaaS-Anbieter in Deutschland?
Was passiert, wenn der Cluster außerhalb der Servicezeit ausfällt?
Wie lange dauert die Übernahme eines bestehenden Clusters?
Was passiert mit unserem Cluster, wenn unser einziger Kubernetes-Mensch geht?
Bleibt der Cluster bei unserem Cloud-Anbieter oder zieht er um?
Womit eure Revision arbeiten kann
Kein Vertrauensvorschuss, sondern Unterlagen. Was im Betrieb ohnehin anfällt, halten wir so fest, dass es einer Prüfung standhält.
Pexon als Dienstleister
- ISO 27001 zertifiziert
- Auftragsverarbeitung nach DSGVO
- Microsoft-Partner
- Betrieb auf Azure, AWS, Google Cloud und im eigenen Rechenzentrum
- Vertrag, Rechnung und Ansprache auf Deutsch
Betriebsmodell
- Betrieb in eurem Cloud-Konto, nicht in unserem
- GitOps-Repository als Soll-Zustand
- Feste Patch- und Upgrade-Zyklen
- Backups mit regelmäßigem Restore-Test
- Benannte Ansprechpartner statt Ticket-Tunnel
- Servicezeit Mo-Fr 08:00-18:00 MEZ
Nachvollziehbarkeit
- Änderungshistorie aus dem GitOps-Repository
- Upgrade- und Patch-Protokolle je Cluster
- Zugriffs- und Berechtigungsnachweise
- Dokumentierte Eskalationswege
- Monatlicher Betriebsbericht
- Übergabefähige Runbooks, auch beim Wechsel zurück
Kostenlose SLA-Gap-Analyse, 60 Minuten
Wir gehen euren bestehenden Vertrag und euren Cluster durch und zeigen, welche Ebenen heute niemand verantwortet: Worker-Nodes, Patching, Upgrades, Nachweise. Ergebnis ist eine Lückenliste, die euch auch dann etwas nützt, wenn ihr am Ende selbst betreibt oder bei jemand anderem unterschreibt.
Wenn Managed Kubernetes allein nicht reicht
Nachweise, Härtung und KI-Workloads sind eigene Angebote und nicht Teil des Betriebsretainers:
den Betrieb audit-fest machen
Nachweis-Paket, C5-Kriterien und der monatliche Audit-Trail für NIS2 und DORA. Für alle, bei denen nicht die Technik das Problem ist, sondern der Beleg.
den Cluster gegen den CIS-Benchmark prüfen
RBAC, Network Policies, Pod Security und CVE-Stand im Konfigurations-Review, mit Ampel und Prioritäten statt einer Werkzeugausgabe.
KI-Workloads auf Kubernetes betreiben
GPU-Knoten, Inferenz und die Plattform unter euren KI-Produkten, auf offenen Standards und ohne Bindung an einen Hyperscaler.
Verwandte Inhalte
Stand 19. August 2026 · Kubernetes-Betrieb im Überblick
Sie suchen einen Partner für Ihr Projekt?
Wir analysieren Ihren individuellen Bedarf, geben erste Empfehlungen zu Umsetzungsstrategien und bieten Ihnen transparente Einblicke in unsere Methoden, Technologien und Referenzen.
