Autopilot-Übersicht

Einführung

Autopilot ist ein neuer Betriebsmodus in Google Kubernetes Engine (GKE), mit der die Betriebskosten für die Verwaltung von Clustern gesenkt, Ihre Cluster für die Produktion optimiert und eine höhere Verfügbarkeit der Arbeitslast erzielt werden sollen. Der Betriebsmodus bezieht sich auf den Grad der Flexibilität, Verantwortung und Kontrolle, den Sie über den Cluster haben. Neben den Vorteilen einer vollständig verwalteten Steuerungsebene und Knotenautomatisierung bietet GKE zwei Betriebsmodi:

Autopilot: GKE stellt und verwaltet die zugrunde liegende Infrastruktur des Clusters, einschließlich Knoten und Knotenpools, und ermöglicht Ihnen einen optimierten Cluster mit praktischer Erfahrung.
Standard: Sie verwalten die zugrunde liegende Infrastruktur des Clusters und damit Flexibilität bei der Knotenkonfiguration.

Mit Autopilot müssen Sie die Integrität Ihrer Knoten nicht mehr überwachen und die benötigte Rechenkapazität nicht mehr berechnen. Autopilot unterstützt die meisten Kubernetes APIs, Tools und dessen umfangreiche Platform. Sie bleiben in GKE und müssen nicht mit den Compute Engine APIs, CLIs oder der UI interagieren, da die Knoten nicht über Compute Engine zugänglich sind, wie sie sich im Standardmodus befinden. Sie bezahlen nur für die CPU-, Arbeitsspeicher- und Speicherkapazität, die Ihre Pods in der Ausführung anfordern.

Autopilot-Cluster sind mit einer optimierten Cluster-Konfiguration vorkonfiguriert, die für Produktionsarbeitslasten bereit ist. Diese optimierte Konfiguration folgt den Best Practices und Empfehlungen von GKE für die Einrichtung und Sicherheit von Clustern und Arbeitslasten. Einige dieser integrierten Einstellungen (siehe Tabelle unten) sind unveränderlich und andere optionale Einstellungen können aktiviert oder deaktiviert werden.

Autopilot bietet ein SLA, das sowohl die Steuerungsebene als auch Ihre Pods abdeckt. Mit Autopilot können Sie sich auf die Kubernetes-API und Ihre Bereitstellungen konzentrieren, da die zugrunde liegende Infrastruktur abstrahiert wird. Autopilot verwendet die von Ihnen in den PodSpec definierten Ressourcenanforderungen und stellt die Ressourcen für die Bereitstellung bereit, z. B. CPU, Arbeitsspeicher und nichtflüchtige Speicher.

Es gibt zwei Hauptgründe, warum Sie anstelle des Autopilot den Standardmodus verwenden sollten:

Sie benötigen eine höhere Kontrolle über die Clusterkonfiguration.
Ihre Cluster müssen Arbeitslasten ausführen, die nicht den Einschränkungen für den Autopilot entsprechen.

Autopilot und Standardmodi vergleichen

Mit Autopilot verwaltet GKE viele Komplexitäten des Lebenszyklus Ihres Clusters. Die folgende Tabelle enthält Optionen, die je nach Betriebsmodus für den Cluster verfügbar sind:

Vorkonfiguriert: Diese Einstellung ist eingebunden und kann nicht geändert werden.
Standard: Diese Einstellung ist aktiviert, kann aber überschrieben werden.
Optional: Diese Einstellung ist deaktiviert, aber Sie können sie aktivieren.

