Auswahlmöglichkeiten für Clusterkonfiguration

Auf dieser Seite werden die wichtigsten Clusterkonfigurationsoptionen erläutert, die Sie beim Erstellen eines Clusters in Google Kubernetes Engine (GKE) auswählen können, unabhängig davon, ob Sie dieGoogle Cloud Console, die Google Cloud CLI oder Terraform verwenden. Mit diesen Optionen können Sie eine Vielzahl von Clusterattributen und -verhalten an Ihre Anforderungen anpassen, z. B. ob der Cluster über öffentliche Netzwerke zugänglich ist oder wie er Versionsupgrades erhalten soll.

Viele der in diesem Leitfaden beschriebenen Optionen können nach dem Erstellen eines Clusters nicht mehr geändert werden. Dazu gehören Optionen, die sich auf die Verfügbarkeit und das Netzwerk eines Clusters auswirken. Wenn Sie diese Optionen ändern müssen, müssen Sie einen neuen Cluster erstellen und den Traffic dann dorthin migrieren. Dies kann zu Unterbrechungen führen.

Best Practice:

Da viele Clusterkonfigurationsoptionen nach dem Erstellen des Clusters nicht mehr geändert werden können, sollten Sie Ihre Clusterkonfiguration mit den Administratoren und Architekten, Cloud-Architekten, Netzwerkadministratoren oder einem anderen Team Ihrer Organisation planen und entwerfen, das für die Definition, Implementierung und Wartung der GKE- undGoogle Cloud -Architektur verantwortlich ist.

Diese Seite richtet sich an Administratoren und Architekten, die IT-Lösungen und Systemarchitekturen gemäß einer Unternehmensstrategie definieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Konzepten sowie den grundlegenden Kubernetes-Konzepten vertraut:

Ebene der Clusterverwaltung

Bevor Sie sich mit Clusteroptionen befassen, sollten Sie sich darüber im Klaren sein, wie viel Flexibilität, Verantwortung und Kontrolle Sie für Ihren Cluster benötigen. Das Maß an Kontrolle, das Sie benötigen, bestimmt den Betriebsmodus, den Sie in GKE verwenden, und die Clusterkonfigurationsoptionen, die Sie auswählen müssen.

Wenn Sie einen Cluster in GKE erstellen, verwenden Sie einen der folgenden Betriebsmodi:

  • Autopilot (empfohlen): Bietet eine vollständig bereitgestellte und verwaltete Clusterkonfiguration. Autopilot-Cluster sind mit einer optimierten Cluster-Konfiguration vorkonfiguriert, die für Produktionsarbeitslasten bereit ist.

  • Standard: Bietet erweiterte Konfigurationsflexibilität für die zugrunde liegende Infrastruktur des Clusters. Bei Clustern, die im Standardmodus erstellt wurden, bestimmen Sie die Konfiguration, die für Ihre Produktionsarbeitslasten erforderlich ist.

Weitere Informationen zu diesen Modi und zu Autopilot finden Sie unter GKE-Betriebsmodi und in der Autopilot-Übersicht.

Einen detaillierten Vergleich der beiden Modi finden Sie unter GKE Standard und Autopilot vergleichen.

Auswahlmöglichkeiten für Clusterkonfiguration

Nachdem Sie einen Betriebsmodus ausgewählt haben, wählen Sie die Konfiguration aus, die Sie für Ihren Cluster benötigen. Da Autopilot-Cluster von Google Cloud vollständiger verwaltet und konfiguriert werden als Standardcluster, stehen für sie weniger Konfigurationsoptionen zur Verfügung.

