GKE Autopilot vs Standard 2026: Die echten Trade-offs

Die Wahl zwischen GKE Autopilot und Standard sieht wie eine Checkbox bei der Cluster-Erstellung aus. Es ist tatsächlich eine Entscheidung, die dein Abrechnungsmodell, deine Betriebsgrenzen und die ausführbaren Workloads für die gesamte Lebensdauer des Clusters festlegt. Der Modus lässt sich danach nicht mehr wechseln.

Die meisten Vergleiche listen Features auf. Dieser beginnt dort, wo die Feature-Liste die eigentliche Antwort verbirgt: wer die Worker-Node-Schicht besitzt.

Das Eine, was beide Modi gemeinsam haben

Beide Modi betreiben dieselbe von Google verwaltete Control Plane. etcd, API-Server, Scheduler, Controller Manager — Google verwaltet, aktualisiert und betreibt alles davon hochverfügbar. Du provisionierst keinen Control-Plane-Node, weil es keinen zu provisionieren gibt. Es ist ein vollständig verwalteter Dienst hinter dem container.googleapis.com-Endpunkt.

Das ist kein Differenzierungsmerkmal. Der eigentliche Unterschied liegt vollständig unterhalb der Control Plane.

Autopilot: Die Node-Schicht verschwindet

Im Autopilot-Modus abstrahiert Google alles unterhalb der Pod-Ebene.

Node-Provisioning ist automatisch. Du erstellst oder löschst keine Node Pools. Wenn du einen Pod mit einem gültigen Resource-Request deployest, provisioniert Google automatisch einen passenden Node. Wenn der Pod endet, skaliert der Node herunter. Der Node ist ein Implementierungsdetail, das du nicht verwaltest.

Du forderst Kapazität an, keine Maschinen. Standardmäßig (GKE 1.32.3-gke.1927002 und später) laufen Pods auf der Container-optimierten Compute-Plattform — Nodes, die zur Laufzeit dynamisch skalieren und ab Bruchteilen einer vCPU wachsen, sodass neue Pods selten auf das Booten eines Nodes warten. Braucht ein Workload spezifische Hardware, forderst du eine ComputeClass an, statt einen Node Pool zu verwalten:

• Balanced / Scale-Out — General-Purpose; Scale-Out wählt Arm (T2A) für zustandslose Dichte
• Performance — Compute-optimierte Machine-Serie
• Accelerator — GPUs und TPUs, angefordert in der ComputeClass oder im Pod-Spec
• autopilot-spot — unterbrechungstolerante Spot-Pods

GKE provisioniert und dimensioniert die passenden Nodes automatisch.

Security-Posture wird erzwungen. Pods laufen standardmäßig als Nicht-Root, hostPath-Volumes und Host-Networking sind gesperrt, und Google pflegt das Node-OS. Diese Einschränkungen sind keine Konfigurationsoptionen — sie machen das verwaltete Modell möglich.

Resource-Requests sind Pflicht. Autopilot lehnt Pods ohne resources.requests ab. Das bricht Workloads, die sie wegzulassen, aber es ist ohnehin die richtige Einschränkung.

Standard: Du besitzt die Node-Schicht

Im Standard-Modus bist du der Node-Betreiber.

Node Pools gehören dir. Du erstellst sie, wählst Machine-Familien (n2, n2d, c3, t2d, m3, a2/a3 GPU und mehr), konfigurierst Boot-Disk-Größe, setzt Node-Taints und -Labels und entscheidest über die Upgrade-Strategie.

Vollständige Workload-Freiheit. Privilegierte Container, eigene DaemonSets für deine Agents, hostPath-Volumes, Host-Networking, Windows-Workloads — alles unterstützt. Das ist der Modus, wenn dein Security-Tooling, dein Netzwerk-Plugin oder dein Compliance-Agent Low-Level-Node-Zugriff benötigt.

Dein Upgrade-Takt. Du konfigurierst die Node-Pool-Upgrade-Strategie (Surge- oder Blue-Green-Upgrades), Wartungsfenster und Patch-Ausschlüsse.

Abrechnung ist vorhersehbar, aber unerbittlich. Du zahlst für die GCE-VMs in deinen Node Pools, unabhängig davon, ob Pods darauf laufen oder nicht. Drei n2-standard-8-Nodes in europe-west3 für 24 Stunden → du zahlst für 72 vCPU-Stunden und 288 GB-Stunden RAM, unabhängig von der tatsächlichen Pod-Last.

Das Abrechnungsmodell ist die eigentliche Entscheidung

Hier machen Teams teure Fehler.

