Auswahlmöglichkeiten für Clusterkonfiguration


Auf dieser Seite werden die wichtigsten Optionen für die Clusterkonfiguration erläutert, die Sie beim Erstellen eines Clusters in der Google Kubernetes Engine (GKE) treffen können. Dabei spielt es keine Rolle, ob Sie die Google Cloud Console, die Google Cloud CLI oder Terraform verwenden. Mit diesen Optionen können Sie eine Vielzahl von Clusterattributen und ‑verhalten anpassen, um sie an Ihre Anforderungen anzupassen. Dazu gehört beispielsweise, ob der Cluster über öffentliche Netzwerke zugänglich ist und wie Versionsupdates empfangen werden sollen.

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. Das 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 gemeinsam 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 unseren Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und ‑Aufgaben. Google Cloud

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

Ebene der Clusterverwaltung

Bevor wir über Clusteroptionen sprechen, müssen Sie wissen, 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, der in GKE verwendet werden muss, und die Clusterkonfigurationen, die Sie vornehmen müssen.

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

  • Autopilot (empfohlen): Stellt eine vollständig bereitgestellte und verwaltete Clusterkonfiguration bereit. 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, legen Sie die Konfiguration fest, die für Ihre Produktionsarbeitslasten erforderlich ist.

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

Einen detaillierten direkten 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, sind für sie weniger Konfigurationsoptionen verfügbar.

Die Konfigurationsoptionen für alle Cluster fallen in die folgenden Kategorien:

  • Name und andere Metadaten: Jeder Cluster muss einen eindeutigen Namen innerhalb seines Projekts haben. Optional können Sie auch eine Clusterbeschreibung und Labels hinzufügen.
  • Verfügbarkeit und Skalierbarkeit: Geben Sie an, wo die Steuerungsebene und die Knoten Ihres Clusters ausgeführt werden sollen und ob Sie mehrere Steuerungsebenen-Replikate benötigen. Alle Autopilot-Cluster sind regional, d. h., sie haben mehrere Steuerungsebenen in mehreren Computing-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, sowie ob der Cluster über öffentliche Netzwerke zugänglich sein soll.
  • Versionen und Upgrade-Verwaltung: Mit Release-Kanälen können Sie beim Upgrade der Software dieses Clusters das gewünschte Gleichgewicht zwischen neuen Funktionen und Stabilität auswählen. Außerdem können Sie Wartungsfenster und -ausschlüsse festlegen, um zu bestimmen, wann Upgrades stattfinden können und wann nicht.
  • Sicherheit: Dazu gehört, ob der Cluster die Workload Identity-Föderation für GKE verwendet und welches Dienstkonto von den Knoten des Clusters zur Authentifizierung beiGoogle Cloudverwendet wird.
  • Clusterfunktionen: Hier können Sie zusätzliche GKE- undGoogle Cloud -Funktionen für diesen Cluster aktivieren und konfigurieren, einschließlich Sicherungen und Beobachtbarkeit. Im Standardmodus können Sie auch kurzlebige Alphacluster erstellen, um Alpha-Kubernetes-Funktionen zu testen.

Zusätzlich gibt es für Standardcluster 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 beschrieben, insbesondere diejenigen mit Optionen, deren Einstellung nach dem Erstellen des Clusters nicht mehr geändert werden kann. Eine vollständige Liste der Konfigurationsoptionen finden Sie in der Referenz zur Konfiguration.

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

Typ der 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 Steuerungsebenenreplikaten in mehreren Computing-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 aktualisiert 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 hat dieselben Kosten wie ein zonaler Cluster. Weitere Informationen zu regionsspezifischen Aspekten finden Sie unter Geografie und Regionen.

Regionale Cluster

Ein regionaler Cluster hat mehrere Replikate der Steuerungsebene, die in mehreren Zonen innerhalb der angegebenen Google Cloud Region ausgeführt werden. Sie müssen immer eine Region angeben, wenn Sie einen Autopilot- oder 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 konfigurierten Knotenstandorten in mehreren Zonen oder einer einzelnen Zone ausgeführt werden. Standardmäßig repliziert GKE jeden Knotenpool in drei Zonen der Region der Steuerungsebene. Wenn Sie einen Standardcluster erstellen oder einen neuen Knotenpool hinzufügen, können Sie die Standardkonfiguration ändern und selbst Zonen festlegen, in denen die Knoten des Clusters ausgeführt werden sollen. 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 der Clustererstellung nicht mehr ändern.

Zonale Cluster (nur Standardcluster)

