Managed Kubernetes: Das Wort leistet ziemlich viel Arbeit

Drei Clouds verkaufen Ihnen Kubernetes mit dem Wort managed davor. Alle drei meinen etwas anderes damit, und die Unterschiede stehen nicht in den Marketing-Tabellen.

Die Control Plane verwaltet jeder. Dieser Teil ist wirklich geklärt: AWS, Microsoft und Google betreiben API-Server und etcd, patchen sie und lassen Sie nicht heran. Wäre das die ganze Geschichte, wäre die Wahl ein Münzwurf.

Die Geschichte beginnt am Node. Dort verschiebt sich die Grenze — und dort kommt die Arbeit zurück, die Sie ausgelagert glaubten.

Was jeder Anbieter verwaltet

Der gemeinsame Boden ist real und verdient eine präzise Beschreibung, denn das ist der Teil, an den Sie tatsächlich nie wieder denken.

AWS beschreibt es über das Shared-Responsibility-Modell: AWS verantwortet die Kubernetes Control Plane inklusive Control-Plane-Nodes und etcd-Datenbank. Microsofts Liste ist länger — API-Server, etcd, DNS-Dienste wie CoreDNS, kube-proxy und Networking außer bei BYOCNI, sowie jedes weitere Add-on oder System-Component im Namespace kube-system. Microsoft erstellt zudem alle 30 Minuten automatische etcd-Backups, die allerdings der eigenen Notfallplanung dienen und Ihnen nicht auf Anforderung zur Verfügung stehen.

Die Asymmetrie beginnt schon hier. Microsoft behandelt CoreDNS und kube-proxy als verwaltete Bestandteile des Clusters. Bei EKS existieren sie als EKS-Add-ons — AWS baut sie, scannt sie, patcht sie und unterstützt sie vollständig, aber es sind eigene Objekte, deren Versionswechsel Sie festlegen. Der Unterschied liegt nicht darin, wer den Patch schreibt, sondern wer entscheidet, wann er landet.

Eine Feinheit dazu: AWS installiert auf jedem Cluster selbstverwaltete Varianten von VPC CNI, kube-proxy und CoreDNS. Ob Sie die verwalteten Add-on-Varianten bekommen, hängt davon ab, wie Sie den Cluster erstellt haben. Die Konsole tut es automatisch, eksctl ab Version 0.184.0 ebenfalls. Auf jedem anderen Weg bleiben die selbstverwalteten, bis Sie sie umstellen.

Wo die Grenze wirklich verläuft: Nodes

Es gibt fünf Modelle, und es sind tatsächlich verschiedene Produkte mit demselben Etikett.

EKS Managed Node Groups. AWS’ eigene Vergleichstabelle beantwortet drei Fragen mit Ja: EC2-Instanzen selbst bereitstellen und verwalten, Betriebssystem selbst absichern und patchen, Node-AMI selbst aktualisieren. Die Konsole meldet Ihnen, dass ein Update verfügbar ist. Klicken müssen Sie. Bei einem eigenen AMI bekommen Sie nicht einmal die Meldung.

AKS. Eine Mittelposition, die leicht falsch gelesen wird. Microsoft liefert ein Basis-OS-Image mit Monitoring- und Netzwerk-Agents, und Nodes erhalten OS-Patches automatisch. Node Auto-Repair startet defekte kubelet-, containerd- oder kube-proxy-Komponenten ohne Ihr Zutun neu. Aber lesen Sie den Abschnitt zur Kundenverantwortung: Microsoft veröffentlicht wöchentlich Patches und neue Node-Images, und Sie müssen sie einspielen. Der Satz für Ihren Kalender: Microsoft unterstützt keine Node-Images, die älter als 90 Tage sind. Kubernetes-Upgrades liegen ebenfalls bei Ihnen.

GKE Standard. Von der Form her am nächsten an AKS Node Pools, aber mit einer spürbar anderen Voreinstellung: Node-Auto-Upgrade ist standardmäßig aktiviert, wenn Sie Cluster oder Node Pool über Konsole oder gcloud anlegen. Nodes werden geleert und neu erstellt, um zur Control-Plane-Version zu passen, mit über Wochen gestaffelten Rollouts. Sie können es abschalten, und Googles Doku benennt die Konsequenz offen: Dann verantworten Sie die Versionskompatibilität selbst — und GKE aktualisiert Nodes trotzdem, sobald eine Version das Support-Ende erreicht, „um die Cluster-Gesundheit sicherzustellen”.