Autopilot-Kosten = Summe der Pod-resources.requests × Einheitstarife (vCPU-Stunde + GB-Stunde + Ephemeral-Storage-GB-Stunde). Die Tarife enthalten einen Managed-Cluster-Aufschlag gegenüber reinen VM-Äquivalenten — etwa 10–20 % pro Einheit. Keine Pods → keine Compute-Kosten.

Ein Detail, das viele überrascht: Die Pod-Abrechnung gilt nur für General-Purpose-Pods. Sobald ein Pod spezifische Hardware wählt — eine GPU, eine TPU oder eine benannte Compute-Engine-Machine-Serie — wechselt Autopilot diesen Workload auf Node-basierte Abrechnung (ganzer Node plus Management-Aufschlag), genau wie Standard. Autopilots „zahle nur, was Pods anfordern“ gilt für General-Purpose-Compute, nicht für Accelerator-Nodes.

Standard-Kosten = Summe der Node-VM-Preise × Laufstunden. Ein Node bei 20 % Auslastung kostet dasselbe wie ein Node bei 95 %.

Der Kipppunkt: Bei etwa 70–80 % konstanter Node-Auslastung unterschreiten die Standard-Gesamtkosten in der Regel die von Autopilot. Unterhalb dieser Schwelle ist Autopilot meistens günstiger.

In der Praxis:

• Dev- und Test-Cluster: Autopilot gewinnt fast immer. Variable Last, Pods idle über Nacht, niemand skaliert manuell herunter.
• Batch-Workloads mit Spitzen: Autopilot gewinnt — du zahlst für die Spitze, nicht für die Wartezeit.
• Produktions-Cluster mit stabiler, hoher Last: Kalkuliere es durch. Wenn deine p50-Node-Auslastung zuverlässig über 75 % liegt, ist Standard wahrscheinlich günstiger.
• Keine überspezifizierten Resource-Requests in Autopilot — überhöhte Requests erhöhen direkt die Rechnung.

Was sich geändert hat — und was Autopilot 2026 noch nicht kann

Die Lücke zwischen den Modi ist seit dem Autopilot-Launch 2021 deutlich geschrumpft. Was inzwischen auf Autopilot funktioniert:

• GPUs und TPUs — über eine ComputeClass oder das Pod-Spec angefordert; keine Accelerator-Node-Pools zu verwalten
• Spot-Pods — unterbrechungstolerante Kapazität pro Pod, kein Spot-Node-Pool
• Arm (T2A) — über die Scale-Out-Klasse oder eine Arm-ComputeClass
• DaemonSets — unterstützt, solange sie keinen erhöhten Zugriff auf den Node benötigen (die meisten Monitoring- und Logging-Agents erfüllen das)
• Confidential GKE Nodes — AMD-SEV-Speicherverschlüsselung ist jetzt eine Autopilot-Option, kein Standard-Alleinstellungsmerkmal mehr
• GKE Sandbox (gVisor) — auf Autopilot standardmäßig aktiv, für eine zusätzliche Syscall-Isolationsschicht
• GKE Dataplane V2, CMEK, Binary Authorization, Workload Identity Federation — alle verfügbar, mehrere standardmäßig aktiv

Die harten Grenzen, die bleiben — die echten Gründe für Standard:

• Kein erhöhter Node-Zugriff — privilegierte Container und alles, was Root auf dem Host braucht, wird abgelehnt; ein Agent, der den Node direkt anfassen muss, läuft nicht
• Kein Node-SSH — kein SSH oder Exec in Worker-Nodes; Debug auf Pod-Ebene
• Kein eigenes Node-OS — Autopilot nutzt ausschließlich Container-Optimized OS, kein Ubuntu-Image, keine eigenen Startup-Skripte
• Keine Windows-Nodes — nur Linux-Workloads
• Kein Host-Networking, keine beliebigen hostPath-Volumes — Node-erzwungene Security-Einschränkungen
• Keine Cloud-Marketplace-Apps und kein externalIPs-Service-Feld

Zwei Korrekturen, die erwähnenswert sind, weil ältere Vergleiche sie falsch darstellen: DaemonSets und Confidential GKE Nodes funktionieren 2026 beide auf Autopilot. Der Blocker war nie „DaemonSet“ — es ist erhöhter Node-Zugriff.

Gegenüberstellung: Das vollständige Bild

Die Grenze verwischt 2026

Zwei Änderungen machen die Wahl weniger binär als früher.

Autopilot-Workloads innerhalb von Standard-Clustern. Du musst nicht mehr einen Modus für den ganzen Cluster wählen. In einem Standard-Cluster kannst du einzelne Workloads im Autopilot-Modus laufen lassen, indem du eine Autopilot-ComputeClass anforderst — GKE provisioniert und verwaltet diese Nodes für dich, während der Rest des Clusters mit deinen eigenen Node Pools unter deiner Kontrolle bleibt. Händefreie Nodes für die Workloads, die sie wollen, volle Kontrolle für die, die sie brauchen.