Die Konfigurationsoptionen für alle Cluster lassen sich in die folgenden Kategorien einteilen:

  • Name und andere Metadaten: Jeder Cluster muss einen Namen haben, der innerhalb des Projekts eindeutig ist. Optional können Sie auch eine Clusterbeschreibung und Labels hinzufügen.
  • Verfügbarkeit und Skalierbarkeit: Geben Sie an, wo die Steuerungsebene und die Knoten des Clusters ausgeführt werden sollen und ob Sie mehrere Replikate der Steuerungsebene wünschen. Alle Autopilot-Cluster sind regional, d. h., sie haben mehrere Steuerungsebenen in mehreren Compute-Zonen in einer Google Cloud-Region.
  • Flottenmitgliedschaft: Wählen Sie aus, ob Ihr Cluster Mitglied einer Flotte sein soll.
  • Netzwerk: Netzwerkoptionen, einschließlich des VPC-Netzwerks (Virtual Private Cloud) und des Subnetzes, in dem sich der Cluster befindet, und ob Ihr Cluster über öffentliche Netzwerke zugänglich sein soll.
  • Versions- und Upgrademanagement: Verwenden Sie Release-Versionen, um beim Upgrade der Software dieses Clusters das gewünschte Verhältnis zwischen neuen Funktionen und Stabilität auszuwählen. Legen Sie Wartungsfenster und -ausschlüsse fest, um zu bestimmen, wann Upgrades durchgeführt werden können und wann nicht.
  • Sicherheit: Dazu gehört, ob der Cluster die Workload Identity-Föderation für GKE verwendet, und das Dienstkonto, das von den Knoten des Clusters zur Authentifizierung beiGoogle Cloudverwendet wird.
  • Cluster-Features: Aktivieren und konfigurieren Sie zusätzliche GKE- undGoogle Cloud -Features für diesen Cluster, einschließlich Sicherungen und Beobachtbarkeit. Im Standardmodus können Sie auch kurzlebige Alpha-Cluster erstellen, um Alpha-Kubernetes-Features auszuprobieren.

Zusätzlich zu diesen Optionen gibt es bei Standardclustern auch Optionen in der folgenden Kategorie:

  • Knotenpools: Geben Sie Details zu den Knoten Ihres Clusters an, einschließlich Knotenpools, Knotenbetriebssystem und Knotengröße.

In den folgenden Abschnitten werden einige dieser Kategorien genauer betrachtet, insbesondere diejenigen mit Optionen, bei denen Sie die Einstellung nach dem Erstellen des Clusters nicht mehr ändern können. Eine vollständige Liste der Konfigurationsoptionen finden Sie in der Konfigurationsreferenz.

In der folgenden Tabelle werden die verfügbaren Optionen in einigen wichtigen Bereichen für Autopilot- und Standardcluster verglichen:

Clusterauswahl Modus
Autopilot Standard
Verfügbarkeitstyp Regional Regional oder Zonal
Release-Version Rapid, Regulär oder Stabil Beliebiger Kanal
Clusterversionen Standard oder eine andere verfügbare Version Standard oder eine andere verfügbare Version
Netzwerk-Routing VPC nativ VPC-nativ oder Routenbasiert
Netzwerkisolation Anpassbar Anpassbar
Kubernetes-Features Produktion Produktion oder Alpha

Clusterverfügbarkeit

Mit GKE können Sie einen Cluster erstellen, der auf die Verfügbarkeitsanforderungen Ihrer Arbeitslast und Ihres Budgets zugeschnitten ist. Sie können zwischen regionalen Clustern mit mehreren Replikaten der Steuerungsebene in mehreren Compute-Zonen in einer Google Cloud -Region oder zonalen Clustern mit einer einzelnen Steuerungsebene in einer einzelnen Zone wählen. Autopilot-Cluster sind immer regional.

Informationen zur Auswahl des Clustertyps im Standardmodus finden Sie unter Regionale oder zonale Steuerungsebene auswählen.

Diese Einstellungen können nach dem Erstellen des Clusters nicht mehr geändert werden: Ein zonaler Cluster kann nicht in einen regionalen Cluster umgewandelt werden und ein regionaler Cluster kann nicht in einen zonalen Cluster umgewandelt werden.

Best Practice:

Verwenden Sie für Produktionsarbeitslasten regionale Cluster, da sie im Allgemeinen eine höhere Verfügbarkeit als zonale Cluster bieten. Verwenden Sie für Entwicklungsumgebungen regionale Cluster mit zonalen Knotenpools. Ein Cluster mit einer regionalen Steuerungsebene und zonalen Knotenpools verursacht dieselben Kosten wie ein zonaler Cluster. Weitere Informationen zu regionsspezifischen Aspekten finden Sie unter Geografie und Regionen

Regionale Cluster

Ein regionaler Cluster verfügt über mehrere Replikate der Steuerungsebene, die in mehreren Zonen innerhalb der von Ihnen angegebenen Google Cloud Region ausgeführt werden. Sie müssen immer eine Region angeben, wenn Sie einen Autopilot- oder einen anderen regionalen Cluster erstellen.