EKS Auto Mode. Dieselbe AWS-Tabelle antwortet nun dreimal Nein. AWS stellt die Instanzen bereit und verwaltet sie, sichert und patcht das Betriebssystem und aktualisiert die Node-Version. Zusätzlich übernimmt es einiges, was Sie sonst selbst installieren: Pod- und Service-Networking, Cluster-DNS, Autoscaling, Block Storage, den Load-Balancer-Controller und den Pod-Identity-Agent. Diese Controller laufen auf AWS-eigener Infrastruktur, Sie sehen sie in Ihrem Konto also unter Umständen gar nicht. Was Sie aufgeben, ist konkret: kein SSH auf Nodes, kein eigenes AMI, kein eigenes CNI, keine Windows-Container, keine Security Groups pro Pod.

GKE Autopilot. Google verwaltet die Nodes vollständig — Bereitstellung, Skalierung, Sicherheits-Patches innerhalb Ihrer Wartungsfenster und Bin-Packing. Jeder Autopilot-Cluster ist in einem Release Channel registriert, Control Plane und Nodes folgen also automatisch qualifizierten Versionen, und Auto-Upgrade lässt sich nicht abschalten. Ein ungenutzter Autopilot-Cluster kann auf null Nodes herunterskalieren, wodurch System-Pods nicht mehr planbar sind — erwartetes Verhalten, das beim ersten Mal überrascht.

Eine Regel gilt überall dort, wo Nodes neu erstellt werden: Änderungen direkt auf der Boot-Disk eines Nodes überleben das nicht. Google sagt es zur Neuerstellung beim Upgrade, Microsoft zu Upgrade, Skalierung und Neustart. Beide verweisen auf dieselbe Lösung — ein DaemonSet.

Das Muster ist durchgängig: Je mehr der Anbieter verwaltet, desto weniger dürfen Sie anpassen. Das ist kein Mangel, sondern der Handel. Der Fehler besteht darin, eine Zeile dieser Tabelle zu erwarten und eine andere zu kaufen.

Die Modifikationsfalle

Bei AKS gibt es eine Regel, die Teams erwischt, die Nodes wie gewöhnliche VMs behandeln, und die Support-Richtlinie sagt es unmissverständlich: Jede Änderung, die direkt über die IaaS-APIs an den Agent-Nodes vorgenommen wird, macht den Cluster nicht mehr supportfähig. Die Nodes erscheinen im Azure-Portal als normale Ressourcen in einer MC_*-Ressourcengruppe. Sie sind keine normalen Ressourcen. Änderungen außerhalb der AKS-API überstehen weder Upgrade noch Skalierung noch Neustart — und kosten Sie den Support.

Der vorgesehene Weg ist ein Kubernetes-nativer: ein privilegiertes DaemonSet oder ein Init-Container für sysctl-Tuning, Security-Agents und Drittsoftware. Microsoft empfiehlt das und sagt gleich dazu, dass es nicht diagnostizieren kann, was Ihr DaemonSet mit dem Node anstellt. Ein fairer, ehrlich benannter Deal — und lesenswert, bevor sich jemand im Team einloggt, um „nur eine Kleinigkeit zu reparieren”.

Managed heißt nicht supported

Hier ein Unterschied, der erst im Incident sichtbar wird: Dass der Anbieter eine Komponente betreibt, und dass er Ihnen hilft, wenn sie ausfällt, sind zwei verschiedene Zusagen.

AKS dokumentiert seine Support-Grenze ungewöhnlich detailliert, und die Ausschlüsse gehören gelesen, bevor Sie darum herum entwerfen. Microsoft Support deckt nicht ab:

• Ingress-Controller von Drittanbietern — nginx, Kong, Traefik. Ausdrücklich eingeschlossen ist der Fall, dass Ihr Ingress-Controller nach einem Kubernetes-Upgrade ausfällt — also genau dann, wenn Sie Hilfe bräuchten.
• Open-Source-Projekte Dritter, die nicht mit dem Cluster ausgeliefert werden — Istio, Envoy und Ähnliches. Für Helm gibt es Best Effort.
• Eigene oder fremde CNI-Plugins im BYOCNI-Modus sowie nicht von Microsoft verwaltete Network-Policy-Konfigurationen.
• DaemonSet-basierte Node-Anpassung — also genau den Mechanismus, den Microsoft für Nodeänderungen empfiehlt.
• Netzwerk-Appliances zur Egress-Kontrolle — VPNs, Firewalls. Für Azure Firewall gibt es Best-Effort-Hinweise.
• Ausstellung und Erneuerung von Zertifikaten für Ihre Anwendungen.

Die CVE-Klausel verdient eine eigene Zeile, weil sie eine Annahme umdreht. Microsoft leistet Schwachstellen-Support nur für Microsoft-verwaltete Komponenten und bearbeitet keine CVEs, deren Hersteller-Fix jünger als 30 Tage ist. Es liegt zudem bei Ihnen, das Node-VHD aktuell zu halten und dem Support eine gefilterte Liste zu übergeben, die nur CVEs mit Fixes älter als 30 Tage enthält.