Optionen	Autopilot-Modus	Standardmodus
Grundlegender Clustertyp	Verfügbarkeit und Version: Vorkonfiguriert: Regional Standard: Reguläre Release-Version	Verfügbarkeit und Version: Optional: Regional oder zonal Release-Version oder statische Version
Knoten und Knotenpools	Von GKE verwaltet.	Von Ihnen verwaltet, konfiguriert und angegeben.
Bereitstellung von Ressourcen	GKE stellt Ressourcen dynamisch basierend auf Ihrer Pod-Spezifikation bereit.	Sie stellen zusätzliche Ressourcen manuell bereit und legen die Gesamtgröße des Clusters fest. Automatische Skalierung von Clustern und automatischer Knotenbereitstellung automatisieren, um den Prozess zu automatisieren
Image-Typ	Vorkonfiguriert: Container-Optimized OS mit containerd	Wählen Sie eine der folgenden Optionen aus: Container-Optimized OS mit containerd Container-Optimized OS mit Docker Ubuntu mit containerd Ubuntu mit Docker Windows Server LTSC Windows Server SAC
Abrechnung	Für Pod-Ressourcenanfragen (CPU, Arbeitsspeicher und flüchtiger Speicher) bezahlen	Bezahlung pro Knoten (CPU, Arbeitsspeicher, Bootlaufwerk)
Sicherheit	Vorkonfiguriert: Workload Identity Shielded-Knoten Secure Boot Optional: CMEK-verschlüsselte angehängte nichtflüchtige Speicher	Optional: Workload Identity Shielded-Knoten Secure Boot Verschlüsselung von Secrets auf Anwendungsebene Binärautorisierung Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) Google Groups RBAC
Netzwerk	Vorkonfiguriert: VPC nativ (Alias-IP) Maximal 32 Pods pro Knoten Knoteninterne Sichtbarkeit Standardeinstellung: Öffentlicher Cluster Standardmäßige CIDR-Bereiche Hinweis: Prüfen Sie Ihre CIDR-Bereiche, um das erwartete Clusterwachstum zu berücksichtigen. Netzwerkname/Subnetz Optional: Privater Cluster Cloud NAT ¹ (nur private Cluster) Autorisierte Netzwerke	Optional: VPC nativ (Alias-IP) Maximal 110 Pods pro Knoten Knoteninterne Sichtbarkeit CIDR-Bereiche und maximale Clustergröße Netzwerkname/Subnetz Privater Cluster Cloud NAT ¹ Netzwerkrichtlinie Autorisierte Netzwerke
Upgrades, Reparatur und Wartung	Vorkonfiguriert: Automatische Knotenreparatur Knoten automatisch aktualisieren Wartungsfenster Surge-Upgrades	Optional: Automatische Knotenreparatur Knoten automatisch aktualisieren Wartungsfenster Surge-Upgrades
Anmeldedaten für die Authentifizierung	Vorkonfiguriert: Workload Identity	Optional: Compute Engine-Dienstkonto Workload Identity
Skalieren	Vorkonfiguriert: Autopilot verwaltet die gesamte Skalierung und Konfiguration Ihrer Knoten. Standardeinstellung: Sie konfigurieren das Horizontale Pod-Autoscaling (HPA) Sie konfigurieren das Vertikale Pod-Autoscaling (VPA).	Optional: Automatische Knotenbereitstellung Sie konfigurieren das Cluster-Autoscaling. HPA VPA
Monitoring und Logging	Vorkonfiguriert: Cloud Operations for GKE Standard: Logging für System und Arbeitslasten Optional: Logging nur für System	Standardeinstellung: Cloud Operations for GKE Logging für System und Arbeitslasten Optional: Logging nur für System
Routing	Vorkonfiguriert: Pod-basiertes Routing. Netzwerk-Endpunktgruppen (NEGs) aktiviert.	Wählen Sie knotenbasierte Weiterleitung von Paketen (Standard) oder Pod-basierte Weiterleitung aus.
Cluster-Add-ons	Vorkonfiguriert: HTTP-Load-Balancing Standardeinstellung: CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine NodeLocal DNSCache	Optional: CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine HTTP-Load-Balancing NodeLocal DNSCache Cloud Build Cloud Run Cloud TPU Config Connector Istio in Google Kubernetes Engine Kalm Nutzungsmessung

¹Weitere Konfiguration erforderlich, um Cloud NAT in einem Cluster zu aktivieren.

Nicht unterstützte Clusterfeatures

Die folgenden GKE-Clusterfunktionen werden für Autopilot-Cluster nicht unterstützt:

Compute Engine-Instanzen

VMs auf Abruf

Sicherheit

Add-ons und Integrationen

Skalieren