Nur bei regionalen Standardclustern können Sie auch auswählen, in welchen Zonen die Knoten des Clusters ausgeführt werden. Knoten in einem regionalen Cluster können je nach den konfigurierten Knotenstandorten in mehreren Zonen oder in einer einzelnen Zone ausgeführt werden. Standardmäßig repliziert GKE jeden Knotenpool in drei Zonen der Region der Steuerungsebene. Wenn Sie einen regionalen Standardcluster erstellen oder einen neuen Knotenpool hinzufügen, können Sie die Standardkonfiguration ändern, indem Sie die Zonen angeben, in denen die Knoten des Clusters ausgeführt werden. Alle Zonen müssen sich in der Region der Steuerungsebene befinden.

Führen Sie Produktionsarbeitslasten mit regionalen Clustern aus, da sie eine höhere Verfügbarkeit als zonale Cluster bieten.

Sie können die Region eines regionalen Clusters nach dem Erstellen des Clusters nicht mehr ändern.

Zonale Cluster

Zonale Cluster haben eine einzige Steuerungsebene in einer einzelnen Zone. Arbeitslasten werden auch während eines Clusterupgrades oder eines Ausfalls der Zone, in der die Steuerungsebene ausgeführt wird, weiter ausgeführt. Der Cluster, seine Knoten und seine Arbeitslasten können jedoch erst konfiguriert werden, wenn die Steuerungsebene verfügbar ist. Je nach Verfügbarkeitsanforderungen Ihrer Arbeitslast können Sie die Knoten für den zonalen Cluster in einer einzigen Zone oder in mehreren Zonen verteilen.

Informationen zum Erstellen eines zonalen Clusters finden Sie unter Zonalen Cluster erstellen.

Standort und Verteilung der Knoten

Unabhängig davon, ob Sie regionale oder zonale Cluster verwenden, können Sie den Standort und die Verteilung Ihrer Knoten auf die Zonen genau bestimmen. Sie können die Standardzonen für alle zukünftigen Knotenpools konfigurieren und die spezifischen Zonen für Knoten in vorhandenen Knotenpools zuweisen oder ändern.

Einzelzonencluster

Ein Cluster mit einer Zone, der ein regionaler oder zonaler Cluster sein kann, führt Arbeitslasten auf Knoten aus, die sich in nur einer Zone befinden. Wenn in dieser Zone ein Ausfall auftritt, sind alle Arbeitslasten nicht mehr verfügbar.

Zonale Cluster werden standardmäßig als Cluster mit einer einzelnen Zone erstellt. Sie können diese Konfiguration jedoch in Cluster mit mehreren Zonen ändern.

Multizonale Cluster

Ein multizonaler Cluster, der ein regionaler oder zonaler Cluster sein kann, verbessert die Verfügbarkeit von Arbeitslasten, indem Knoten auf mehrere Zonen innerhalb einer einzelnen Region verteilt werden. So können Sie Arbeitslasten in mehreren Zonen einer Region ausführen. Wenn Sie eine Arbeitslast in mehreren Zonen ausführen und ein zonaler Ausfall auftritt, wird die Arbeitslast in dieser Zone unterbrochen, bleibt jedoch in anderen Zonen verfügbar.

Wenn Sie GKE-Knoten auf mehrere Zonen verteilen, können Gebühren für zonenübergreifenden ausgehenden Netzwerktraffic anfallen, wenn Knoten mit Peers in einer anderen Zone innerhalb der Region kommunizieren müssen.

Regionale Cluster werden standardmäßig als multizonale Cluster erstellt. Sie können diese Konfiguration jedoch in Cluster mit einer einzelnen Zone ändern.

KI-Zonen

KI-Zonen sind spezialisierte Zonen, die für KI-/ML-Trainings- und Inferenzarbeitslasten verwendet werden. Diese Zonen bieten eine erhebliche ML-Beschleunigerkapazität. Weitere Informationen finden Sie in der Dokumentation zu KI-Zonen.

In diesem Dokument und in der GKE-Dokumentation beziehen sich „Standardzonen“ oder „Zonen“ auf Nicht-KI-Zonen innerhalb einer Google Cloud -Region.