Lesen Sie die Reihenfolge noch einmal: Sie betreiben den Scanner, Sie aktualisieren das Image, Sie filtern den Bericht — und dann steigt Microsoft ein. Eine vertretbare Arbeitsteilung — nur eben nicht das, was die meisten sich unter managed vorstellen.

Die Managed-Steuer, die niemand nennt

Jeder Anbieter nimmt sich von jedem Node ein Stück, bevor Ihr erster Pod geplant wird. Das ist nicht versteckt — es ist ausführlich dokumentiert — taucht aber selten in Vergleichen auf und verzerrt Ihre Kapazitätsplanung unmittelbar.

GKE reserviert Memory mit 25% der ersten 4 GiB, 20% der nächsten 4 GiB, 10% der nächsten 8 GiB, 6% der nächsten 112 GiB und 2% oberhalb von 128 GiB — plus zusätzlich 100 MiB auf jedem Node für Pod-Eviction. Bei CPU sind es 6% des ersten Kerns, 1% des zweiten, 0,5% der nächsten beiden und 0,25% von allem über vier. Erhöhen Sie Max Pods pro Node über 110, reserviert GKE weitere 400 mCPU. Auf Shared-Core-E2-Maschinen sind es pauschal 1060 Millicores.

Googles eigene Dokumentation zeigt das Ergebnis auf einem 4-vCPU-Node:

capacity:                    allocatable:
  cpu: "4"                     cpu: 3920m
  memory: 16393264Ki           memory: 13498416Ki
  pods: "110"                  pods: "110"

Rund 2,7 GiB eines 16-GB-Nodes sind weg, bevor Sie irgendetwas deployen.

AKS reserviert CPU nach fester Tabelle statt nach Formel:

Beim Memory ist die Reservierung ab AKS 1.29 der kleinere Wert aus 20 MB × Max Pods + 50 MB oder 25% des Gesamtspeichers, plus 100 Mi Eviction-Schwelle. Microsofts Beispiel: Eine 8-GB-VM mit bis zu 30 Pods reserviert 650 MB, es bleiben 90,6% allocatable.

Das sieht besser aus als GKE — und in dieser Konfiguration ist es das auch. Dieselbe Doku zeigt aber, was die ältere Regel kostete: Vor AKS 1.29 lag die Eviction-Schwelle bei 750 Mi und die Reservierung war regressiv, sodass ein 7-GB-Node 34% des Speichers als nicht zuweisbar meldete. Wer eine ältere AKS-Version betreibt, sollte vor jeder Dimensionierung nachsehen.

Hier gibt es einen Folgeeffekt, der direkt ans Autoscaling anschließt: Entscheidungen zur Node-Konsolidierung beruhen auf den Requests der Pods, nicht auf der Nutzung. Reservierte Kapazität verkleinert den Pool, um den diese Requests konkurrieren — ein Node kann also im Dashboard halb leer aussehen und gleichzeitig weder beplanbar noch konsolidierbar sein. Diese Fehlerart habe ich ausführlich in Kubernetes Autoscaling beschrieben.

Was die Control Plane kostet

Das ist die eine Zahl, die alle nennen — und die unwichtigste auf dieser Seite.

Zwei Dinge stechen heraus.

AKS hat als Einziger eine wirklich kostenlose Control Plane. Der Free-Tier enthält alle aktuellen AKS-Funktionen und unterstützt bis zu 1.000 Nodes. Was fehlt, ist ein finanziell abgesichertes SLA — Microsoft benennt Free-Tier-Verfügbarkeit ausdrücklich als Best Effort. Für Entwicklung und kleine Umgebungen ist das eine echte Ersparnis; für Produktion sollte es eine bewusste Entscheidung sein, keine Voreinstellung.

GKEs Gebühr ist wirklich pauschal — 0,10 USD pro Cluster und Stunde, unabhängig von Modus, Größe und Topologie, sekundengenau abgerechnet. Google gibt davon ein Free-Tier-Guthaben von 74,40 USD pro Monat und Rechnungskonto zurück, was einen zonalen Standard- oder Autopilot-Cluster abdeckt. Für regionale Cluster gilt das Guthaben nicht, und nicht genutztes Guthaben verfällt.

Bei rund 73 USD pro Cluster und Monat verliert diese Gebühr jede Bedeutung, sobald echte Nodes laufen. Genau das ist der Punkt: Die Control-Plane-Gebühr ist nicht der Preis des Clusters. Nodes, Load Balancer, zonenübergreifender Verkehr, öffentliche IPv4-Adressen, Storage und Logging sind es. AWS nennt den unauffälligsten Posten direkt auf der Preisseite: Sie zahlen den Cross-AZ-Verkehr von den Nodes zur Control Plane.

Die Rechnung, wenn Sie nicht aktualisieren