Autopia skaliert die Ressourcen des Clusters automatisch anhand Ihrer Pod-Spezifikationen, sodass Sie sich auf Ihre Pods konzentrieren können. Um die Anzahl der Pods automatisch zu erhöhen oder zu verringern, können Sie das horizontale Pod-Autoscaling mithilfe der Standard-Kubernetes-CPU- oder -Speichermesswerte oder mithilfe benutzerdefinierter Messwerte über Cloud Monitoring implementieren.

Zulässige Ressourcenbereiche

In der folgenden Tabelle sind die zulässigen Ressourcenbereiche für Autopilot-Pods aufgeführt. Alle Werte gelten für die Summe aller Containerressourcenanfragen im Pod, sofern nicht anders angegeben. Pod-vCPUs sind in Schritten von 0,25 vCPUs verfügbar. Zusätzlich zu den Mindestwerten muss das Verhältnis zwischen CPU und Arbeitsspeicher zwischen 1 vCPU und 1 GiB bis 1 vCPU: 6,5 GiB liegen. Ressourcen außerhalb der zulässigen Verhältnisbereiche werden hochskaliert. Weitere Informationen finden Sie unter Ressourcenbereiche und Verhältnisverwaltung und Beispiele für Ressourcenlimits.

Ressource	Minimale Ressourcen		Maximale Ressourcen
Ressource	Normale Pods	DaemonSet-Pods	Normale Pods und DaemonSet-Pods
CPU	250 mCPU	10 mCPU	28 vCPU²
Speicher	512 MiB	10 MiB	80 GiB²
Sitzungsspezifischer Speicher	10 MiB (pro Container)	10 MiB (pro Container)	10 GiB

²Die maximalen CPU- und Arbeitsspeicherlimits für normale Pods werden zusätzlich durch die Gesamtsumme der Ressourcenanfragen aller DaemonSet-Pods reduziert.

Standardanfragen für Containerressourcen

Autopilot stützt sich auf Ihre Angaben in der Deployment-Konfiguration, um Ressourcen bereitzustellen. Wenn Sie für einen Container im Pod keine Ressourcenanfragen angeben, wendet Autopilot Standardwerte an. Mit diesen Standardeinstellungen erhalten die Container in Ihren Pods eine durchschnittliche Menge an Ressourcen, die für viele kleinere Arbeitslasten geeignet sind.

Autopilot wendet diese Standardwerte auf Ressourcen an, die nicht in der Pod-Spezifikation definiert sind.

Ressource	Container in normalen Pods	Container in DaemonSets
CPU	500 mCPU	50 mCPU
Speicher	2 GiB	100 MiB
Sitzungsspezifischer Speicher	1 GiB	100 MiB

Weitere Informationen zu den Limits für Autopilot-Cluster finden Sie unter Kontingente und Limits.

Limits und Beschränkungen für Arbeitslasten

Autopilot unterstützt die meisten Arbeitslasten, die Ihre Anwendungen ausführen. Damit GKE die Verwaltung der Knoten anbietet und eine optimierte Nutzung für Sie sorgt, gibt es im Vergleich zu GKE Standard einige Limits und Beschränkungen. Einige dieser Einschränkungen sind Best Practices für die Sicherheit, während andere einen Autopilot-Cluster sicher verwalten können. Limits für Arbeitslasten gelten für alle Pods, einschließlich solcher, die von Deployments, DaemonSets, ReplicaSets, ReplicationControllers, StatefulSets, Jobs und CronJobs gestartet wurden.

Beschränkungen für Hostoptionen

HostPort und hostNetwork sind nicht zulässig, da die Knotenverwaltung von GKE verarbeitet wird. Die Verwendung von hostPath-Volumes im Schreibmodus ist verboten, während die Verwendung von hostPath-Volumes im Lesemodus nur für die path-Präfixe /var/log/ zulässig ist. Die Verwendung von Host-Namespaces in Arbeitslasten ist verboten.

Limits für Linux-Arbeitslasten

Autopilot unterstützt nur die folgenden Linux-Berechtigungen für Arbeitslasten:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"

Ab GKE-Version 1.21.3-gke.900 wird die Funktion "SYS_PTRACE" für Arbeitslasten unterstützt.

Knotenselektoren und Knotenaffinität

