Kubernetes Managed Service 2026: ab 5.000 Euro im Monat

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting | 9 Min. Lesezeit | 10.09.2026

TL;DR: Kubernetes Managed Service kurz erklärt

Pexon Consulting ist Managed Service Provider für Kubernetes, kein Hoster. Ihr Cluster bleibt bei Ihnen, die Daten verlassen das Haus nicht. Wir setzen auf oder sanieren, danach Updates, Monitoring, Security und NIS2-Prüfung. Betrieben von Kubestronauts. Einstieg ab 5.000 Euro monatlich plus Setup-Fee.

Das Problem: Managed Service bedeutet überall etwas anderes

Wenn drei Anbieter Kubernetes Managed Service auf die Website schreiben, meinen sie in der Regel drei verschiedene Dinge. Manche hosten Ihre Workloads in ihrem Rechenzentrum. Andere verkaufen Ihnen AKS und nennen das Managed. Wieder andere stellen Ihnen ein Ticketsystem hin und reagieren, wenn Sie sich melden.

Deshalb lohnt sich die präzise Frage: Wo läuft das Cluster, wem gehören die Daten, und wer handelt – reaktiv oder proaktiv?

Bei uns lautet die Antwort: Das Cluster läuft bei Ihnen, die Daten gehören Ihnen, und wir handeln, bevor Sie etwas merken. Der häufigste Satz aus unseren Bestandskunden lautet sinngemäß, dass sie von Problemen gar nichts mitbekommen – weil wir sie vorher wegräumen.

AKS, EKS und GKE nehmen Ihnen die Control Plane ab. Das ist wertvoll, aber es ist kein Betrieb. Node-Updates, Image-Härtung, Network Policies, RBAC, Backup-Tests, Alerting, Incident-Response und der Nachweis gegenüber Auditoren bleiben bei Ihnen. Wer das mit „wir haben Managed Kubernetes“ verwechselt, merkt den Unterschied erst, wenn der erste Patch-Zyklus ansteht oder NIS2 nach Dokumentation fragt.

Was wir konkret übernehmen

Der Kubernetes Managed Service läuft in zwei Phasen.

Phase 1 – Instandsetzung. Wir kommen in Ihre Umgebung und sorgen zuerst dafür, dass der Cluster sauber aufgesetzt ist. Existiert bereits eine Umgebung, prüfen und sanieren wir sie: falsche Konfigurationen, offene Sicherheitsthemen, fehlende Skalierungslogik, ungehärtete Images. Existiert noch nichts, bauen wir neu – dann von Anfang an so, dass die Umgebung wartbar bleibt.

Phase 2 – Dauerbetrieb. Danach halten wir den Cluster in genau dem Zustand, in dem wir ihn übergeben haben:

• Kubernetes- und Node-Updates, inklusive Testpfad
• Proaktives Monitoring, Logging und Alerting
• Security-Härtung auf Cluster- und Container-Ebene
• Laufende Prüfung gegen die für Sie geltende Regulatorik – je nach gebuchtem Paket NIS2 oder KRITIS
• Störungsbehebung, bei entsprechendem SLA auch außerhalb der Geschäftszeiten
• Dokumentation, die auch dann trägt, wenn Sie den Betrieb später wieder selbst übernehmen

Wer selbst Software entwickelt, integriert das sinnvollerweise direkt in die Deployment-Pipeline: Die Entwickler drücken auf den Knopf, die Applikation landet im Cluster – den ganzen Unterbau sehen sie nicht mehr.

Die Schnittstelle sieht in der Praxis ungefähr so aus. Das ist keine Vertragsformel, sondern die Arbeitsteilung, die wir mit den meisten Teams so fahren:

# Illustrativ: Verantwortlichkeiten im Kubernetes Managed Service.
betrieb:
  updates_und_patches: pexon
  monitoring_alerting: pexon
  security_haertung: pexon
  incident_response: pexon
  nis2_nachweis_plattform: pexon
kunde:
  fachliche_releases: kunde
  workload_architektur: kunde
  dateneigentum: kunde
  infrastrukturvertrag: kunde

Ihr Team bleibt am Steuer für Produkt und Architektur. Wir halten die Plattform in einem Zustand, in dem Releases nicht an Betriebschaos scheitern.

Ihre Daten bleiben in Ihrem Haus

Das ist der Punkt, an dem sich das Modell von klassischem Hosting unterscheidet, und für regulierte Kunden ist es der entscheidende.

Wir betreiben den Cluster nicht bei uns – wir bieten überhaupt kein Hosting an. Wir kommen in Ihre Umgebung: Ihr Rechenzentrum, Ihre Azure-Subscription, Ihr Anbieter. Die Daten verlassen Ihr Haus nicht. Sie behalten die Hoheit über Speicherort, Verschlüsselung und Zugriff, und Sie behalten die Verträge mit Ihren eigenen Infrastrukturanbietern.