Bevor Sie eine KI-Zone in GKE verwenden, sollten Sie die folgenden Merkmale beachten:

  • Wenn Sie eine KI-Zone mit vorhandenen GKE-Clustern verwenden möchten, muss auf Ihrer Steuerungsebene die Version 1.36.4-gke.1495002 oder höher oder die Version 1.37.1-gke.1552000 oder höher ausgeführt werden. Mit diesen Versionen kann die Steuerungsebene die Zone erkennen und Knoten registrieren. Wenn Ihre Steuerungsebene Version 1.35 oder früher oder eine Version vor diesen Mindestversionen ausführt, aktualisieren Sie die Steuerungsebene, bevor Sie Knotenpools in der KI-Zone erstellen. Wenn ein Upgrade nicht möglich ist, wenden Sie sich an den Cloud Customer Care.
  • KI-Zonen sind physisch von Standardzonen getrennt, um zusätzlichen Speicherplatz und zusätzliche Leistung bereitzustellen. Diese Trennung kann zu einer höheren Latenz führen, die für KI-/ML-Arbeitslasten im Allgemeinen tolerierbar ist.
  • KI-Zonen haben ein Suffix mit der Notation ai. Eine KI-Zone in der Region us-central1 heißt beispielsweise us-central1-ai1a.
  • Derzeit werden nur TPU-VMs unterstützt.
  • Die Steuerungsebene des Clusters wird in einer oder mehreren Standardzonen in derselben Region wie die KI-Zone ausgeführt.

  • Sie können VMs ohne angehängte TPUs nur dann in einer KI-Zone ausführen, wenn Sie die folgenden Anforderungen erfüllen:

    • Sie führen bereits andere Arbeitslasten aus, die TPU-VMs in derselben Zone verwenden.
    • Die Nicht-TPU-VMs sind entweder Spot-VMs, an eine Reservierung gebunden oder Teil eines Knotenpools mit einem bestimmten Verhältnis von beschleunigungsoptimierten VMs zu VMs für allgemeine Zwecke.

  • KI-Zonen teilen sich Komponenten wie Netzwerkverbindungen und Software-Rollouts mit Standardzonen, die dasselbe Suffix in derselben Region haben. Für Arbeitslasten mit Hochverfügbarkeit empfehlen wir die Verwendung verschiedener Zonen. Vermeiden Sie beispielsweise, sowohl us-central1-ai1a als auch us-central1-a für Hochverfügbarkeit zu verwenden.

Standardmäßig stellt die GKE Ihre Arbeitslasten nicht in KI-Zonen bereit. Wenn Sie eine KI-Zone verwenden möchten, müssen Sie eine der folgenden Optionen konfigurieren:

  • (Empfohlen) ComputeClasses: Legen Sie die höchste Priorität fest, um On-Demand-TPUs in einer KI-Zone anzufordern. Mit ComputeClasses können Sie eine priorisierte Liste von Hardwarekonfigurationen für Ihre Arbeitslasten definieren. Ein Beispiel finden Sie unter Informationen zu ComputeClasses.
  • Automatische Knotenbereitstellung: Verwenden Sie in Ihrer Pod-Spezifikation einen nodeSelector oder nodeAffinity, um die automatische Knotenbereitstellung anzuweisen, einen Knotenpool in der KI-Zone zu erstellen. Wenn Ihre Arbeitslast nicht explizit auf eine KI-Zone ausgerichtet ist, werden bei der automatischen Knotenbereitstellung nur Standardzonen oder Zonen aus --autoprovisioning-locations berücksichtigt, wenn neue Knotenpools erstellt werden. Diese Konfiguration sorgt dafür, dass Arbeitslasten, die keine KI-/ML-Modelle ausführen, in Standardzonen verbleiben, sofern Sie nichts anderes konfigurieren. Ein Beispiel für ein Manifest, das eine nodeSelector verwendet, finden Sie unter Standardzonen für automatisch erstellte Knoten festlegen.
  • GKE Standard: Wenn Sie Ihre Knotenpools direkt verwalten, verwenden Sie beim Erstellen eines Knotenpools eine KI-Zone im Flag --node-locations. Ein Beispiel finden Sie unter TPU-Arbeitslasten in GKE Standard bereitstellen.

Flottenmitgliedschaft

Wenn Ihre Organisation mehrere Cluster verwendet, können Sie die Multi-Cluster-Verwaltung vereinfachen. Fügen Sie dafür die Cluster zu einer Flotte hinzu: eine logische Gruppierung von Kubernetes-Clustern. Durch das Erstellen einer Flotte können Sie die Verwaltung von einzelnen Clustern bis hin zu ganzen Clustergruppen optimieren und Flotten-fähige Funktionen wie Multi-Cluster-Ingress, Config Sync undPolicy Controller verwenden.