Diese Kosten gehörten auf die erste Folie, denn sie sind hoch, vermeidbar und werden fast nie besprochen.

Bei EKS erhält eine Kubernetes-Version 14 Monate Standard Support zu 0,10 USD pro Cluster und Stunde. Danach folgt Extended Support für 12 Monate zu 0,60 USD pro Cluster und Stunde — Grundgebühr plus 0,50 USD Aufschlag. AWS rechnet es selbst vor: 26 Monate Cluster-Betrieb ohne Control-Plane-Upgrade ergeben im Schnitt 0,33 USD pro Stunde, mehr als das Dreifache des Listenpreises.

Google berechnet dieselbe Struktur: Cluster im Extended Release Channel nach Ende des Standard-Supports zahlen 0,50 USD zusätzlich zur Grundgebühr von 0,10 USD, ebenfalls 0,60 USD pro Cluster und Stunde. Bei AKS existiert der Premium-Tier mit 24 Monaten Long Term Support genau dafür.

Multiplizieren Sie das mit einer Flotte. Zwanzig Cluster auf einer alten Version sind der Unterschied zwischen rund 1.460 und 8.760 USD im Monat — für dieselben Cluster mit derselben Arbeit.

Upgrade-Schulden bei Managed Kubernetes sind nicht nur ein Sicherheitsthema. Sie werden abgerechnet.

Ehrlich entscheiden

Die brauchbare Frage lautet nicht, welcher Dienst mehr Funktionen hat. Bei der Control Plane sind sie nahezu gleichwertig, und jede Funktionslücke schließt sich binnen ein bis zwei Releases. Die Frage lautet: Wie viel Betriebsarbeit wollen Sie behalten, und was geben Sie dafür auf, den Rest abzugeben?

Autopilot oder EKS Auto Mode, wenn Nodes aufhören sollen, ein Thema für Ihr Team zu sein, und Sie ohne SSH, eigene AMIs und eigenes CNI auskommen. Für die meisten Anwendungsteams ist das die richtige Voreinstellung, und Google schreibt genau das in die eigene Dokumentation.

Selbst kontrollierte Node-Pools — EKS Managed Node Groups, AKS Node Pools, GKE Standard — wenn Sie eigene AMIs, ein bestimmtes CNI, privilegierte DaemonSets, Windows-Nodes oder Security Groups pro Pod brauchen. Sie entscheiden sich damit für Patching und Upgrades in Eigenregie, wobei die Voreinstellungen abweichen: GKE Standard aktualisiert Nodes automatisch, sofern Sie nicht abschalten, während AKS erwartet, dass Sie die wöchentlichen Images einspielen. Setzen Sie beides auf einen Zeitplan, und behalten Sie bei AKS die 90-Tage-Grenze für Node-Images im Blick.

Der AKS Free-Tier für Entwicklung, Test und Lernumgebungen, in denen ein SLA nicht der Punkt ist. Er ist der Einzige der drei, der für die Clusterverwaltung nichts berechnet.

Und egal wofür Sie sich entscheiden: Planen Sie das Upgrade ein. Nicht zu aktualisieren hat auf zwei der drei Plattformen einen dokumentierten Stundenpreis.

Der Punkt

Managed Kubernetes heißt, dass die Control Plane das Problem eines anderen ist. Alles Weitere ist Verhandlungssache, und die Konditionen unterscheiden sich je Anbieter auf eine Weise, die keine Funktionsmatrix zeigt.

Die drei Fragen, die diese Produkte wirklich trennen:

1. Wer patcht und aktualisiert die Nodes — und was passiert, wenn es niemand tut?
2. Was dürfen Sie im Gegenzug nicht mehr anpassen?
3. Was behält der Node für sich, bevor Ihre Workloads etwas davon sehen?

Beantworten Sie diese drei, und die Wahl trifft sich von selbst. Überspringen Sie sie, erfahren Sie die Antworten später — im Incident Review oder auf der Rechnung.

Weiterlesen: Zu den Autoscaling-Controllern, die darauf aufsetzen, siehe Kubernetes Autoscaling. Zur GKE-spezifischen Variante dieser Abwägung siehe GKE Autopilot vs Standard. Wenn Sie es selbst betreiben wollen, siehe k3s vs k0s vs MicroK8s vs RKE2. Zum Fundament, in dem diese Cluster landen, siehe was in eine Cloud Landing Zone gehört.

Quellen: Security in Amazon EKS, Manage compute resources by using nodes, Amazon EKS add-ons und Amazon EKS pricing; AKS support policies, AKS node resource reservations und AKS pricing tiers; GKE Autopilot overview, Auto-upgrading nodes, About GKE node sizing und GKE pricing. Preise sind US-Listenpreise zum Zeitpunkt der Erstellung und variieren je Region — prüfen Sie die Rechner der Anbieter vor der Budgetierung.