Zonale Cluster haben eine einzige Steuerungsebene in einer einzelnen Zone. 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.

Einzelzonencluster

Ein Einzelzonencluster hat eine einzige Steuerungsebene, die in einer einzigen Zone ausgeführt wird. Diese Steuerungsebene verwaltet Arbeitslasten auf Knoten, die in derselben Zone ausgeführt werden. Wenn Sie eine Arbeitslast in einer einzelnen Zone ausführen, ist diese Arbeitslast bei einem Zonenausfall nicht verfügbar.

Multizonale Cluster

Ein multizonaler Cluster hat ein einzelnes Replikat der Steuerungsebene, das in einer einzelnen Zone ausgeführt wird, und Knoten, die in mehreren Zonen ausgeführt werden. Während eines Upgrades des Clusters oder wenn die Zone ausfällt, in der die Steuerungsebene ausgeführt wird, werden weiterhin Arbeitslasten ausgeführt. Der Cluster, seine Knoten und seine Arbeitslasten können jedoch erst konfiguriert werden, wenn die Steuerungsebene verfügbar ist. Multizonale Cluster gleichen Verfügbarkeit und Kosten für konsistente Arbeitslasten aus. Wenn Sie die Verfügbarkeit beibehalten möchten und sich die Anzahl Ihrer Knoten und Knotenpools häufig ändert, sollten Sie einen regionalen Cluster verwenden. 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.

Clusterstufe

Wie Sie von den GKE-Versionen wissen, gibt es in GKE zwei Funktionsstufen: eine Standardstufe mit Funktionen, die allen GKE-Nutzern zur Verfügung stehen, und eine Enterprise-Stufe mit leistungsstarken Funktionen für die Arbeit im Unternehmensmaßstab, von denen viele auf der GKE-Flottenverwaltung basieren.

Bei GKE-Clustern auf Google Cloudkönnen Sie pro Cluster auswählen, ob Sie die zusätzliche Funktionsebene hinzufügen möchten. Sobald ein Cluster für die GKE Enterprise-Stufe registriert ist, können Sie alle verfügbaren Enterprise-Funktionen damit verwenden. Wenn Sie keine Clusterebene angeben, wird standardmäßig die Standardebene verwendet, mit einigen Ausnahmen.

Beachten Sie bei der Auswahl der Clusterebene Folgendes:

  • Viele GKE Enterprise-Funktionen erfordern eine Flottenmitgliedschaft, um zu funktionieren. Sie können einen Cluster bei einer Flotte registrieren, während Sie ihn erstellen, oder nachdem Sie ihn erstellt haben. Wenn Sie flottenfähige GKE Enterprise-Funktionen mit einem Cluster verwenden möchten, empfehlen wir, den Cluster bei der Erstellung bei einer Flotte zu registrieren. Dadurch übernimmt der Cluster die Einstellungen für Enterprise-Funktionen auf Flottenebene. Weitere Informationen finden Sie unter Fleet-Mitgliedschaft.
  • Sie können die Enterprise-Stufe für einen Cluster nur aktivieren, wenn die GKE Enterprise API (Anthos) im Projekt des Clusters aktiviert ist.

Diese Einstellung kann nach dem Erstellen des Clusters geändert werden.

Weitere Informationen zu den in GKE Enterprise enthaltenen Funktionen, einschließlich der Funktionen, für die keine Flottenmitgliedschaft erforderlich ist, finden Sie unter GKE Enterprise-Bereitstellungsoptionen.

Mitgliedschaft in der Google Unternehmensgruppe

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

Sie können einer Flotte zwar jederzeit Cluster hinzufügen, wenn Sie jedoch GKE Enterprise aktiviert haben, empfehlen wir Ihnen dringend, neue Cluster der Enterprise-Ebene bei 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 finden Sie in den folgenden Anleitungen:

Diese Einstellung kann nach der Clustererstellung aktualisiert werden, um den Cluster zu registrieren oder abzumelden. Wir empfehlen jedoch nicht, Cluster mit aktiven 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-Clusters können Sie eine Reihe von Netzwerkeinstellungen angeben, darunter das Netzwerk, in dem sich der Cluster befindet, den Routingmodus für das Netzwerk und ob auf Ihre Clusterknoten von öffentlichen Netzwerken aus zugegriffen werden kann.