Sie können einer Flotte zwar jederzeit Cluster hinzufügen, wir empfehlen jedoch dringend, neue Cluster während der Clustererstellung bei einer Flotte zu registrieren. Dies liegt daran, dass diese „in der Flotte geborenen“ Cluster mit Ihren ausgewählten Standardeinstellungen auf Flottenebene für eine Reihe von Unternehmensfunktionen erstellt werden und empfohlene Logs und Messwerte bereits aktiviert sind. Weitere Informationen dazu finden Sie in den folgenden Anleitungen:

Diese Einstellung kann nach der Clustererstellung aktualisiert werden, um den Cluster zu registrieren oder die Registrierung aufzuheben. Wir empfehlen jedoch nicht, Cluster mit Live-Arbeitslasten von einer Flotte in eine andere zu verschieben.

Weitere Informationen zum Hinzufügen von Clustern zu Flotten finden Sie unter Flotten erstellen, um die Multi-Cluster-Verwaltung zu vereinfachen.

Netzwerkeinstellungen

Beim Erstellen eines GKE-Cluster können Sie eine Reihe von Netzwerkeinstellungen angeben, darunter das Netzwerk, in dem sich der Cluster befindet, den Netzwerkroutingmodus und ob Ihre Clusterknoten über öffentliche Netzwerke zugänglich sein sollen.

Wenn Sie kein Netzwerkadministrator sind, sollten Sie sich vor dem Erstellen eines produktionsreifen Clusters mit den Netzwerkspezialisten Ihrer Organisation beraten, da viele dieser Optionen nach der Clustererstellung nicht mehr geändert werden können. Wenn Sie Netzwerkadministrator sind, finden Sie unter Informationen zum GKE-Netzwerk weitere Informationen zum GKE-Netzwerk. Best Practices für Netzwerkoptionen finden Sie unter Best Practices für GKE-Netzwerke. In diesem Abschnitt wird nur ein Teil der möglichen Netzwerkoptionen beschrieben.

Netzwerk und Subnetz

Das VPC-Netzwerk, in dem sich ein Cluster befindet, bestimmt, mit welchen anderen Compute Engine-Ressourcen er kommunizieren kann. Standardmäßig werden GKE-Cluster im Standardnetzwerk Ihres Projekts erstellt. Sie können jedoch ein anderes Netzwerk auswählen, wenn Sie oder Ihr Administrator eines erstellt haben. Falls verfügbar, können Sie angeben, dass Ihr Cluster zu einem bestimmten VPC-Subnetz gehören soll. Andernfalls wird das Standardsubnetz verwendet. Optional können Sie auch angeben, dass Sie einen bestimmten IP-Adressbereich innerhalb dieses Subnetzes für Ihre Pods und Dienste verwenden möchten.

Diese Einstellungen können nach dem Erstellen des Clusters nicht mehr aktualisiert werden.

Auswahl der Netzwerkisolation

Sie können die Netzwerkisolation in Ihrem Cluster anpassen, indem Sie die folgenden beiden Aspekte berücksichtigen:

  • Zugriff auf die Steuerungsebene: Standardmäßig sind sowohl der interne als auch der externe Endpunkt der Steuerungsebene aktiviert und der DNS-basierte Endpunkt ist deaktiviert. Sie können zwischen diesen Optionen auswählen:

    • Deaktivieren Sie sowohl den externen als auch den internen Endpunkt und verwenden Sie nur den DNS-Endpunkt.
    • Deaktivieren Sie nur den externen Endpunkt, um den Zugriff auf externe Clients zu verhindern.
    • Aktivieren Sie autorisierte Netzwerke, um zu steuern, welche IP-Adressen die Endpunkte der Steuerungsebene erreichen.

  • Clusternetzwerkkonfiguration: Sie können private Knoten in Ihrem Cluster aktivieren, um Arbeitslasten vollständig von öffentlichen Netzwerken zu isolieren. Sie können private Knoten für ganze Cluster oder auf Knotenpool- (für Standard) oder Arbeitslastebene (für Autopilot) aktivieren. Wenn Sie private Knoten auf Knotenpool- oder Arbeitslastebene aktivieren, werden alle Knotenkonfigurationen auf Clusterebene überschrieben.

Diese Einstellungen können nach dem Erstellen des Clusters geändert werden.

Weitere Informationen zur Netzwerkisolation finden Sie unter Netzwerkisolation anpassen und Netzwerkisolation anpassen.

