GKE-Pods in bestimmten Zonen platzieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Google Kubernetes Engine (GKE) anweisen, Ihre Pods mithilfe der zonalen Topologie auf Knoten in bestimmten Google Cloud -Zonen auszuführen. Diese Art von Placement ist in folgenden Situationen nützlich:

• Pods müssen auf Daten zugreifen, die auf einem zonalen nichtflüchtigen Compute Engine-Speicher gespeichert sind.
• Pods müssen zusammen mit anderen zonalen Ressourcen wie Cloud SQL-Instanzen ausgeführt werden.

Sie können die zonale Platzierung auch mit topologiebezogenem Traffic-Routing verwenden, um die Latenz zwischen Clients und Arbeitslasten zu reduzieren. Weitere Informationen zum topologiebezogenen Traffic-Routing finden Sie unter Topologie-fähiges Routing.

Die Verwendung der zonalen Topologie zur Steuerung der Pod-Platzierung ist ein erweiterter Kubernetes-Mechanismus, den Sie nur verwenden sollten, wenn Ihre Pods in bestimmten Zonen ausgeführt werden müssen. In den meisten Produktionsumgebungen empfehlen wir, nach Möglichkeit regionale Ressourcen zu verwenden. Dies ist die Standardeinstellung in GKE.

Zonale Platzierungsmethoden

Die zonale Topologie ist in Kubernetes mit dem Knotenlabel topology.kubernetes.io/zone: ZONE implementiert. Sie können GKE mit einer der folgenden Methoden anweisen, einen Pod in einer bestimmten Zone zu platzieren:

• nodeAffinity: Geben Sie in Ihrer Pod-Spezifikation eine nodeAffinity-Regel für eine oder mehrere Google Cloud -Zonen an. Diese Methode ist flexibler als ein nodeSelector, weil Sie damit Pods in mehreren Zonen platzieren können.

• nodeSelector: Geben Sie einen nodeSelector in Ihrer Pod-Spezifikation für eine einzelne Google Cloud -Zone an.

• Compute-Klassen: Konfigurieren Sie Ihren Pod für die Verwendung einer GKE-Compute-Klasse. Mit diesem Ansatz können Sie eine priorisierte Liste von Gruppen von Google Cloud -Zonen definieren. So kann die Arbeitslast dynamisch in die bevorzugten Zonen verschoben werden, wenn Knoten in diesen Zonen verfügbar sind. Weitere Informationen finden Sie unter Benutzerdefinierte Compute-Klassen.

Hinweise

Bei der zonalen Pod-Platzierung mit zonaler Topologie gilt Folgendes:

• Der Cluster muss sich in derselben Google Cloud -Region wie die angeforderten Zonen befinden.
• In Standardclustern müssen Sie die automatische Knotenbereitstellung verwenden oder Knotenpools mit Knoten in den angeforderten Zonen erstellen. Autopilot-Cluster verwalten diesen Prozess automatisch für Sie.
• Standardcluster müssen regionale Cluster sein.

Preise

Zonale Topologie ist eine Kubernetes-Planungsfunktion, die ohne zusätzliche Kosten in GKE angeboten wird.

Preisdetails finden Sie unter GKE-Preise.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

• Sie benötigen einen GKE-Cluster in derselbenGoogle Cloud -Region wie die Zonen, in denen Sie Ihre Pods platzieren möchten. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Pods mithilfe von nodeAffinity in mehreren Zonen platzieren

Die Knotenaffinität von Kubernetes bietet einen flexiblen Mechanismus zur Planung der Planung, der mehrere Labelselektoren und logische Operatoren unterstützt. Verwenden Sie nodeAffinity, wenn Sie Pods in einer von mehreren Zonen ausführen möchten (z. B. in us-central1-a oder us-central1-f).

1. Speichern Sie das folgende Manifest als multi-zone-affinity.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-multi-zone
     template:
       metadata:
         labels:
           app: nginx-multi-zone
       spec:
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: topology.kubernetes.io/zone
                   operator: In
                   values:
                   - us-central1-a
                   - us-central1-f
   

   Dieses Manifest erstellt ein Deployment mit drei Replikaten und platziert die Pods je nach Knotenverfügbarkeit in us-central1-a oder us-central1-f.

   Achten Sie darauf, dass sich Ihr Cluster in der Region us-central1 befindet. Wenn sich Ihr Cluster in einer anderen Region befindet, ändern Sie die Zonen im Feld „Werte“ des Manifests in gültige Zonen in Ihrer Clusterregion.

   Optional: Wenn Sie TPU-VMs bereitstellen, verwenden Sie eine KI-Zone wie us-central1-ai1a. KI-Zonen sind spezielle Standorte, die für KI-/ML-Arbeitslasten in Google Cloud -Regionen optimiert sind.