Zonale Affinitätstopologien werden unterstützt. Knotenaffinität und Knotenselektoren sind nur für die Verwendung mit den folgenden Schlüsseln beschränkt: topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, cloud.google.com/gke-os-distribution, kubernetes.io/os und kubernetes.io/arch. Nicht alle Werte vom Betriebssystem und von Arch werden in Autopilot unterstützt.

Keine Container Threat Detection

Autopilot unterstützt Container Threat Detection nicht.

Keine privilegierten Pods

Der privilegierte Modus für Container in Arbeitslasten wird hauptsächlich zum Ändern von Knoten verwendet, z. B. zum Ändern von Kubelet oder Netzwerkeinstellungen. Bei Autopilot-Clustern sind Knotenänderungen nicht zulässig, sodass diese Pod-Typen ebenfalls nicht zulässig sind. Diese Beschränkung kann sich auf einige Administratorarbeitslasten auswirken.

Pod-Affinität und Anti-Affinität

Obwohl GKE Ihre Knoten für Autopilot verwaltet, haben Sie weiterhin die Möglichkeit, Ihre Pods zu planen. Autopilot unterstützt Pod-Affinität, sodass Sie Pods für eine Netzwerkeffizienz gemeinsam auf einem einzelnen Knoten zusammenbringen können. Sie können die Pod-Affinität beispielsweise verwenden, um Front-End-Pods auf Knoten mit Back-End-Pods bereitzustellen. Die Pod-Affinität ist nur für die folgenden Schlüssel begrenzt: topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region und failure-domain.beta.kubernetes.io/zone.

Autopilot unterstützt auch Anti-Affinität, sodass Sie Pods auf Knoten verteilen können, um Single Points Of Failure zu vermeiden. Beispielsweise können Sie Pod-Anti-Affinität verwenden, um zu verhindern, dass Front-End-Pods zusammen mit Back-End-Pods lokalisiert werden.

Standard- und Ressourcenlimits bei Verwendung der Pod-Anti-Affinität

Autopilot unterstützt Pod-Anti-Affinität, sodass Sie verhindern können, dass sich zwei Pods auf demselben Knoten befinden. Wenn Sie Anti-Affinität verwenden, muss Autopilot zusätzliche Rechenressourcen zuweisen, um eine ordnungsgemäße Pod-trennung zu gewährleisten, wie in der PodSpec definiert. Bei Verwendung der Pod-Anti-Affinität erhöhen sich die Standard- und Mindestressourcenlimits. Für alle in der PodSpec aufgeführten Container:

Ressource	Standardwert
CPU	0.75 vCPU
Speicher	2 GiB
Sitzungsspezifischer Speicher	1 GiB

Bei Verwendung der Pod-Anti-Affinität gelten dieselben Regeln und Logiken für das Ressourcenlimit, jedoch mit höheren vCPU-Inkrementen. Pod-vCPU werden in mindestens 0,5 vCPU und Schritten von 0,5 vCPU angeboten (auf den nächsten Schritt aufgerundet). Wenn Sie beispielsweise insgesamt 0,66 vCPU anfragen (unter all Ihren Containern, die Anti-Affinität verwenden), wird Ihre PodSpec während der Zulassung geändert und auf 1 vCPU festgelegt. Ihr Pod hat vollen Zugriff auf die höhere Ressource, wobei die zusätzliche Ressource auf die Ressourcenanfragen aller Container verteilt ist.

Toleranzen werden nur für die Arbeitslasttrennung unterstützt

Toleranzen werden nur für die Trennung von Arbeitslasten unterstützt. Markierungen werden bei Bedarf automatisch durch die automatische Knotenbereitstellung hinzugefügt.

Ressourcenbereiche und Verhältnismanagement