Die Container-optimierte Compute-Plattform. Auf aktuellen Versionen (GKE 1.32.3-gke.1927002+) laufen General-Purpose-Autopilot-Pods auf Nodes, die zur Laufzeit dynamisch skalieren und aus einem Pool vorbereitgestellter Kapazität schöpfen. Das beseitigt den größten Teil der Cold-Start-Verzögerung, die früher Autopilots Schwachstelle war — neue Pods werden meist eingeplant, ohne auf einen frischen Node zu warten.

Fazit: „Autopilot vs Standard“ wird zunehmend zu „wie viel von diesem Cluster soll verwaltet sein“ — statt zwei getrennten Welten.

Wie man wählt: Drei Fragen

1. Benötigt ein Workload erhöhten Node-Zugriff — privilegierte Container, ein DaemonSet, das den Node anfasst, Node-SSH, ein eigenes oder Ubuntu-Node-OS oder Windows-Nodes?

Wenn ja → Standard, ohne Diskussion. Das sind harte Einschränkungen in Autopilot, keine Einstellungen. (Was nicht mehr auf dieser Liste steht: GPUs, TPUs, Spot, Arm und Confidential GKE Nodes laufen alle auf Autopilot.)

2. Läuft dein Cluster bei konstant hoher Node-Auslastung (über ~75%)?

Wenn ja → Standard durchrechnen. Bei konstant hoher Auslastung nutzt du die VMs, für die du zahlst, vollständig — und der Standard-VM-Preis unterbietet Autopilots Pod-Request-Preis. Nutze den GCP Pricing Calculator mit deinen tatsächlichen Resource-Requests.

3. Soll das Team, das diesen Cluster betreibt, Infrastruktur verwalten?

Wenn nein → Autopilot. Dev-Umgebungen, interne Developer-Plattformen, SaaS-Produktcluster, Batch-Verarbeitung — Autopilot beseitigt den Node-Pool-Verwaltungsaufwand, damit das Team sich auf die Applikationsschicht konzentriert.

Im Zweifel: Autopilot als Standard für neue Cluster, es sei denn, eine der harten Grenzen greift. Für die Workloads, die es benötigen, kann immer ein paralleler Standard-Cluster betrieben werden.

Ein Muster, das in großem Maßstab funktioniert

Beim Aufbau der ersten Produktions-GCP-Plattform bei der Deutschen Telekom hat sich mit der Zeit diese Aufteilung ergeben:

• Standard für die Produktions-Datenebene: konstant hohe Auslastung, Security-DaemonSets für Compliance-Agents, vollständige Dataplane-V2-Konfiguration, Spot-Node-Pools für Batch-Verarbeitung.
• Autopilot für Dev- und Pre-Prod-Umgebungen: automatisches Scale-to-Zero an Wochenenden und nachts, keine Idle-Node-Kosten, Entwickler erhalten einen Cluster, ohne ihn besitzen zu müssen.

Beide Cluster-Typen treten demselben GKE Enterprise Fleet bei, teilen Policy-Controller-Regeln und werden aus demselben Cloud-Monitoring-Workspace überwacht. Der Modus ist ein Implementierungsdetail; die Governance-Schicht liegt über beiden.

Die Security-Grundlage ändert sich nicht

Unabhängig vom gewählten Modus sind diese Maßnahmen identisch und nicht verhandelbar:

Workload Identity Federation — keine Service-Account-Schlüsseldateien auf Nodes oder in Pods. WIF stellt kurzlebige OIDC-Token aus. Den vollständigen Ansatz zur Eliminierung von SA-Schlüsseln findest du in Service-Account-Schlüssel abschaffen: Workload Identity Federation auf GKE.

Binary Authorization — erzwinge, dass nur signierte, geprüfte Images in deinem Cluster laufen.

GKE Dataplane V2 — eBPF-basierte Network-Policy-Durchsetzung (Cilium). Standard bei Autopilot; opt-in bei Standard.

Least-Privilege RBAC — ClusterAdmin für Menschen ist fast nie korrekt. Binde Rollen an Service Accounts, nicht direkt an Google-Identitäten.

Node-Auto-Upgrade — konfiguriere bei Standard einen Release-Channel (Regular oder Stable) und aktiviere Auto-Upgrade. Rückstand bei Node-Versionen ist die häufigste Ursache vermeidbarer Security-Exposition in produktiven GKE-Clustern. Bei Autopilot übernimmt Google das.

Mehr zu Isolations-Trade-offs beim Betrieb nicht vertrauenswürdiger Workloads innerhalb von GKE findest du in MicroVMs 2026: Firecracker vs gVisor für sichere Workloads.