2. Erstellen Sie das Deployment:

   kubectl create -f multi-zone-affinity.yaml
   

   GKE erstellt die Pods in Knoten in einer der angegebenen Zonen. Es können mehrere Pods auf demselben Knoten ausgeführt werden. Optional können Sie die Pod-Anti-Affinität verwenden, um GKE anzuweisen, jeden Pod auf einem separaten Knoten zu platzieren.

Pods mit einem nodeSelector in einer einzelnen Zone platzieren

Wenn Sie Pods in einer einzelnen Zone platzieren möchten, verwenden Sie einen nodeSelector in der Pod-Spezifikation. Ein nodeSelector entspricht einer nodeAffinity-Regel requiredDuringSchedulingIgnoredDuringExecution, in der eine einzelne Zone angegeben ist.

Achtung: Pods, die Sie mithilfe einer zonalen Topologie in einer einzelnen Zone platzieren, fallen möglicherweise nicht unter das Service Level Agreement (SLA) für Autopilot, das Autopilot-Pods in mehreren Zonen abdeckt. Das SLA für die Compute Engine gilt weiterhin.

1. Speichern Sie das folgende Manifest als single-zone-selector.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-singlezone
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-singlezone
     template:
       metadata:
         labels:
           app: nginx-singlezone
       spec:
         nodeSelector:
           topology.kubernetes.io/zone: "us-central1-a"
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
   

   Dieses Manifest weist GKE an, alle Replikate im Deployment in der Zone us-central1-a zu platzieren.

2. Erstellen Sie das Deployment:

   kubectl create -f single-zone-selector.yaml
   

Pod-Platzierung in ausgewählten Zonen mithilfe einer Compute-Klasse priorisieren

GKE-Compute-Klassen bieten einen Kontrollmechanismus, mit dem Sie eine Liste von Prioritäten für die Knotenkonfiguration definieren können. Mit zonalen Einstellungen können Sie die Zonen definieren, in denen GKE Pods platzieren soll.

Achtung: Wir raten davon ab, zonale Einstellungen in Compute-Klassen mit früheren zonalen Topologiemethoden in Kubernetes zu kombinieren.

Priorität von Standortzonen verwenden

Zum Definieren von zonalen Einstellungen in Compute-Klassen mithilfe der Priorität von Standortzonen ist die GKE-Version 1.33.1-gke.1545000 oder höher erforderlich.

Im folgenden Beispiel wird eine Compute-Klasse erstellt, die eine Liste bevorzugter Zonen für Pods angibt.

In diesen Schritten wird davon ausgegangen, dass sich Ihr Cluster in der Region us-central1 befindet. Wenn sich Ihr Cluster in einer anderen Region befindet, ändern Sie die Werte der Zonen im Manifest in gültige Zonen in Ihrer Clusterregion.

1. Speichern Sie das folgende Manifest als zones-custom-compute-class.yaml:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: zones-custom-compute-class
   spec:
     priorities:
     - location:
       zones: [us-central1-a, us-central1-b]
     - location:
       zones: [us-central1-c]
     activeMigration:
       optimizeRulePriority: true
     nodePoolAutoCreation:
       enabled: true
     whenUnsatisfiable: ScaleUpAnyway
   

   Dieses Manifest für die Compute-Klasse ändert das Skalierungsverhalten so:

   1. GKE versucht, Pods entweder in us-central1-a oder in us-central1-b zu platzieren.
   2. Wenn us-central1-a und us-central1-b keine verfügbare Kapazität haben, versucht GKE, Pods in us-central1-c zu platzieren.
   3. Wenn us-central1-c keine verfügbare Kapazität hat, sorgt das Feld whenUnsatisfiable: ScaleUpAnyway dafür, dass GKE die Pods in einer beliebigen verfügbaren Zone in der Region platziert.
   4. Wenn eine Zone mit höherer Priorität in der Compute-Klasse später verfügbar wird, sorgt das Feld activeMigration.optimizeRulePriority: true dafür, dass GKE die Pods aus Zonen mit niedrigerer Priorität in diese Zone verschiebt. Bei dieser Migration wird das Budget für Pod-Störungen verwendet, um die Dienstverfügbarkeit zu gewährleisten.

2. Erstellen Sie die benutzerdefinierte Compute-Klasse:

   kubectl create -f zones-custom-compute-class.yaml
   

   Die GKE erstellt eine benutzerdefinierte Compute-Klasse, auf die Ihre Arbeitslasten verweisen können.

3. Speichern Sie das folgende Manifest als custom-compute-class-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-zonal-preferences
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-zonal-preferences
     template:
       metadata:
         labels:
           app: nginx-zonal-preferences
       spec:
         nodeSelector:
           cloud.google.com/compute-class: "zones-custom-compute-class"
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
   