Pod-vCPU-Schritte: Pod-vCPU sind in Schritten von 0,25 vCPU (aufgerundet) verfügbar. Wenn Sie beispielsweise insgesamt 0,66 vCPU anfragen (unter all Ihren Containern), wird Ihre PodSpec während der Zulassung geändert und auf 0,75 vCPU festgelegt. Ihr Pod hat vollen Zugriff auf die höhere Ressource, wobei die zusätzliche Ressource auf die Ressourcenanfragen aller Container verteilt ist. Der Mindestwert beträgt 250 MilliCPU (mCPU). DaemonSet-vCPUs werden in Schritten von 10 mCPU angeboten (aufgerundet auf den nächsten Schritt).
Verhältnis von Arbeitsspeicher zu CPU: Das Verhältnis von Arbeitsspeicher (in GiB) zu vCPU muss im Bereich 1 bis 6,5 vCPU liegen. Sie können beispielsweise einen Pod mit 1 vCPU und 1 GiB Arbeitsspeicher oder 1 vCPU und 6,5 GiB Arbeitsspeicher haben, jedoch nicht mit 1 vCPU und 7 GiB Arbeitsspeicher. GKE skaliert die Ressource, die zu niedrig ist, um die Ressourcenanfrage zu verarbeiten. Wenn Sie beispielsweise 1 vCPU- und 7 GiB-Speicher anfragen, wird Ihre PodSpec beim Zugriff auf 1,25 vCPU- und 7 GiB-Speicher geändert. Wenn Sie 1 vCPU und 800 MiB Speicher anfragen, wird Ihre PodSpec auf 1 vCPU und 1 GiB RAM geändert, wobei die zusätzliche Ressource auf die Container aufgeteilt wird.

Die Anforderungen an die Erhöhung und das Verhältnis von CPU und Speicher sowie die mögliche Vergrößerung von Ressourcenanfragen werden berechnet, nachdem die Standardeinstellungen auf Container mit fehlenden Ressourcenanfragen angewendet wurden.

Für Container ohne Ressourcenanfragen werden standardmäßig das Standardminimum von 500 mCPU und 1 GiB-Arbeitsspeicher verwendet. Wenn Sie bei CPU und Arbeitsspeicher in GKE eine Ressourcenanfrage nach oben skalieren (z. B. um die Mindestanforderung oder die Verhältnisanforderung zu erfüllen), wird die zusätzliche Ressource gleichmäßig zwischen Containern verteilt. Gerundete Werte werden proportional auf Container verteilt. Beispielsweise erhält ein Container mit doppelt so viel Speicher wie die anderen Container doppelt so viel zusätzlichen Speicher.

Flüchtiger Speicher: Der verfügbare Bereich liegt zwischen 10 MiB und 10 GiB. Dies wirkt sich auf die beschreibbare Ebene des Containers und emptyDir-Bereitstellungen.

Der flüchtige Speicherung ist eine Mindestanfrage pro Container erforderlich. Wenn also die flüchtigen Speicheranfragen für einen Container unter dem Minimum liegen, erhöht Autopilot die Anfrage auf das Minimum. Flüchtiger Speicher hat keine Mindestanfrage pro Pod. Ein flüchtiger Speicher hat eine maximale Anfrage pro Pod, die für alle Container kumulativ ist. Wenn der kumulative Wert größer als das Maximum ist, skaliert Autopilot die Anfrage auf das Maximum zurück und stellt gleichzeitig sicher, dass das Verhältnis der Anfragen zwischen Containern gleich bleibt.

Beispiele für Ressourcenlimits

Beispiel 1: Für einen einzelnen Container mit einem Minimum von < 250 mCPU:

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 180 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 250 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
Pod-Ressourcen insgesamt		CPU: 250 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB

Beispiel 2: Bei mehreren Containern mit einem gesamten Minimum von < 250 mCPU verteilt Autopilot den Rest der Ressourcen (bis zu 250 vCPU) gleichmäßig auf alle Container im Pod.

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 70 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 84 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
2	CPU: 70 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 83 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
3	CPU: 70 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 83 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
Pod-Ressourcen insgesamt		CPU: 250 mCPU Speicher: 1,5 GiB Flüchtiger Speicher: 30 MiB

Beispiel 3: Bei mehreren Containern mit Gesamtressourcen >= 250 mCPU wird die CPU auf ein Vielfaches von 250 mCPU gerundet, und die zusätzliche CPU wird im Verhältnis ihrer ursprünglichen Anfragen auf alle Container verteilt. In diesem Beispiel beträgt die ursprüngliche kumulative CPU 320 mCPU und wird insgesamt auf 500 mCPU geändert. Die zusätzlichen 180 mCPU sind auf die Container verteilt:

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 170 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 266 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
2	CPU: 80 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 125 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
3	CPU: 70 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB	CPU: 109 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 10 MiB
4	Init-Container, nicht definierte Ressourcen	Erhält Pod-Ressourcen
Pod-Ressourcen insgesamt		CPU: 500 mCPU Speicher: 0,5 GiB Flüchtiger Speicher: 30 MiB