Wenn Sie kein Netzwerkadministrator sind, sollten Sie sich an die Netzwerkspezialisten Ihrer Organisation wenden, bevor Sie einen einsatzbereiten Cluster erstellen, da viele dieser Optionen nach der Clustererstellung nicht mehr geändert werden können. Wenn Sie Netzwerkadministrator sind, finden Sie unter GKE-Netzwerk weitere Informationen zu GKE-Netzwerken. Best Practices für Netzwerkoptionen finden Sie unter Best Practices für GKE-Netzwerke. In diesem Abschnitt werden nur einige der möglichen Netzwerkoptionen beschrieben.

Netzwerk und Subnetz

Mit welchen anderen Compute Engine-Ressourcen ein Cluster kommunizieren kann, hängt davon ab, in welchem VPC-Netzwerk (Virtual Private Cloud) er sich befindet. Standardmäßig werden GKE-Cluster im Standardnetzwerk Ihres Projekts erstellt. Sie können jedoch ein anderes Netzwerk auswählen, falls 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 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 anhand der folgenden beiden Aspekte anpassen:

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

    • Deaktivieren Sie sowohl den externen als auch den internen Endpunkt und verwenden Sie nur den DNS-Endpunkt.
    • Deaktivieren Sie den externen Endpunkt nur, um den Zugriff auf externe Clients zu verhindern.
    • Autorisierte Netzwerke aktivieren, 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 Ebene des Knotenpools (für Standard) oder der Arbeitslast (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 die allgemeine Sicherheitslage 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, der Alias-IP-Adressen verwendet, wird als VPC-nativer Cluster bezeichnet. Ein Cluster, der Google Cloud -Routen verwendet, wird als routenbasierter Cluster bezeichnet.

Standardmäßig verwenden alle neuen GKE-Cluster das VPC-native Routing, was wir empfehlen. 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 speziellen 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 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 Standard-Cluster) werden standardmäßig in der Release-Version „Regular“ registriert. Sie können jedoch bei 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 Registrierung für die Release-Version. GKE aktualisiert die Steuerungsebene und die Knoten des Clusters automatisch, sobald neue Versionen in diesem Release-Kanal verfügbar sind. Sie können den Zeitpunkt und den Umfang von Upgrades mit Wartungsfenstern und -ausschlüssen steuern.

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

Informationen zu bevorstehenden 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-Funktionen, 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, sind Alphafunktionen in speziellen GKE-Alphaclustern verfügbar. 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. Alphacluster werden für Produktionsarbeitslasten nicht unterstützt, können nicht geupgradet oder Release-Kanälen hinzugefügt werden und laufen innerhalb von 30 Tagen ab.

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

Informationen zum Erstellen eines Alphaclusters finden Sie unter Alphacluster erstellen.

Sicherheitseinstellungen

GKE bietet eine Reihe von Sicherheitseinstellungen, die Sie beim Erstellen eines Clusters angeben können. Dazu gehören Verschlüsselungseinstellungen, Sicherheitsfunktionen wie die Binary Authorization, das Dienstkonto, das Sie für die Knoten des Clusters verwenden möchten (wird im nächsten Abschnitt ausführlicher behandelt), und ob in Ihrem Cluster die Identitätsföderation von Arbeitslasten für GKE verwendet wird.

Wie bei anderen Einstellungen sollten Sie sich vor dem Erstellen eines produktionsfertigen Clusters mit Experten beraten – in diesem Fall mit den Sicherheitsspezialisten Ihres Unternehmens. Weitere Informationen zur GKE-Sicherheit finden Sie in der Sicherheitsübersicht und unter Sicherheit Ihres Clusters erhöhen.

Dienstkonto für Knoten

GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knotendienstkonten müssen in Ihrem Projekt mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) haben. Standardmäßig verwendet 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 Standard-Compute Engine-Dienstkonto 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 für GKE erforderlich. Dies kann zu Sicherheitsrisiken führen.

Das Dienstkonto für Cluster im Autopilot-Modus oder für Knotenpools im Standardmodus kann nach der Erstellung nicht mehr geändert werden.

Knotenpooleinstellungen (nur Standardcluster)

Wie Sie aus der Übersicht zur Clusterverwaltung und den GKE-Betriebsmodi wissen, müssen Sie sich keine Gedanken über die Knotenkonfiguration machen, wenn Sie Autopilot für Ihre Cluster verwenden, da GKE Ihre Knoten für Sie konfiguriert. Autopilot-Clusterknoten werden alle vollständig von GKE verwaltet und verwenden 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 Speicherort der Knotenpools, die Sie verwenden möchten. Knotenpools sind Gruppen von Knoten innerhalb Ihres 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. Für alle Standardcluster ist jedoch mindestens ein Knotenpool erforderlich. 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 standardmäßigen Knotenimage cos_containerd und einem allgemeinen Maschinentyp.

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