Autopilot-Übersicht


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:
  • Öffentlicher Cluster
  • Standardmäßige CIDR-Bereiche

    Hinweis: Prüfen Sie Ihre CIDR-Bereiche, um das erwartete Clusterwachstum zu berücksichtigen.

  • Netzwerkname/Subnetz
Optional:
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:
  • Verwaltetes Anthos Service Mesh (Vorschau)
  • Istio (Verwaltetes Anthos Service Mesh verwenden (Vorschau))
  • 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

    Speicher

    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
    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:

    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 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 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:

    Nächste Schritte