Autopilot-Übersicht

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite wird der Autopilot-Betriebsmodus in Google Kubernetes Engine (GKE) beschrieben. Außerdem erhalten Sie Ressourcen, mit denen Sie Ihre Cluster planen, einrichten und verwalten können.

Was ist Autopilot?

GKE Autopilot ist ein Betriebsmodus in GKE, in dem Google Ihre Clusterkonfiguration verwaltet, einschließlich Knoten, Skalierung, Sicherheit und anderer vorkonfigurierter Einstellungen. Autopilot-Cluster sind für die Ausführung der meisten Produktionsarbeitslasten optimiert und stellen Rechenressourcen basierend auf Ihren Kubernetes-Manifesten bereit. Die optimierte Konfiguration folgt den Best Practices und Empfehlungen von GKE für die Einrichtung von Clustern und Arbeitslasten, Skalierbarkeit und Sicherheit. Eine Liste der integrierten Einstellungen finden Sie in der Vergleichstabelle für Autopilot und Standard.

Preise

Sie zahlen nur für die CPU-, Arbeitsspeicher- und Speicherressourcen, die von Ihren Arbeitslasten bei der Ausführung in GKE Autopilot angefordert werden.

Nicht verwendete Kapazitäten auf Ihren Knoten werden Ihnen nicht in Rechnung gestellt, da GKE die Knoten verwaltet. Außerdem werden Ihnen keine System-Pods, Betriebssystemkosten oder ungeplanten Arbeitslasten in Rechnung gestellt. Ausführliche Preisinformationen finden Sie unter Autopilot-Preise.

Vorteile

  • Fokus auf die Anwendungen: Google verwaltet die Infrastruktur, sodass Sie sich auf das Erstellen und Bereitstellen Ihrer Anwendungen konzentrieren können.
  • Sicherheit: Cluster haben eine standardmäßig gehärtete Konfiguration, wobei viele Sicherheitseinstellungen standardmäßig aktiviert sind. GKE wendet Sicherheitspatches automatisch auf Ihre Knoten an, wenn verfügbar. Dabei werden alle konfigurierten Wartungspläne eingehalten.
  • Preise: Das Preismodell von Autopilot vereinfacht Abrechnungsprognosen und Attributionen, da es auf von Ihren Pods angeforderten Ressourcen basiert.
  • Knotenverwaltung: Google verwaltet Worker-Knoten. Sie müssen also keine neuen Knoten erstellen, um Ihre Arbeitslasten zu berücksichtigen oder automatische Upgrades und Reparaturen zu konfigurieren.
  • Skalierung: Wenn Ihre Arbeitslasten eine hohe Last aufweisen und Sie weitere Pods hinzufügen, um den Traffic zu verarbeiten, z. B. mit dem horizontalen Pod-Autoscaling von Kubernetes, stellt GKE automatisch neue Knoten für diese Pods bereit und erweitert die Ressourcen in Ihren vorhandenen Knoten nach Bedarf automatisch.
  • Planung: Autopilot verwaltet das Pod-Bin-Pack für Sie, sodass Sie sich nicht Gedanken darüber machen müssen, wie viele Pods auf jedem Knoten ausgeführt werden. Sie können die Pod-Platzierung mithilfe von Kubernetes-Mechanismen wie Affinität und Pod-Verteilungstopologie zusätzlich steuern.
  • Ressourcenverwaltung: Wenn Sie Arbeitslasten bereitstellen, ohne Ressourcenwerte wie CPU und Arbeitsspeicher festzulegen, legt Autopilot automatisch vorkonfigurierte Standardwerte fest und ändert Ihre Ressourcenanforderungen auf Arbeitslastebene.
  • Netzwerk: Autopilot aktiviert standardmäßig einige Netzwerksicherheitsfunktionen, z. B. dass der gesamte Pod-Netzwerktraffic durch Ihre Firewallregeln für Virtual Private Cloud geleitet wird, auch wenn der Traffic an andere Pods im Cluster geht.
  • Release-Verwaltung: Alle Autopilot-Cluster sind in einem GKE-Releasekanal registriert. Dadurch wird sichergestellt, dass Ihre Steuerungsebene und Ihre Knoten auf den neuesten qualifizierten Versionen in diesem Kanal ausgeführt werden.
  • Verwaltete Flexibilität: Wenn Ihre Arbeitslasten spezielle Hardware- oder Ressourcenanforderungen haben, wie z. B. hohe CPU- oder Speicheranforderungen, bietet Autopilot vorkonfigurierte Compute-Klassen, die für diese Arbeitslasten entwickelt wurden. Sie fordern die Compute-Klasse in Ihrer Bereitstellung an, anstatt neue Knoten manuell erstellen zu müssen, die von benutzerdefinierten Maschinentypen und Hardware unterstützt werden. Sie können auch GPUs auswählen, um Arbeitslasten wie Batch- oder KI/ML-Anwendungen zu beschleunigen.
  • Geringere betriebliche Komplexität: Autopilot reduziert den Aufwand für die Plattformverwaltung, da Sie die Knoten, die Skalierung und die Planung von Vorgängen nicht ständig überwachen müssen.

Autopilot umfasst ein SLA, das sowohl die Steuerungsebene als auch die von Ihren Pods verwendete Rechenkapazität abdeckt.

Skalierung

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

Mit Autopilot können Sie CPU-, Arbeitsspeicher- und sitzungsspezifische Speicherressourcen für Ihre Arbeitslasten anfordern. Die zulässigen Bereiche hängen davon ab, ob Sie Ihre Pods auf der Standardplattform für allgemeine Zwecke oder auf einer Computing-Klasse ausführen möchten. Informationen zu den standardmäßigen Anfragen für Containerressourcen und den zulässigen Ressourcenbereichen finden Sie unter Ressourcenanfragen in Autopilot.

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 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 kubernetes.io/hostname 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.

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.

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.

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 zu Knoten

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

Sie können mit den exec-Funktionen von Kubernetes weiterhin Remote-Verbindungen zu Ihren ausgeführten Containern herstellen, um Befehle zur Fehlerbehebung in Ihren Containern auszuführen. Dazu gehört auch die Verbindung zu einer interaktiven Shell, z. B. mit kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh..

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.

Keine Google Cloud Marketplace-Anwendungen

Sie können keine Anwendungen aus Cloud Marketplace in Autopilot-Clustern installieren.

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Autopilot-Clustern.

Nächste Schritte