Für Banken, Versicherungen, Förderbanken und Energieversorger, die einen großen Teil unseres Kundenstamms ausmachen, ist genau das in der Regel die Voraussetzung dafür, dass ein Betriebspartner überhaupt in Frage kommt. Ein Modell, bei dem Workloads und Secrets in ein fremdes Rechenzentrum wandern, fällt in diesen Häusern oft schon in der ersten Compliance-Runde.

Technisch heißt das: Wir arbeiten mit den Zugängen, die Sie uns geben. Lesend dort, wo Analyse reicht. Schreibend dort, wo Betrieb das verlangt – und das ist dokumentiert, nicht stillschweigend. Ihre Identity-Quelle, Ihre Vaults, Ihre Backup-Ziele bleiben Ihre.

Die drei häufigsten Gründe, warum Kunden abgeben

Wir sehen im Wesentlichen drei Auslöser – meistens in dieser Reihenfolge.

1. Überlastung. Der häufigste Grund. Kunden fühlen sich überladen und kommen nicht mehr zu ihrem Kerngeschäft, weil hinter Kubernetes einfach sehr viel mehr steckt, als ein AKS in Azure zu deployen. Der Cluster ist kein Projekt, das man abschließt, sondern eine Plattform, die man betreibt. Wer Software baut, hat dafür weder die Zeit noch den Anspruch.

2. Regulatorik und Datenschutz. Deutlich größer geworden in den letzten Jahren, allen voran durch NIS2. Laut Europäischer Richtlinie 2022/2555 (NIS2) müssen Betreiber wesentlicher Dienste ihre Systeme nachweisbar absichern – das Cluster eingeschlossen. Viele Kunden sind schlicht überfordert von der Frage, wie sie ihr Cluster regulatorisch sauber halten und auditfähig dokumentieren sollen – und wollen sich damit auch gar nicht beschäftigen müssen.

3. Kosten und Personalabgang. Der ehrlichste Fall. Der Kollege mit dem Kubernetes-Wissen geht, und der Kunde steht vor der Entscheidung: neue Person einstellen – auf einem Markt, auf dem gute Kubernetes-Leute rar sind – oder an einen Partner geben. Über die Gesamtkosten gerechnet ist der Managed Service dabei oft die günstigere Variante, weil er kein Rekrutierungsrisiko, keine Einarbeitungszeit und keinen Bus-Faktor 1 erzeugt.

Die drei Gründe stapeln sich. Überlastung führt zu lückenhafter Dokumentation. Lückenhafte Dokumentation fällt in der nächsten Prüfung auf. Verliert das Haus dann noch die einzige Person mit Cluster-Wissen, ist das kein Betriebsproblem mehr, sondern ein Geschäftsrisiko.

Was der Kubernetes Managed Service kostet

Der Einstieg liegt bei 5.000 Euro monatlich. Je nach Ausgangslage kommt eine einmalige Setup-Fee hinzu – insbesondere dann, wenn wir eine bestehende Umgebung erst sanieren oder ein Cluster neu aufbauen. Was darüber hinaus in die laufende Fee einfließt, hängt an vier Stellschrauben:

1. Clustergröße und Anzahl der Cluster – der größte Hebel.
2. SLA-Niveau – Geschäftszeiten oder 24/7.
3. Regulatorik-Paket – NIS2 ist das mit Abstand am häufigsten mitgebuchte Add-on.
4. Neuaufbau oder Übernahme – ein Greenfield-Cluster ist ein anderer Aufwand als die Sanierung einer gewachsenen Umgebung.

Wir bieten die Pakete in den Größen Small, Medium und Large an. Am beliebtesten ist mit Abstand Medium. Dort ist bereits sehr viel abgedeckt, der Kunde muss sich um wenig kümmern, sitzt aber noch selbst am Steuer und behält die Kontrolle über Architekturentscheidungen. Wer den Rahmen vorab selbst abstecken will, kommt über den Kubernetes Managed Service Konfigurator in wenigen Klicks zu einem Ab-Preis.

Die Setup-Fee ist kein versteckter Aufschlag, sondern der Preis für Phase 1. Eine Umgebung, die zwei Jahre ohne Patch-Disziplin gelaufen ist, braucht zuerst Inventar, Härtung und einen Testpfad. Erst danach ist Dauerbetrieb ehrlich kalkulierbar. Wer das in die monatliche Fee drückt, bezahlt die Sanierung jahrelang mit.

Was das nicht ist: kein Lock-in

Uns geht es nicht darum, uns als Dauerdienstleister so einzunisten, dass Sie nie wieder wegkommen. Das ist keine Marketingaussage, sondern eine Arbeitsweise: Wir bauen die Dokumentation von Anfang an so auf, dass Sie damit allein weiterarbeiten können, und beteiligen Ihr Team auf Wunsch aktiv am Aufbau.