Beispiel 4: Für einen einzelnen Container, bei dem die CPU für den Speicher zu niedrig ist (maximal 1 vCPU : 6,5 GiB). Das maximal zulässige Verhältnis von CPU zu Arbeitsspeicher beträgt 1:6,5. Wenn das Verhältnis höher ist, wird die CPU-Anfrage erhöht und gegebenenfalls aufgerundet:

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 250 mCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB	CPU: 750 mCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB
Pod-Ressourcen insgesamt		CPU: 750 mCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB

Beispiel 5: Für einen einzelnen Container, bei dem der Arbeitsspeicher für den Umfang der CPU zu niedrig ist (mindestens 1 vCPU : 1 GiB). Das minimal zulässige Verhältnis von CPU zu Arbeitsspeicher beträgt 1:1. Wenn das Verhältnis niedriger ist, wird die Speicheranfrage erhöht.

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 4 vCPU Speicher: 1 GiB Flüchtiger Speicher: 10 MiB	CPU: 4 vCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB
Pod-Ressourcen insgesamt		CPU: 4 mCPU Speicher: 4 GiB Flüchtiger Speicher: 10 MiB

Beispiel 6: Für einen einzelnen Container mit einem Minimum von < 250 mCPU, bei dem die CPU nach der Anpassung zu niedrig für die Speichermenge ist (maximal 1 vCPU : 6.5 GiB)

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 100 mCPU Speicher: 50 MiB Flüchtiger Speicher: 10 MiB	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 10 MiB
Pod-Ressourcen insgesamt		CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 10 MiB

Beispiel 7: Für einen einzelnen Container mit flüchtigen Speicheranfragen > 10 GiB beträgt die maximal zulässige flüchtige Speicheranfrage 10 GiB. Ist die Anfrage größer als der Maximalwert, wird die Anfrage auf 10 GiB herunterskaliert.

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 11 GiB	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 10 GiB
Pod-Ressourcen insgesamt		CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 10 GiB

Beispiel 8: Bei mehreren Containern mit flüchtigen Speicheranfagen > 10 GiB werden alle flüchtigen Speicheranfragen für Container verkleinert, um die endgültige kumulative Speicheranfrage von 10 GiB zu erhalten.

Containernummer	Ursprüngliche Ressourcenanfragen	Geänderte Anfragen
1	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 5 GiB	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 2,94 GiB
2	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 6 GiB	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 3,53 GiB
3	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 6 GiB	CPU: 250 mCPU Speicher: 256 MiB Flüchtiger Speicher: 3,53 GiB
Pod-Ressourcen insgesamt		CPU: 750 mCPU Speicher: 768 MiB Flüchtiger Speicher: 10 GiB

Sicherheitsbeschränkungen

Container-Isolation

Autopilot erzwingt eine strenge Konfiguration für Ihre Pods, die eine erweiterte Sicherheitsisolation ermöglicht und die Auswirkungen von Container-Escape-Sicherheitslücken auf Ihrem Cluster begrenzt:

Standardmäßig wird das seccomp-Profil der Containerlaufzeit auf alle Pods im Cluster angewendet.
Die Containerberechtigung CAP_NET_RAW wird für alle Container gelöscht. Die Berechtigung CAP_NET_RAW wird normalerweise nicht verwendet und war Gegenstand mehrerer Container-Escape-Sicherheitslücken. Das Fehlen von CAP_NET_RAW kann dazu führen, dass ping in Ihrem Container fehlschlägt.
Workload Identity wird erzwungen und verhindert, dass der Pod Zugriff auf das zugrunde liegende Compute Engine-Dienstkonto und andere vertrauliche Knotenmetadaten erhält.
Dienste mit dem Wert spec.ExternalIPs werden blockiert, um CVE-2020-8554 zu schützen. Diese Dienste werden selten verwendet.