4. Erstellen Sie das Deployment:

   kubectl create -f custom-compute-class-deployment.yaml
   

Priorität der „zoneTypes“ für den Standort verwenden

Zum Definieren von zonalen Präferenzen in Compute-Klassen mit der Priorität für Standortzonentypen ist die GKE-Version 1.35.2-gke.1842000 oder höher erforderlich. Wenn Sie einen Zonentyps für Ihre Pods auswählen, wird je nach Ihren Einstellungen ein neuer Knotenpool verwendet oder erstellt, der alle Zonen eines bestimmten Typs umfasst.

Sie können die folgenden Zonentypten in Ihrer Compute-Klasse angeben:

• STANDARD: Für allgemeine Zwecke, Google Cloud Zonen in einer Region. Empfohlen für Nicht-ML-Arbeitslasten.
• AI: Spezielle Zonen, die für KI-/Beschleunigerkapazität optimiert sind. Empfohlen für KI/ML-Arbeitslasten.
• CLUSTER_DEFAULT: Zonen, die im autoprovisioning-locations des Clusters angegeben sind (oder die Standorte des Clusters, wenn leer).

Weitere Informationen zu Standard- und KI-Zonen finden Sie unter Informationen zu KI-Zonen.

Einschränkungen beim Kombinieren von Feldern

Sie können das Feld zoneTypes nicht mit dem Feld location.zones oder dem Feld reservations.specific im selben Prioritätseintrag kombinieren. Sie können das Feld zoneTypes und das Feld location.zones in derselben Compute-Klasse verwenden, sofern Sie sie in separate Prioritätseinträge einfügen.

Außerdem gilt das Feld priorityDefaults für jede Priorität in der Compute-Klasse. Eine Folge dieser Regel ist, dass Sie das Feld location.zones oder das Feld reservations.specific in keiner Priorität verwenden können, wenn Sie das Feld zoneTypes im Feld priorityDefaults festlegen.

Gültiges Beispiel: separate Prioritäten

Das folgende Beispiel ist gültig, da zones und zoneTypes in separaten Prioritätseinträgen angegeben sind:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: valid-zonal-preferences
spec:
  priorities:
  - location:
      zones: [us-central1-a]
  - location:
      zoneTypes: [AI]

Ungültiges Beispiel: Gleiche Priorität

Das folgende Beispiel ist ungültig, da zones und zoneTypes im selben Prioritätseintrag angegeben sind:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: invalid-same-priority
spec:
  priorities:
  - location:
      zones: [us-central1-a]
      zoneTypes: [AI] # Error: mutually exclusive

Ungültiges Beispiel: Konflikt mit Standardeinstellungen

Das folgende Beispiel ist ungültig, da das Festlegen des Felds zoneTypes im Abschnitt priorityDefaults mit dem Feld zones im Prioritätseintrag in Konflikt steht:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: invalid-defaults-conflict
spec:
  priorityDefaults:
    location:
      zoneTypes: [AI]
  priorities:
  - location:
      zones: [us-central1-a] # Error: merges with defaults

Verwendungsbeispiel

Im folgenden Beispiel wird eine Compute-Klasse erstellt, die eine Liste bevorzugter Zonentyps für Pods angibt.

1. Speichern Sie das folgende Manifest als zone-types-custom-compute-class.yaml:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: zone-types-custom-compute-class
   spec:
     priorities:
     - location:
       zones: [us-central1-c]
     - location:
       zoneTypes:
       - AI
     - location:
       zoneTypes:
       - CLUSTER_DEFAULT
     activeMigration:
       optimizeRulePriority: true
     nodePoolAutoCreation:
       enabled: true
     whenUnsatisfiable: ScaleUpAnyway
   

   Dieses Manifest für die Compute-Klasse ändert das Skalierungsverhalten so:

   1. GKE versucht, Pods in einer der us-central1-c-Zonen zu platzieren.
   2. Wenn us-central1-c keine verfügbare Kapazität hat, versucht GKE, Pods in einer beliebigen AI-Zone in der Region zu platzieren.
   3. Wenn in keiner der AI-Zonen Kapazität verfügbar ist, versucht GKE, Pods in einer der CLUSTER_DEFAULT-Zonen zu platzieren.
   4. Wenn in keiner der CLUSTER_DEFAULT-Zonen Kapazität verfügbar ist, sorgt das Feld whenUnsatisfiable: ScaleUpAnyway dafür, dass GKE die Pods in einer beliebigen verfügbaren Zone in der Region platziert.
   5. Wenn eine Zone mit höherer Priorität in der Compute-Klasse später verfügbar wird, sorgt das Feld activeMigration.optimizeRulePriority: true dafür, dass GKE die Pods von Zonen mit niedrigerer Priorität in diese Zone verschiebt. Bei dieser Migration wird das Budget für Pod-Störungen verwendet, um die Dienstverfügbarkeit zu gewährleisten.

