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 Vergleichstabelle für Autopilot und Standard weiter 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.
Wenn Sie den Standardmodus anstelle von Autopilot verwenden möchten, finden Sie hier einige Gründe, warum:
- 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.
- Ihre Arbeitslasten sind sehr rechenintensiv. Autopilot-Cluster eignen sich ideal zum Ausführen der meisten Produktionsarbeitslasten. Standardcluster sind jedoch möglicherweise besser für rechenintensive Arbeitslasten geeignet, für die spezielle CPU-Plattformen oder Maschinentypen erforderlich sind.
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: |
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: |
Abrechnung | Für Pod-Ressourcenanfragen (CPU, Arbeitsspeicher und flüchtiger Speicher) bezahlen | Bezahlung pro Knoten (CPU, Arbeitsspeicher, Bootlaufwerk) |
Sicherheit | Vorkonfiguriert: Optional: |
Optional: |
Netzwerk | Vorkonfiguriert: Standardeinstellung:
|
Optional:
|
Upgrades, Reparatur und Wartung | Vorkonfiguriert: |
Optional: |
Anmeldedaten für die Authentifizierung | Vorkonfiguriert: Workload Identity | Optional:
|
Skalieren | Vorkonfiguriert: Autopilot verwaltet die gesamte Skalierung und Konfiguration Ihrer Knoten. Standardeinstellung:
|
Optional:
|
Logging | Vorkonfiguriert: System- und Arbeitslast-Logging | Standard:
System- und Arbeitslast-Logging
Optional: Nur System-Logging |
Monitoring | Vorkonfiguriert: System-Monitoring Optional: System- und Arbeitslast-Monitoring |
Standardeinstellung: System-Monitoring Optional: System- und Arbeitslast-Monitoring |
Cluster-Add-ons | Vorkonfiguriert: Standardeinstellung:
|
Optional: |
1Weitere 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
Für GKE-Versionen vor 1.21.4 werden die folgenden Instanztypen in Autopilot-Clustern nicht unterstützt:
Sicherheit
- Binärautorisierung
- Kubernetes Alpha APIs
- Alte Authentifizierungsoptionen
Speicher
Add-ons und Integrationen
- Calico Netzwerkrichtlinie
- Cloud Run
- Cloud TPU
- Config Connector
- Grafikprozessoren (GPUs)
- Kalm
- Nutzungsmessung
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 | |
---|---|---|---|
Normale Pods | DaemonSet-Pods | Normale Pods und DaemonSet-Pods | |
CPU | 250 mCPU | 10 mCPU | 28 vCPU2 |
Speicher | 512 MiB | 10 MiB | 80 GiB2 |
Sitzungsspezifischer Speicher | 10 MiB (pro Container) | 10 MiB (pro Container) | 10 GiB |
2Die 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.
Arbeitslasteinschränkungen in Autopilot
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 wird die Funktion "SYS_PTRACE"
auch 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.
Sie können Knotenselektoren und Knotenaffinität auch für folgende Zwecke verwenden:
- Konfigurieren Sie die Arbeitslasttrennung.
- Stellen Sie in Clustern mit der GKE-Version 1.21.4 und höher automatisch Spot-Pods bereit.
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 |
Sicherheitseinschränkungen bei Autopilot
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 BerechtigungCAP_NET_RAW
wird normalerweise nicht verwendet und war Gegenstand mehrerer Container-Escape-Sicherheitslücken. Das Fehlen vonCAP_NET_RAW
kann dazu führen, dassping
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 werden OPA Gatekeeper und Policy Controller 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.
Weitere Einschränkungen bei Autopilot
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
Init-Container werden nacheinander ausgeführt und müssen abgeschlossen sein, bevor die Anwendungscontainer gestartet werden. Wenn Sie keine Ressourcenanfragen für Ihre Autopilot-init-Container angeben, weist GKE jedem Init-Container die für den Pod verfügbaren Standardressourcen zu. Dieses Verhalten unterscheidet sich vom GKE-Standard, bei dem jeder Init-Container alle nicht zugewiesenen Ressourcen verwenden kann, die auf dem Knoten verfügbar sind, auf dem der Pod geplant ist.
Im Gegensatz zu Anwendungscontainern empfiehlt GKE, dass Sie keine Ressourcenanfragen für Autopilot-init-Container angeben, damit jeder Container die vollständigen Ressourcen erhält, die für den Pod verfügbar sind. Wenn Sie weniger Ressourcen als die Standardwerte anfordern, schränken Sie den init-Container ein. Wenn Sie mehr Ressourcen anfordern als die Autopilot-Standardeinstellungen, können Sie die Abrechnung 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
Sie können keine Änderungen an Autopilot-Knoten vornehmen, z. B. Änderungen am zugrunde liegenden Maschinentyp, wenn Ihre Arbeitslasten bestimmte Computing-Anforderungen haben.
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 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.
Logging des seriellen Ports
Für Autopilot-Cluster muss das Logging mit seriellem Port aktiviert sein, um Fehler in Ihren Knoten zu beheben und Fehler zu beheben. Wenn Ihre Google Cloud-Organisation eine Organisationsrichtlinie hat, die die Einschränkung compute.disableSerialPortLogging
erzwingt, werden neue Knoten möglicherweise nicht bereitgestellt.
Bitten Sie Ihren Administrator für Organisationsrichtlinien, diese Einschränkung in Projekten mit Autopilot-Clustern zu entfernen.
Webhook-Einschränkungen
In GKE Version 1.21 und höher können Sie auch mutierende dynamische Zulassungs-Webhooks erstellen. Autopilot ändert jedoch mutierende Webhook-Objekte so, dass eine Namespace-Auswahl hinzugefügt wird, die dafür sorgt, dass die Ressourcen in verwalteten Namespaces (z. B. kube-system
) nicht abgefangen werden. 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: ""
resource: persistentvolumes
- group: certificates.k8s.io
resource: certificatesigningrequests
- group: authentication.k8s.io
resource: tokenreviews
Sie können das Token *
, das für alle Werte steht, nicht im Feld resources
oder groups
verwenden, um die vorhergehenden Ressourcen zuzulassen.
Einschränkung der Identitätsübernahme von Nutzern
Die GKE-Version 1.22.4-gke.1501 und höher unterstützt die Identitätsübernahme von Nutzern für alle benutzerdefinierten Nutzer und Gruppen. Für Systemnutzer und Gruppen wie den kube-apiserver
-Nutzer und die system:masters
-Gruppe kann aber keine Identität übernommen werden.
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
).
Knoten können nicht vertikal skaliert werden
Nach dem Erstellen eines Autopilot-Clusters wird in den Logs die folgende Meldung angezeigt:
"napFailureReasons": [
{
"messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
...
Dieser Fehler bezieht sich auf ein noScaleUp
-Ereignis, bei dem die automatische Knotenbereitstellung keine Knotengruppe für den Pod in der Zone bereitgestellt hat, weil dies gegen Ressourcenlimits verstoßen würde.
Wenn dieser Fehler auftritt, prüfen Sie Folgendes:
- Ihr Cluster hat ausreichend Arbeitsspeicher und CPU.
- Der CIDR-Bereich der Pod-Adresse ist groß genug, um die erwartete maximale Clustergröße zu unterstützen.