Best Practice:

Verwenden Sie Cloud NAT, um GKE-Pods Zugriff auf Ressourcen mit öffentlichen IP-Adressen zu gewähren. Cloud NAT verbessert den allgemeinen Sicherheitsstatus des Clusters, da Pods nicht direkt mit dem Internet verbunden sind, aber trotzdem auf Internetressourcen zugreifen können.

VPC-native und routenbasierte Cluster

In GKE lassen sich Cluster anhand der Methode unterscheiden, mit der sie Traffic von einem Pod zu einem anderen weiterleiten. Ein Cluster, in dem Pod-IP-Adressen nativ im VPC-Netzwerk routingfähig sind, ohne dass benutzerdefinierte statische Routen verwendet werden, wird als VPC-nativer Cluster bezeichnet. In IPv4- und Dual-Stack-Clustern verwendet GKE Alias-IP-Adressen. In Einzelstack-IPv6-Clustern weist GKE Adressen direkt aus dem Subnetzwerk ohne Alias-IP-Adressbereiche zu. Ein Cluster, der Google Cloud -Routen verwendet, wird dagegen als routenbasierter Cluster bezeichnet.

Standardmäßig verwenden alle neuen GKE-Cluster VPC-natives Routing. Dies ist die von uns empfohlene Option. Sie können diese Einstellung beim Erstellen des Clusters ändern, um einen routenbasierten Cluster nur im Standardmodus zu erstellen. Diese Einstellung kann nach dem Erstellen des Clusters nicht mehr aktualisiert werden.

Weitere Informationen zu VPC-nativen Clustern und ihren Vorteilen, einschließlich aller besonderen Anforderungen, finden Sie unter VPC-native Cluster.

Best Practice:

Verwenden Sie für Ihre Cluster den VPC-nativen Netzwerkmodus. Dies ist die Standardeinstellung für Autopilot-Cluster.

Versionen und Upgrades

Mit Release-Versionen wählt die GKE Softwareversionen für einen Cluster aus, die das von Ihnen gewählte Gleichgewicht zwischen Funktionsverfügbarkeit und Stabilität bieten. Wenn Sie einen Cluster erstellen, können Sie die gewünschte Release-Version auswählen. Neue Cluster (sowohl Autopilot- als auch Standardcluster) werden standardmäßig in der Release-Version „Regular“ registriert. Sie können jedoch bei Bedarf während der Clustererstellung eine bestimmte Version auswählen.

Autopilot-Cluster verwenden immer Release-Versionen. Für Standardcluster werden standardmäßig Release-Versionen verwendet. Sie können jedoch auch wählen, Ihren Cluster nicht in einer Release-Version zu registrieren. Wir empfehlen dies jedoch nicht, da Sie mit dieser Einstellung nur eingeschränkten Zugriff auf Clusterfunktionen haben.

GKE führt im Laufe der Zeit für alle Cluster automatisch Upgrades durch, unabhängig von der Release-Version-Registrierung. Die GKE aktualisiert die Steuerungsebene des Clusters und seine Knoten automatisch, wenn neue Versionen in dieser Release-Version verfügbar sind. Sie können Timing und Umfang von Upgrades mit Wartungsfenstern und -ausschlüssen steuern.

Sie können die Release-Version eines Clusters jederzeit ändern.

Informationen zu anstehenden automatischen Upgrades finden Sie in den GKE-Versionshinweisen.

Best Practice:

Wählen Sie einen Release-Version für GKE aus, um Versionen für Ihren Cluster mit dem von Ihnen gewünschten Verhältnis zwischen Featureverfügbarkeit und Stabilität auszuwählen. Mit Wartungsfenstern und ‑ausschlüssen können Sie Timing und Umfang der automatischen Upgrades steuern.

Alpha-Funktionen (nur Standardcluster)

Neue Funktionen in Kubernetes werden abhängig von ihrem Entwicklungsstatus als Alpha, Beta oder Stabil bezeichnet. In den meisten Fällen sind Kubernetes-Features, die als Beta oder stabil aufgeführt sind, in GKE-Clustern enthalten.