Die folgenden StorageTypes sind zulässig. Andere StorageTypes werden blockiert, da sie Berechtigungen für den Knoten benötigen:

"configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "hostPath",
"nfs", "persistentVolumeClaim", "projected", "secret"

Pod-Sicherheitsrichtlinien

Autopilot erzwingt Einstellungen, die eine optimierte Isolation für Ihre Container ermöglichen. Die PodSecurityPolicy von Kubernetes wird auf Autopilot-Clustern nicht unterstützt. In GKE-Versionen vor 1.21.3-gke.900 werden OPA Gatekeeper und Policy Controller ebenfalls nicht unterstützt.

Sicherheitsgrenzen in Autopilot

Auf der Kubernetes-Ebene stellt der GKE Autopilot-Modus die Kubernetes API bereit, entfernt aber Berechtigungen für die Verwendung einiger besonders privilegierter Kubernetes-Primitive, z. B. privilegierte Pods, um den Zugriff auf diese Ressourcen zu beschränken oder zu ändern. Sie können die virtuelle Maschine (VM) des Knotens direkt steuern.

Der GKE-Autopilot-Modus wird eingerichtet, um Arbeitslasten daran zu hindern, Zugriff auf eine Knoten-VM zu gewähren, damit Google Cloud die vollständige Verwaltung von Knoten anbieten kann, und auf Pod-Ebene.SLA , um die Option zu aktivieren.

Wir möchten den unbeabsichtigten Zugriff auf die virtuelle Maschine des Knotens verhindern. Wir nehmen die Einreichung im Rahmen des Google Vulnerability Reward Program (VRP) in Betracht und werden nach eigenem Ermessen über den Google VRP-Prämienbereich belohnt.

Privilegierte Nutzer wie Clusteradministratoren haben die vollständige Kontrolle über jeden GKE-Cluster. Als Best Practice für Sicherheit sollten Sie die leistungsstarken GKE/Kubernetes-Berechtigungen vermeiden und stattdessen die Namespace-Administrator-Delegierung verwenden, wie in unserer Anleitung zur Mehrmandantenfähigkeit beschrieben.

Arbeitslasten auf Autopilot genießen weiterhin die gleiche Sicherheit wie der GKE-Standardmodus, in dem VMs für einzelne Mandanten für die ausschließliche Verwendung im Projekt des Nutzers bereitgestellt werden. Wie bei Standard können auch Autopilot-Arbeitslasten in einer Cluster auf einer VM mit einem Kernel ausgeführt werden, der von Sicherheit geschützt, aber gemeinsam genutzt wird.

Da der freigegebene Kernel eine einzelne Sicherheitsgrenze darstellt, empfiehlt GKE, dass Sie Ihre Arbeitslasten auf GKE-Standardclustern ausführen, wenn Sie eine starke Isolation benötigen, z. B. riskante oder nicht vertrauenswürdige Arbeitslasten,GKE Sandbox.

Sonstige Einschränkungen

Zertifikatsignierungsanfragen

Sie können in Autopilot-Zertifikatsignierungsanfragen nicht erstellen.

Externe Monitoring-Tools

Bei den meisten externen Monitoring-Tools ist der Zugriff eingeschränkt. Lösungen von mehreren Google Cloud-Partnern können auf Autopilot genutzt werden. Es werden jedoch nicht alle Lösungen unterstützt. Benutzerdefinierte Monitoring-Tools können auf Autopilot-Clustern nicht installiert werden.

Externe Dienstleistungen

Externe IP-Dienste sind auf Autopilot-Clustern nicht zulässig. Um einem Dienst eine externe IP zuzuweisen, können Sie einen den Load-Balancer-Typ Dienst oder einen Ingress verwenden, um den Dienst einer externen IP hinzuzufügen, die von mehreren Diensten gemeinsam genutzt wird.

Init-Container

Container werden nacheinander ausgeführt, bevor die Anwendungscontainer gestartet werden. Standardmäßig weist GKE jedem Init-Container die vollständigen Ressourcen zu, die dem Pod zur Verfügung stehen.