Wenn Sie irgendwann Lust haben, den Betrieb selbst zu übernehmen – weil Sie jemanden gefunden haben, weil sich die Strategie ändert, weil Sie es einfach wollen -, dann besteht diese Möglichkeit jederzeit. Ein Modell, das wir häufig fahren: Wir bauen den Cluster professionell auf, betreiben ihn im Managed Service, und Ihr Team lernt parallel mit. Learning on the Job auf einer Umgebung, die von Anfang an richtig gebaut ist.

Konkret heißt das: Runbooks, Inventar, Zugangsmatrix, Update-Pfad und die Begründung für Architekturentscheidungen liegen bei Ihnen, nicht in unserem Wiki. Ein Partner, der ohne diese Unterlagen nicht abgelöst werden kann, hat kein Betriebsmodell, sondern eine Abhängigkeit.

So läuft der Einstieg

Meistens kurzfristig. Wir hatten mehrfach Fälle, in denen ein Kunde am Abend anrief und am nächsten Morgen ein erster Call stattfand. Wie lange es bis zur geordneten Betriebsübernahme dauert, hängt vor allem an Zugängen und interner Freigabe – das legen wir im ersten Gespräch gemeinsam fest.

Ein typischer Ablauf sieht so aus:

1. Erstgespräch. Clusterzahl, Umgebung (AKS, EKS, GKE, On-Prem, hybrid), SLA, Regulatorik.
2. Zugang und Inventar. Lesender Blick zuerst, dann die Liste dessen, was wirklich läuft.
3. Instandsetzung. Sanierung oder Greenfield, Testpfad, Härtung, Dokumentation.
4. Betriebsübergabe. Monitoring greift, Update-Kalender steht, Eskalation ist klar.
5. Dauerbetrieb. Wir halten den Zustand. Ihr Team liefert Features.

Betrieben wird das von zertifizierten Kubestronauts und Golden Kubestronauts. Nach Angaben der CNCF ist das der Nachweis für geprüfte Kubernetes-Praxis, nicht nur ein Kurszertifikat. Das ist die Voraussetzung dafür, dass Updates und Incidents nicht an Lehrbuchwissen scheitern.

Häufig gestellte Fragen

Funktioniert der Managed Service auch für AKS, EKS oder GKE?

Ja. Wir betreuen AKS, EKS, GKE, On-Prem-Cluster und hybride Setups. AKS ist bei unseren Kunden am weitesten verbreitet, weil viele ohnehin in Azure sind – technisch sind wir aber nicht auf eine Umgebung festgelegt. Bei den Hyperscaler-Diensten entfällt die Control Plane, der Betrieb darunter und darum herum bleibt.

Übernehmen Sie auch bestehende Cluster, die nicht sauber aufgesetzt sind?

Das ist der Normalfall. Wir gehen regelmäßig in Bestandsumgebungen hinein, die über Jahre gewachsen sind und deren Aufbau niemand mehr vollständig überblickt. Der erste Schritt ist dann ein Cluster-Review plus Grunddokumentation – für Sie und für uns.

Wie schnell können Sie starten?

Meistens kurzfristig. Der begrenzende Faktor ist selten unser Kalender, sondern Ihre Zugänge und Freigaben. Was intern drei Wochen dauert, dauert intern drei Wochen. Den technischen Start können wir eng darauf setzen.

Deckt der Managed Service NIS2 vollständig ab?

Für den Teil, der Ihre Kubernetes-Infrastruktur betrifft: ja, mit dem entsprechenden Add-on. NIS2 betrifft aber Ihre gesamte Organisation, nicht nur ein Cluster. Wir liefern den technischen Nachweis und die Dokumentation für die Plattform – Ihre Governance drumherum bleibt Ihre Aufgabe.

Was passiert bei einem Incident nachts um drei?

Das hängt am gebuchten SLA. Ohne 24/7-Paket reagieren wir zu Geschäftszeiten. Mit 24/7 rund um die Uhr. Wichtig ist die Vorstufe: Ein großer Teil unserer Arbeit besteht darin, dass dieser Anruf gar nicht erst nötig wird.

Nächster Schritt

Mitbringen sollten Sie drei Dinge: eine Aussage zur Größe Ihrer Umgebung (Anzahl und Größe der Cluster), Ihre Erwartung an die Verfügbarkeit, und die Regulatorik, die für Sie gilt. Damit lässt sich im ersten Gespräch bereits ein belastbares Angebot skizzieren.

Den Rahmen können Sie vorab selbst durchklicken – der Konfigurator zeigt Ihnen einen Ab-Preis, bevor wir überhaupt miteinander sprechen.

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting, erklärt im Gespräch, was Pexon im Kubernetes Managed Service konkret übernimmt, warum die Daten im Haus bleiben und welche drei Gründe Kunden am häufigsten nennen. Video auf YouTube ansehen.

Verwandte Themen