Wenn Sie mit sehr neuen Funktionen experimentieren möchten, die noch nicht produktionsreif sind, können Sie Alphafunktionen in speziellen GKE-Alphaclustern verwenden. In einem Alphacluster sind alle Kubernetes Alpha APIs (manchmal auch als Feature-Gates bezeichnet) aktiviert. Sie können Alphacluster für das frühe Testen und Validieren von Kubernetes-Funktionen verwenden. Alpha-Cluster werden für Produktionsarbeitslasten nicht unterstützt, können nicht aktualisiert oder zu Release-Versionen hinzugefügt werden und laufen innerhalb von 30 Tagen ab.

Alphafunktionen sind für Autopilot-Cluster nicht verfügbar.

Informationen zum Erstellen eines Alpha-Clusters finden Sie unter Alpha-Cluster erstellen.

Sicherheitseinstellungen

GKE bietet eine Reihe von Sicherheitseinstellungen, die Sie beim Erstellen des Clusters festlegen können. Dazu gehören Verschlüsselungseinstellungen, Sicherheitsfunktionen wie die Binärautorisierung, das Dienstkonto, das Sie für die Knoten des Clusters verwenden möchten (wird im nächsten Abschnitt ausführlicher erläutert), und ob Ihr Cluster die Workload Identity Federation for GKE verwendet.

Wie bei anderen Einstellungen sollten Sie sich vor dem Erstellen eines produktionsreifen Clusters mit fachkundigen Kollegen beraten, in diesem Fall mit den Sicherheitsspezialisten Ihrer Organisation. Weitere Informationen zur GKE-Sicherheit finden Sie in unserer Sicherheitsübersicht und unter Sicherheit von Clustern erhöhen.

Dienstkonto für Knoten

Die GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knotendienstkonten müssen mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) für Ihr Projekt haben. Standardmäßig verwendet die GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.

Wenn Ihre Organisation die Einschränkung der Organisationsrichtlinie iam.automaticIamGrantsForDefaultServiceAccounts erzwingt, erhält das Compute Engine-Standarddienstkonto in Ihrem Projekt möglicherweise nicht automatisch die erforderlichen Berechtigungen für GKE.

Wenn Sie das Compute Engine-Standarddienstkonto für andere Funktionen in Ihrem Projekt oder Ihrer Organisation verwenden, hat das Dienstkonto möglicherweise mehr Berechtigungen, als GKE benötigt. Dies kann zu Sicherheitsrisiken führen.

Sie können das Dienstkonto für Cluster im Autopilot-Modus oder für Knotenpools im Standardmodus nach dem Erstellen nicht mehr ändern.

Knotenpool-Einstellungen (nur Standardcluster)

Wie Sie aus der Übersicht über die Clusterverwaltung und den GKE-Betriebsmodi wissen, müssen Sie sich bei der Verwendung von Autopilot für Ihre Cluster keine Gedanken über die Knotenkonfiguration machen, da GKE Ihre Knoten für Sie konfiguriert. Autopilot-Clusterknoten werden alle vollständig von GKE verwaltet und verwenden alle dasselbe Knotenbetriebssystem.

Wenn Sie einen Standardcluster erstellen, können Sie beim Erstellen des Clusters eine Reihe von Knotenoptionen angeben, darunter:

  • Name, Anzahl, Größe und Standort der Knotenpools, die Sie verwenden möchten. Knotenpools sind Gruppen von Knoten innerhalb des Clusters, die eine gemeinsame Konfiguration verwenden.
  • Das Knotenbetriebssystem, das Sie für neue Knoten verwenden möchten.
  • Ob Sie sitzungsspezifische Spot-VMs für Knoten verwenden möchten.
  • Der Compute Engine-Maschinentyp, den Sie für Knoten verwenden möchten.
  • Das Dienstkonto, das Sie für Knoten verwenden möchten, wie unter Sicherheitseinstellungen beschrieben.

Einige der Knotenpooleinstellungen eines Clusters können nach der Clustererstellung geändert werden. Alle Standardcluster erfordern jedoch mindestens einen Knotenpool. Wenn Sie beim Erstellen eines Standardclusters keine Anzahl von Knoten und keinen Maschinentyp angeben, besteht der Standardknotenpool aus drei Knoten in jeder Zone des Clusters mit dem Standard-Knoten-Image cos_containerd und einem Maschinentyp für allgemeine Zwecke.

Weitere Informationen zur Konfiguration von Knotenpools finden Sie unter Knotenpools und Knotenpools hinzufügen und verwalten.

Konfigurationsreferenz

Eine vollständige Liste der möglichen Konfigurationsoptionen finden Sie in den folgenden Referenzhandbüchern:

Nächste Schritte