Internes Kubernetes-Team oder Managed Service 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 12 Min. Lesezeit | 29.09.2026

TL;DR: Internes Kubernetes-Team oder Managed Service kurz erklärt

Managed Kubernetes Service heißt hier übernommene Betriebsverantwortung für den Cluster, den Sie schon haben, nicht ein Hosting-Tarif. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) stellt Self-Managed, internes Platform-Team und externen Day-2-Betrieb gegeneinander. Die Grenze liegt bei Upgrades, Policy-Drift, Backup-Schichten und dem Ticket nach 18 Uhr. 8×5 ist die belegte Form, kein 24/7.

Das Problem: Alle haben Kubernetes, niemand besitzt das Ticket

Der Cluster läuft. Das Platform-Team hat Golden Paths gebaut. Upgrades warten auf ein Fenster, das niemand blockt. Velero ist grün, der Drill nicht. Nach 17 Uhr geht das Ticket an eine On-Call-Liste, die in der Praxis die App-Entwickler sind.

Internes Kubernetes-Team oder Managed Service ist deshalb keine Frage nach AKS oder Self-Hosting, die behandelt unser Vergleich der Betriebsmodelle. Es geht darum, wer den laufenden Betrieb trägt.

Pexon Consulting übernimmt diese Betriebsverantwortung audit-fest aus Deutschland, ab 2.500 EUR im Monat, Mo-Fr 08:00-18:00.

Wann reicht ein internes Platform-Team ohne externen Betrieb?

Die kurze Antwort: wenn die Plattform-Rolle wirklich Betrieb ist, nicht nur Enablement.

Ein internes Team reicht, wenn Upgrades terminiert sind, jemand Policy-Drift schließt, Backup-Schichten Besitzer haben und das Ticket nach 18 Uhr eine vereinbarte Liste trifft, keine Hoffnung. Es reicht nicht, wenn dieselben drei Leute Features, Plattform und Bereitschaft mischen und das Quartal die Features gewinnt.

Unsere Empfehlung: Platform-Team bauen, Betrieb ehrlich benennen. Viele Häuser können Plattform und wollen Day-2 trotzdem abgeben. Das ist kein Versagen. Das ist die Gabel.

Wann ist Self-Managed ehrlich das Ende der Fahnenstange – und wann nur Gewohnheit?

Ehrlich das Ende: ein Cluster, ein Team, Last überschaubar, Übungen finden statt, niemand NIS2-Nachweis vom Dienstleister verlangt.

Gewohnheit: „wir haben das schon immer selbst gemacht“, während niemand das letzte etcd-Backup geprüft hat. Self-Managed ist dann ein Status, kein Modell.

Die Kostenfrage AKS, EKS oder GKE gegen Self-Hosting behandelt unser Vergleich der Betriebsmodelle. Hyperscaler-Managed (AKS) ist eine Plattform-SLA, kein Ersatz für Worker-Patching und App-Day-2.

Wir raten davon ab, Self-Managed als Souveränität zu verkaufen, wenn niemand das Ticket besitzt. Souveränität ohne Bereitschaft ist eine Folie.

Was ein Managed Service tragen muss, das ein Platform-Team intern nicht nebenbei leistet?

Upgrades im Fenster. CVE-Triage auf der Plattform. Policy-Drift, die keine App-Gruppe schließt. Backup-Job, Volume, Datenbank, etcd: vier Ebenen, vier Besitzer oder ein Vertrag, der sie nennt.

Nebenbei heißt: nach dem Daily, vor dem Feature-Freeze. Das reicht für ein Lab. Es reicht nicht für einen Cluster, den Fachbereiche als Produktionsfläche nutzen.

Pexon Consulting übernimmt genau dort, wo die SLA der Plattformanbieter aufhört: Worker, Patching, Day-2. Dokumentiert so, dass die Unterlagen einem Nachweis standhalten.

Welche Betriebsgrenze gilt für Daten, Restore-Übungen und Tickets außerhalb 8×5?

Daten: wer übt Restore, wer besitzt Barman oder Volume, wer etcd. Die geübte Wiederherstellung ist das Kriterium.

Tickets außerhalb 8×5: Der Managed Service von Pexon deckt Mo-Fr 08:00-18:00 ab, kein 24/7. Wer nachts Bereitschaft braucht, muss das gesondert vereinbaren.

Wenn unklar ist, ob der Cluster überhaupt review-fähig ist: 45 Minuten Cluster-Check.

Wann bleiben Sie bei Hyperscaler-Managed (AKS/EKS/GKE) und holen nur Day-2 dazu?

Wenn die Control Plane schon beim Provider liegt und der Schmerz Worker, Policies und der Alltag sind.

