Managed Kubernetes auf Azure: Upgrades und Betrieb ohne euer Team
Azure Kubernetes Service trägt jede Kubernetes-Version zwölf Monate ab Verfügbarkeit, drei Versionen gleichzeitig. Danach fällt der Cluster in den Platform-Support: keine Security-Patches, keine Bugfixes, kein zugesagtes Verfügbarkeits-SLA. Wir übernehmen die Ebene unter der Control Plane: Worker-Nodes, Node-Images, Versionswechsel und die Protokolle darüber. Ab 2.500 EUR im Monat, Servicezeit Mo-Fr 08:00-18:00 MEZ.
Pexon betreibt euren Azure Kubernetes Service mit Upgrade-Verantwortung: Worker-Nodes, Node-Images, geplante Versionswechsel und Day-2, dokumentiert für NIS2- und DORA-Nachweise. Der Cluster bleibt in eurem Azure-Abonnement und auf eurer Rechnung. Ab 2.500 EUR im Monat, Servicezeit Mo-Fr 08:00-18:00 MEZ. Die Control Plane betreibt Microsoft, alles darunter übernehmen wir.
Kern-Themen: Was wir auf Azure übernehmen · Preise und Stufen · Supportfenster und Zuständigkeit · Ablauf der Übernahme · Was wir nicht machen · Häufige Fragen.
Unsere Lösungen
Der Cluster bleibt, wo er ist: in eurem Azure-Abonnement, auf eurer Rechnung. Wir kommen mit Zugriff und Zuständigkeit dazu, nicht mit einer neuen Plattform. Die Tabelle zeigt, was das im AKS-Alltag konkret bedeutet und ab welcher Stufe es enthalten ist.
| Leistung | Was wir auf Azure übernehmen | Enthalten in Stufe |
|---|---|---|
| Upgrade-Kalender | Versionswechsel werden zwölf Monate im Voraus festgelegt, in einer Vorstufe getestet und mit eurem Release-Kalender abgestimmt. Ein geplanter Wechsel mit Rückfallplan statt einer Nachtaktion | L Operations und aufwärts |
| Worker-Nodes und Node-Pools | Bereitstellung, Skalierung, Austausch defekter Knoten und die Betriebssystem-Images darunter, in festen Patch-Zyklen statt nach Zuruf | L Operations und aufwärts |
| Schwachstellen-Bewertung | Neue Schwachstellen werden auf euren Cluster bezogen eingeordnet: betroffen oder nicht, dringend oder planbar. Keine Werkzeugausgabe, sondern eine Entscheidung | L Operations und aufwärts |
| Day-2-Betrieb | Zertifikats-Rotation, Backups mit regelmäßigem Restore-Test, Observability, Alarmierung in eure Kanäle und gepflegte Runbooks. Wie das im Detail aussieht, steht unter Cluster und Workloads überwachen lassen | L Operations und aufwärts |
| Netzwerkweg vor der Wachstumsschwelle | Wir prüfen, ob euer Cluster mit dem Azure Network Policy Manager weiterläuft oder auf Cilium wechseln muss, bevor die Knotenzahl die Entscheidung erzwingt | ab L Platform |
| Plattform-Dienste und GitOps | 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 aus dem GitOps-Repository, Upgrade- und Patch-Protokolle je Cluster, Zugriffsnachweise und ein monatlicher Bericht. 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.
Warum der Azure-Kubernetes-Betrieb im zweiten Jahr teuer wird
Einen AKS-Cluster anzulegen ist der einfache Teil. Teuer wird das zweite Jahr: AKS trägt jede Kubernetes-Version zwölf Monate ab Verfügbarkeit, danach fällt der Cluster aus dem Support (Microsoft Learn, AKS Supported Versions, 2026). Wer das nicht einplant, macht es unter Zeitdruck.
Kubernetes veröffentlicht etwa alle vier Monate eine Minor-Version, AKS trägt genau drei gleichzeitig. Ohne Long Term Support geht nur eine Minor-Version pro Schritt. Das ist kein Projekt, das ist ein Kalender.
Meist kennt genau eine Person den Cluster. Geht sie, geht das Wissen mit. Zwei eigene Vollzeitstellen kosten rund 218.000 EUR im Jahr (Bitkom- und StepStone-Gehaltsdaten, Konfidenz mittel) und decken trotzdem keinen Urlaub ab.
Wer wann welches Node-Image getauscht und welches Upgrade gefahren hat, steht selten irgendwo. Fragt ein Kunde nach dem Betriebsnachweis, beginnt die Rekonstruktion aus Ticket-Verläufen.
Anteil ungenutzter Ressourcen im Branchenschnitt (Datadog State of Cloud Costs, 2024). Der Cluster-Anteil ist eine Architekturfrage, der größere Rest steckt in den Ressourcenanforderungen eurer Workloads und bleibt deshalb bei euren Entwicklern.
Azure Kubernetes Service ist der Kubernetes-Dienst von Microsoft Azure. Microsoft betreibt darin die Control Plane, also API-Server und Steuerungskomponenten, und hält sie verfügbar. Alles darunter bleibt bei euch: Worker-Nodes, Node-Pools, Betriebssystem-Images, Netzwerkmodus, Backups und die Anwendungen selbst.
Genau diese Trennung erzeugt die Arbeit. Verwaltet ist die Steuerungsebene, nicht der Betrieb. Azure Kubernetes betreiben zu lassen heißt deshalb, dass jemand die Ebene unterhalb der Control Plane dauerhaft und schriftlich übernimmt: den Versionsstand jedes Clusters, geplante Upgrades vor dem Ende des Supportfensters, Patch-Zyklen für Node-Images, die Bewertung neuer Schwachstellen auf euren Cluster bezogen, getestete Restores und die Protokolle, mit denen sich all das später belegen lässt.
Wer den AKS-Betrieb abgibt, kauft also keine neue Plattform, sondern Zuständigkeit für eine Ebene, die heute meist an einer einzelnen Person hängt. Der AKS-Betrieb im Retainer lohnt sich, sobald ein produktives Cluster an genau dieser einen Person hängt und das nächste Pflicht-Upgrade in zwölf Monaten ansteht.
Preise und Stufen
Der Einstieg ist die Stufe L Operations für ein produktives Cluster. Alle Werte sind Orientierung für die Budgetplanung, kein verbindliches Angebot: verbindlich wird der Preis erst nach der Bestandsaufnahme, weil Clusterzahl, Versionsstand und Nachweisbedarf ihn bestimmen. Eure Azure-Rechnung bleibt davon unberührt.
L Operations
- Worker-Nodes, Node-Images, Patching
- Geplante AKS-Upgrades mit Rückfallplan
- Day-2 inklusive Backups und Restore-Test
- Observability, Alarmierung, Runbooks
L Platform
- Alles aus L Operations
- Ingress, Secrets, Policies
- Netzwerkweg vor der 250-Knoten-Schwelle geklärt
- GitOps-Repository als Soll-Zustand
XL
- Alles aus L Platform
- Mehrere Cluster und Umgebungen
- Einheitlicher GitOps-Stand über alle Stages
- Abgestimmter Upgrade-Kalender je Cluster
Day-2-Compliance-Retainer
Der Aufsatz für alle, die den AKS-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. Abgenommen ist die Übernahme erst nach protokolliertem Versionswechsel und Restore. Außerhalb der Servicezeit Mo-Fr 08:00-18:00 MEZ sagen wir keinen Dienst zu. Die verbindliche Zahl steht im Angebot, nach der Bestandsaufnahme.
Wie lange unterstützt AKS eine Kubernetes-Version?
Zwölf Monate ab allgemeiner Verfügbarkeit, drei Versionen parallel. Fünf Werte bestimmen, was der AKS-Betrieb über die Zeit kostet. Alle aus Herstellerdokumentation und Branchenstudie, abgerufen am 16.08.2026.
| Kennwert | Wert | Was das im Betrieb heißt | Quelle |
|---|---|---|---|
| Unterstützte Versionen | 3 gleichzeitig | Jede neue Minor-Version schiebt die älteste heraus. Kubernetes veröffentlicht etwa alle vier Monate eine. | Microsoft Learn, AKS Supported Versions, 2026 |
| Support je Version | 12 Monate | Ab allgemeiner Verfügbarkeit. Danach entfallen Security-Patches, Bugfixes und das zugesagte Verfügbarkeits-SLA. | Microsoft Learn, AKS Supported Versions, 2026 |
| Mit Long Term Support | 24 Monate | Nur im Premium-Tier. Verlängert das Supportfenster, nicht die zugesagte Verfügbarkeit. | Microsoft Learn, AKS Long Term Support, 2026 |
| Netzwerk-Schwelle | 250 Knoten | Bis dahin trägt der Azure Network Policy Manager auf Linux-Knoten, darüber empfiehlt Microsoft Cilium. | Microsoft Learn, Netzwerkrichtlinien in AKS, 2026 |
| Leerlauf in den Containerkosten | 83 Prozent | Anteil ungenutzter Ressourcen. Der Cluster-Anteil ist eine Architekturfrage, der Rest steckt in den Anforderungen eurer Workloads. | Datadog State of Cloud Costs, 2024 |
Wer verantwortet was auf Azure
Microsoft betreibt die Control Plane, alles darunter bleibt ohne Vereinbarung bei euch. Die Tabelle zeigt, welche Ebenen wir übernehmen und welche ausdrücklich nicht.
| Ebene | Microsoft | Ohne Vereinbarung | Mit Pexon |
|---|---|---|---|
| Control Plane | betrieben und abgesichert | nichts zu tun | wir prüfen Konfiguration und Versionsstand, betreiben sie aber nicht selbst |
| Worker-Nodes und Node-Pools | nicht enthalten | bei euch | bei uns, inklusive Skalierung und Austausch defekter Knoten |
| Node-Images und Patching | Images werden bereitgestellt | Einspielen und Reboot-Fenster bei euch | bei uns, in festen Zyklen mit angekündigtem Wartungsfenster |
| Versionswechsel | Supportfenster endet nach 12 Monaten | bei euch, meist unter Zeitdruck | bei uns, zwölf Monate im Voraus geplant, mit Test und Rückfallplan |
| Eure Anwendung | ausgeschlossen | bei euren Entwicklern | bleibt bei euren Entwicklern, wir alarmieren auf eure Anwendungs-Metriken |
| Azure-Rechnung | stellt Microsoft | euer Abonnement, euer Vertrag | bleibt unberührt, wir verkaufen keine Cloud-Kapazität weiter |
| Audit-Nachweis | Zertifikate der Plattform, nicht eures Betriebs | entsteht rückwirkend, wenn überhaupt | Änderungshistorie, Upgrade- und Zugriffsnachweise aus eurem Betrieb |
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
Die Control Plane, eure Anwendung, der Dienst nachts und am Wochenende, die Rechtsfrage. Wer eines davon braucht, ist bei uns falsch, und das früh zu wissen spart beiden Seiten Zeit.
Wir betreiben die Control Plane nicht
Die betreibt Microsoft, und das ist gut so. Wir prüfen Konfiguration und Versionsstand und planen den Wechsel, bevor das Supportfenster zuläuft. Die Managed-Komponenten selbst fassen wir nicht an, dafür gibt es den Azure-Support.
Keine Anwendungsentwicklung
Code, Ressourcenanforderungen und Release-Entscheidungen bleiben bei euren Entwicklerinnen und Entwicklern. Dort steckt auch der größere Teil der Kostenoptimierung: der Leerlauf sitzt meist in den Requests und Limits, nicht im Cluster-Zuschnitt.
Kein Dienst außerhalb der Servicezeit
Unsere Servicezeit ist Mo-Fr 08:00-18:00 MEZ. Nacht- und Wochenendabdeckung sagen wir nicht zu, weil wir sie nicht dauerhaft besetzen können. Die Arbeit steckt stattdessen davor: Redundanz über Zonen, getestete Backups, Runbooks.
Kein Wiederverkauf und keine Rechtsberatung
Eure Azure-Rechnung bleibt eure Azure-Rechnung, wir schlagen nichts auf Infrastruktur auf. Und ob ihr unter NIS2 oder DORA fallt, beantwortet eure Rechtsabteilung. Wir liefern die technischen Nachweise, mit denen diese Prüfung geführt werden kann.
Wo wir das bereits betreiben
Ein laufendes Betriebsmandat, eine veröffentlichte AKS-Migration und die Zahl, an der ihr die Alternative messen könnt. 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 →Migration zu Azure Kubernetes Service in der Versicherungsbranche
Für einen Versicherer haben wir die Workloads auf Azure Kubernetes Service migriert. Der Fall zeigt den Schritt davor: erst entsteht die Plattform, danach braucht sie jemanden, der Versionswechsel, Node-Images und Nachweise dauerhaft verantwortet. Genau dieser zweite Schritt ist der Betrieb, den diese Seite beschreibt.
Zur Case Study →Was die Alternative im eigenen Haus kostet
Vollkosten für zwei Plattform-Engineers, die den Cluster im Wechsel tragen könnten, gerechnet auf Basis von Bitkom- und StepStone-Gehaltsdaten (Konfidenz mittel, keine Pexon-Kalkulation). Eine Stelle deckt keine Vertretung ab, zwei sind für ein Cluster schwer zu rechtfertigen. Suche und Einarbeitung liegen vor der ersten Entlastung, nicht danach.
Stufe und Preis selbst ermitteln →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 Azure-Abonnement.
Bestandsaufnahme
Versionsstand jedes Clusters, Node-Pools, Netzwerkmodus, Backups und vorhandene Dokumentation. Ergebnis ist eine Lückenliste mit Reihenfolge, nicht ein Angebot mit Pauschale.
Zugriffe und GitOps
Rollen, Zugriffe 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 laufen der erste geplante Versionswechsel und der erste Restore-Test, damit beides einmal unter Beobachtung passiert ist.
Abnahme
Abgenommen ist die Übernahme, wenn Versionswechsel und Restore ohne Zutun eures Teams durchgelaufen und protokolliert sind. Vorher endet der Parallelbetrieb nicht.
Wie der Azure-Betrieb danach funktioniert
Sechs wiederkehrende Schritte, die nach der Abnahme den Alltag bestimmen.
Versionsstand führen
Für jedes Cluster ist festgehalten, wie viele Monate die laufende Version noch trägt. Der Upgrade-Termin steht, bevor das Supportfenster zuläuft.
Node-Images patchen
Betriebssystem-Images und Cluster-Komponenten laufen in festen Zyklen, mit angekündigten Wartungsfenstern statt Ad-hoc-Reboots im laufenden Geschäft.
Schwachstellen bewerten
Neue Schwachstellen werden auf euren Cluster bezogen eingeordnet: betroffen oder nicht, dringend oder planbar.
Restore testen
Ein Backup ist erst dann eins, wenn ein Restore durchgelaufen ist. Wir testen ihn regelmäßig und protokollieren das Ergebnis.
Alarmieren und eskalieren
Alarme laufen in eure Kanäle, Eskalationswege sind schriftlich festgelegt. Servicezeit Mo-Fr 08:00-18:00 MEZ, mit benannten Ansprechpartnern.
Monatlich berichten
Ein Bericht je Monat: Änderungen, Upgrades, Patches, Zugriffe. Genau die Unterlage, nach der eure Revision sonst rückwirkend sucht.
Wo ihr mit dem AKS-Betrieb anfangt
Fünf Wege von hier aus: drei benachbarte Betriebsformen, falls euer Cluster gar nicht auf Azure liegt, und zwei Einstiege, die nichts kosten.
Wenn der Cluster woanders läuft
Dieselbe Betriebsverantwortung, andere Unterlage. Welche der drei Seiten ihr braucht, entscheidet sich daran, wo euer Cluster heute steht.
Managed Kubernetes im Überblick
Die Mutterseite zu dieser: Leistungsumfang je Stufe, Preise, Zuständigkeitsgrenze zu den Plattformanbietern und der Ablauf der Übernahme, unabhängig davon, auf welcher Infrastruktur euer Cluster läuft.
Managed Kubernetes im Überblick ansehenKubernetes-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 zum AKS-Betrieb
Aus Erstgesprächen mit CTOs, Plattform-Verantwortlichen und IT-Leitungen im DACH-Raum.
Was passiert, wenn unser AKS-Cluster aus dem Support fällt?
Wann lohnt sich AKS Long Term Support?
Was kostet Managed Kubernetes auf Azure?
Bleibt unser Cluster in unserem Azure-Abonnement?
Was übernehmt ihr auf Azure nicht?
Brauchen wir ein AKS-Projekt oder den AKS-Betrieb?
Womit eure Revision arbeiten kann
Kein Vertrauensvorschuss, sondern Unterlagen. Nachweise fallen im Betrieb ohnehin an, wir halten sie so fest, dass sie einer Prüfung standhalten. Nebenbei, nicht rückwirkend.
Pexon als Dienstleister
- ISO 27001 zertifiziert
- Auftragsverarbeitung nach DSGVO
- Microsoft Solutions Partner
- Betrieb in eurem Azure-Abonnement, nicht in unserem
- Vertrag, Rechnung und Ansprache auf Deutsch
Betriebsmodell auf Azure
- Upgrade-Kalender zwölf Monate im Voraus
- Test in einer Vorstufe, Rückfallplan je Versionswechsel
- Feste Patch-Zyklen für Node-Images und Cluster-Komponenten
- 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
Sagt uns euren Versionsstand, wir sagen euch den Aufwand
Ihr nennt Clusterzahl, Kubernetes-Version und Nachweisbedarf. Wir sagen euch in 60 Minuten, welche Ebenen heute niemand verantwortet und was die Übernahme kostet. Die Lückenliste nützt euch auch dann, wenn ihr selbst weiterbetreibt.
Nachricht senden
Lieber schriftlich? Schreibt uns, wir melden uns innerhalb von 24 Stunden.
Wenn der AKS-Betrieb 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.
Kubernetes-Betrieb im Überblick
Die Kategorie-Ebene über allem: welche Betriebsform zu euch passt, was Beratung von Betrieb unterscheidet und welche Regelwerke greifen.
Verwandte Inhalte
Stand 24. August 2026 · Managed Kubernetes im Überblick · 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.
Vertrieb kontaktieren