2. Erstellen Sie die benutzerdefinierte Compute-Klasse:

   kubectl create -f zone-types-custom-compute-class.yaml
   

   Die GKE erstellt eine benutzerdefinierte Compute-Klasse, auf die Ihre Arbeitslasten verweisen können.

3. Speichern Sie das folgende Manifest als custom-compute-class-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-zonal-preferences
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-zonal-preferences
     template:
       metadata:
         labels:
           app: nginx-zonal-preferences
       spec:
         nodeSelector: cloud.google.com/compute-class: "zone-types-custom-compute-class"
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
   

4. Erstellen Sie das Deployment:

   kubectl create -f custom-compute-class-deployment.yaml
   

Hinweis: Wenn Sie das Feld zoneTypes verwenden, insbesondere wenn das Feld reservation.affinity auf den Wert AnyBestEffort gesetzt ist, empfehlen wir, das Feld locationPolicy auf ANY zu setzen. Wenn Sie locationPolicy: ANY angeben, kann der Orchestrator für die Hochskalierung Echtzeit-Kapazitätssignale für eine optimale Platzierung verwenden.

So bewertet NAP zoneTypes

Bei der Entscheidung, ob ein vorhandener Knotenpool wiederverwendet oder ein neuer erstellt werden soll, erfordert die automatische Knotenbereitstellung (Node Auto-Provisioning, NAP) in der Regel eine genaue Übereinstimmung zwischen den vorhandenen Zonen des Knotenpools und den angeforderten zoneTypes. Wenn Sie eine Priorität aktualisieren, um umfassendere Zonentypten einzuschließen (z.B. von [AI] zu [AI, STANDARD]), stellt NAP einen neuen Knotenpool bereit, der der neuen genauen Form entspricht.

Hinweis: Da Konfigurationen mit kompakter Platzierung und TPU-Konfigurationen mit mehreren Hosts strikt auf eine einzelne Zone beschränkt sind, gilt für sie eine andere Regel. NAP verwendet einen vorhandenen Knotenpool mit einer einzelnen Zone wieder, solange die Zone eine Teilmenge der ausgewählten zoneTypes ist. Es wird nicht versucht, einen neuen Knotenpool zu erstellen, nur weil die Priorität einen größeren Bereich akzeptabler Zonen definiert.

Maschinentypabhängiges Kürzen

Wenn ein Maschinentyp (z. B. h3-standard-88) nur in einer Teilmenge der durch einen Typ definierten Zonen verfügbar ist (z. B. nur in us-central1-a), kürzt GKE die Liste der Knotenpoolstandorte automatisch, sodass nur Zonen enthalten sind, in denen diese Hardware physisch vorhanden ist.

KI-Zonen für die Erkennung

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.

Wichtig: Der Zugriff auf KI-Zonen ist eingeschränkt, sofern Sie sie nicht für IhrGoogle Cloud -Projekt aktiviert haben. Wenn Sie sie verwenden möchten, müssen Sie KI-Zonen aktivieren (Vorabversion).

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.
  Hinweis: Auch wenn GKE Ihnen das Erstellen des Knotenpools ermöglicht, stellt Compute Engine die VMs nur bereit, wenn diese Bedingungen erfüllt sind. Weitere Informationen finden Sie unter KI-Zonen.

• 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.

Pod-Platzierung prüfen

Um die Pod-Platzierung zu überprüfen, listen Sie die Pods auf und prüfen Sie die Knotenlabels. Mehrere Pods können auf einem einzelnen Knoten ausgeführt werden. Wenn Sie also „nodeAffinity“ verwenden, werden möglicherweise keine Pods in mehreren Zonen angezeigt.

1. Listen Sie Ihre Pods auf:

   kubectl get pods -o wide
   

   Die Ausgabe ist eine Liste der ausgeführten Pods und des entsprechenden GKE-Knotens.

2. Beschreiben Sie die Knoten:

   kubectl describe node NODE_NAME | grep "topology.kubernetes.io/zone"
   

   Ersetzen Sie NODE_NAME durch den Namen des Knotens.

   Die Ausgabe sieht in etwa so aus:

   topology.kubernetes.io/zone: us-central1-a
   

Wenn Sie möchten, dass GKE Ihre Pods gleichmäßig auf mehrere Zonen verteilt, um das Failover über mehrere fehlerhafte Domains hinweg zu verbessern, verwenden Sie topologySpreadConstraints.

Nächste Schritte

• GKE-Arbeitslasten voneinander trennen
• Netzwerkverkehr in derselben Topologie wie der Knoten halten
• Pods auf mehrere Ausfallzonen verteilen