AKS nimmt Ihnen etcd-Betrieb ab, nicht das Ticket „Image pullen, Node drainen, Policy driftet“. Day-2 dazu holen ist der häufige Schnitt. Den Cluster in ein fremdes Rechenzentrum zu schieben, ist eine andere Entscheidung.

Drei Fragen, die das Modell entscheiden, bevor jemand einen Vertrag schreibt

Internes Kubernetes-Team oder Managed Service wird in Meetings oft zur Glaubensfrage. Wir machen drei operative Fragen draus:

1. Wer hat das letzte Upgrade wirklich durchgeführt, mit Rollback, in diesem Halbjahr?
2. Wer besitzt Velero, Volume, Datenbank, etcd – vier Namen, nicht ein „das Team“?
3. Was passiert mit einem Sev-1 um 19:10 an einem Dienstag? 8×5 endet um 18:00. Alles danach ist entweder Heldentum oder ein gesonderter Vertrag.

Drei ehrliche Antworten, und das Modell ist da. Self-Managed ohne das letzte Upgrade ist Gewohnheit. Ein Platform-Team ohne die vier Backup-Namen baut, Betrieb ist Luft. Fehlt der Ticketweg nach 18:00, brauchen Sie interne Bereitschaft oder einen externen Day-2, der die Grenze benennt.

1. Upgrade-Kalender schriftlich.
2. Vier Backup-Besitzer schriftlich.
3. Ticketweg nach 18:00 schriftlich.
4. Plattform-Rolle von App-Bereitschaft trennen.
5. Erst dann Vertrag oder bewusst Self-Managed.

Pexon Consulting übernimmt den laufenden Betrieb für den Cluster, den Sie schon haben: ab 2.500 EUR im Monat, Mo-Fr 08:00-18:00, aus Deutschland.

Ein internes Platform-Team, das Golden Paths liefert und Tickets nach 18:00 an die App-Gruppen durchreicht, ist Enablement, kein Betrieb. Enablement ist wertvoll. Es ist ein anderes Wort. Wer es Betrieb nennt, wundert sich, warum niemand das Upgrade zieht.

Self-Managed auf AKS ist kein Widerspruch. Die Control Plane liegt beim Provider, Day-2 kann intern bleiben. Self-Managed On-Prem plus externer Day-2 ist das Spiegelbild. Hosting ist keines von beiden.

Policy-Drift ist der stille Kostenblock. Eine Kyverno-Regel, die niemand mehr erklärt, wird stummgeschaltet. Sechs Monate später fehlt die Schicht. Ein Managed Service, der Drift nicht im Vertrag hat, ist ein Chart-Dienstleister. Wir nehmen Drift in die Betriebsgrenze, oder wir sagen nein.

Backup-Schichten: Velero, Volume, Datenbank, etcd. Vier Namen. Ein Vertrag, der Backup sagt und eine Ebene meint, ist die Finding, die wir vor dem Kickoff schreiben, nicht danach.

Kapazität planen ist Platform. Nodes drainen im Fenster ist Betrieb. Beides im selben Daily zu mischen, gewinnt immer das Feature. Deshalb die Grenze schriftlich, bevor jemand „wir machen das intern“ in das Protokoll schreibt.

NIS2-Nachweis und DORA-Unterlagen verlangen Wiederholbarkeit. Ein Held, der das Upgrade aus dem Kopf macht, ist nicht wiederholbar. Der Managed Service liefert diese Nachweise wiederholbar. Self-Managed trägt ihn nur, wenn das interne Team denselben Satz schreiben kann.

# Betriebsgrenze, kein Hosting-Tarif
platform  = Golden Paths, Enablement
betrieb   = Upgrade, Drift, Ticket, Drill
managed   = Recurring 8x5, Cluster den Sie schon haben

Drei Nein in dieser Tabelle, und Self-Managed ist die Folie, nicht das Modell. Ein Ja reicht nicht, wenn die anderen zwei offen bleiben.

GitOps und RBAC als operative Schnittstelle zwischen Entwicklerteams und Day-2-Betrieb

Die Trennung zwischen interner Plattform-Entwicklung und externem oder dediziertem Betrieb scheitert in der Praxis selten an der grundlegenden Absicht, sondern an unklaren Zugriffsrechten und intransparenten Übergabepunkten. Wenn ein internes Team Plattform-Werkzeuge bereitstellt und der Day-2-Betrieb die Stabilität garantieren soll, reicht ein geteilter Cluster-Admin-Zugang nicht aus. In einer tragfähigen Betriebsstruktur fungiert das GitOps-Repository als verbindliche Demarkationslinie. Entwicklerteams definieren ihre Workloads, Resource-Quotas und Horizontal-Pod-Autoscaler deklarativ in anwendungsspezifischen Repositories. Der Plattform-Betrieb steuert hingegen die Basisinfrastruktur, Ingress-Controller, Service-Meshes und clusterweite Sicherheitsrichtlinien über getrennte Plattform-Repositories. Diese Trennung erzwingt, dass Konfigurationsänderungen über automatisierte Pull-Requests laufen, anstatt manuelle Ad-hoc-Befehle über die Kommandozeile auszuführen, die im Nachgang kein Prüfprotokoll nachweisen kann.