Im Gegensatz zu Ihren anderen Containern empfiehlt GKE, nicht mehr die Ressourcenanfragen für Init-Container zu übernehmen, damit die Container die vollständigen Ressourcen haben. Wenn Sie niedrigere Ressourcen festlegen, wird Ihr Init-Container unnötig eingeschränkt. Wenn Sie höhere Ressourcen festlegen, könnten sich die Rechnung für die Lebensdauer des Pods erhöhen.

Verwaltete Namespaces

Der Namespace kube-system wird verwaltet. Das bedeutet, dass alle Ressourcen in diesem Namespace nicht geändert und neue Ressourcen nicht erstellt werden können.

Keine Änderungen an Knoten

Da GKE die Knoten für Autopilot-Cluster verwaltet, können Sie die Knoten nicht ändern.

Keine Konvertierung

Die Konvertierung von Standardclustern in den Autopilot-Modus und die Konvertierung von Autopilot-Clustern in den Standardmodus wird nicht unterstützt.

Keine direkten externen eingehenden Verbindungen für private Cluster

Autopilot-Cluster mit privaten Knoten haben keine externen IP-Adressen und können keine direkten Verbindungen annehmen. Wenn Sie Dienste auf einem NodePort bereitstellen, können Sie nicht von außerhalb der VPC, z. B. aus dem Internet, darauf zugreifen. Verwenden Sie Dienste, um Anwendungen extern in Autopilot-Clustern verfügbar zu machen. Weitere Informationen finden Sie unter Anwendungen mit Diensten freigeben.

Kein Pod-Bursting

Bei Standardclustern können Pods so konfiguriert werden, dass auf dem Knoten ungenutzte Kapazität verwendet wird. Für Autopilot-Cluster ist das Ressourcen-Bursting nicht möglich, da alle Pods Limits für Anfragen festgelegt haben. Es ist wichtig, dass Ihre Pod-Spezifikation geeignete Ressourcen für die Ressourcenanfragen definiert und nicht von Bursting abhängt.

Keine Portweiterleitung

Autopilot-Cluster unterstützen den Befehl kubectl port-forward nicht.

Keine SSH-Verbindung

Da Sie die Knoten in Autopilot nicht mehr bereitstellen oder verwalten, gibt es keinen SSH-Zugriff. GKE verarbeitet alle operativen Aspekte der Knoten, einschließlich Knotenstatus und Kubernetes-Komponenten, die auf den Knoten ausgeführt werden.

Ressourcenlimits

In einem Autopilot-Cluster wird jeder Pod als Pod mit der Klasse "Guaranteed QoS" behandelt, dessen Limits den Anfragen entsprechen. Autopilot setzt Ressourcenlimits automatisch auf Anfragen, wenn keine Ressourcenlimits angegeben sind. Wenn Sie Ressourcenlimits angeben, werden Ihre Limits überschrieben und so festgelegt, dass sie den Anfragen entsprechen.

Webhook-Einschränkungen

In der GKE-Version 1.21.3-gke.900 und höher können Sie validierende und mutierende Webhooks für die dynamische Zulassung erstellen. Autopilot ändert jedoch die Webhook-Objekte der Zulassung, um eine Namespace-Auswahl hinzuzufügen, die die Ressourcen in verwalteten Namespaces (derzeit kube-system) vom Abfangen ausschließt. Darüber hinaus werden Webhooks, die eine oder mehrere der folgenden Ressourcen (und alle ihre Unterressourcen) in den Regeln angeben, abgelehnt:

- group: ""
  resource: nodes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Fehlerbehebung

Cluster kann nicht erstellt werden: 0 Knoten registriert

Wenn Sie einen Autopilot-Cluster erstellen, schlägt der Vorgang mit folgendem Fehler fehl:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Um das Problem zu beheben, darf das Standardkonto für den Compute Engine-Dienst nicht deaktiviert sein. Führen Sie den folgenden Befehl aus, um dies zu prüfen:

gcloud iam service-accounts describe SERVICE_ACCOUNT

Ersetzen Sie SERVICE_ACCOUNT durch die numerische Dienstkonto-ID oder E-Mail-Adresse des Dienstkontos (z. B. 123456789876543212345 oder my-iam-account@somedomain.com).