Konflikte entstehen typischerweise an den Randzonen dieser beiden Welten. Tritt ein CrashLoopBackOff auf, stellt sich unmittelbar die Frage nach der Zuständigkeit. Liegt ein Bereitstellungsfehler der Anwendung vor, ist der Fachbereich in der Pflicht, das Anwendungs-Image und die übergebenen Umgebungsvariablen zu korrigieren. Meldet der Worker-Node jedoch Resource-Pressure, greifen Eviction-Policies oder versagen die Storage-Provisioner beim Anhängen persistenter Datenträger, liegt die Behebung eindeutig im Verantwortungsbereich des Plattform-Betriebs. Ohne eine fest definierte Fehlermatrix führt jeder Zwischenfall zu Verzögerungen, weil Anwendungsentwickler vermuten, die Plattform sei instabil, während der Betrieb das Problem in mangelhaft konfigurierten Liveness- und Readiness-Probes der Anwendung vermutet. Eine technische Schnittstellendefinition muss daher exakt festlegen, welche Metriken und Fehlermeldungen automatisch als Plattform-Ticket qualifiziert werden und welche Ereignisse unverändert an den jeweiligen Anwendungsbesitzer zurückgehen.

Ein weiterer Brennpunkt betrifft Custom Resource Definitions und Operator-Lebenszyklen. Moderne Kubernetes-Architekturen stützen sich massiv auf Operatoren für Zertifikate, Monitoring-Agenten oder Ingress-Routing. Das Einspielen neuer CRD-Versionen erfordert häufig clusterweite Berechtigungen, die das Rollenmodell eines Entwicklerteams bewusst überschreiten. Übernimmt ein externer Day-2-Dienstleister diesen Betriebsteil, muss vertraglich und technisch geklärt sein, wer für die Kompatibilität zwischen anwendungsspezifischen Custom Resources und den übergeordneten Plattform-Operatoren haftet. Wird diese Zuständigkeit nicht vorab durch definierte Teststufen auf Staging-Clustern abgefangen, blockiert ein reguläres Operator-Upgrade potenziell Dutzende Fachanwendungen gleichzeitig, ohne dass der Betrieb die genaue Fehlerursache im Code der jeweiligen Anwendung aufklären kann.

Schließlich verlangt die Vergabe von Rollen und Rechten über RBAC eine disziplinierte Begrenzung. Plattform-Teams neigen während intensiver Release-Phasen dazu, Entwicklern temporäre Eskalationsrechte für Namespaces einzuräumen, um Fehler schnell direkt auf der Infrastruktur zu debuggen. Bleiben solche Sonderrechte dauerhaft bestehen, verliert der eigentliche Betrieb die Kontrolle über den Zustand des Gesamtsystems. Ein stabiler Day-2-Betrieb funktioniert ausschließlich dann, wenn privilegierte Zugriffe auditierbar bleiben, Secrets über externe Vault-Mechanismen injiziert werden und kein Entwickler eigenmächtig Security-Context-Constraints oder Network-Policies außer Kraft setzen darf. Nur wenn diese Grenzen technisch durch Admission Controller überwacht werden, kann der Betrieb die zugesagte Verfügbarkeit überhaupt gewährleisten.

Häufig gestellte Fragen

Was kostet der Managed Service?

Der Managed Service beginnt bei 2.500 EUR im Monat, Servicezeit Mo-Fr 08:00-18:00.

Ist Managed Service dasselbe wie Kubernetes-Hosting?

Nein. Hosting ist ein Tarif für Kapazität. Hier geht es um Betriebsverantwortung für den Cluster, den Sie schon haben.

Internes Kubernetes-Team oder Managed Service: können wir beides mischen?

Ja. Plattform intern, Recurring extern. Genau das ist oft die ehrliche Lage. Entweder-oder ist die Folie.

Reicht AKS allein als Managed?

Für die Control Plane ja. Für Worker, Policies und App-Day-2 nein.

Müssen wir Self-Host aufgeben, um Betrieb abzugeben?

Nein. Self-Hosted Control Plane plus externer Day-2 ist ein Modell. Hyperscaler plus Day-2 ist ein anderes. Hosting ist keines von beiden.

Nächster Schritt

Verwandte Themen