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 dort Knoten 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. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  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 mit 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 empfehlen nicht, zonale Einstellungen in Compute-Klassen mit früheren zonalen Topologiemethoden in Kubernetes zu kombinieren.

Priorität von Standortzonen verwenden

Für die Definition von zonalen Einstellungen in Compute-Klassen mit der Priorität von Standortzonen ist GKE-Version 1.33.1-gke.1545000 oder höher erforderlich.

Im folgenden Beispiel wird eine Compute-Klasse erstellt, in der eine Liste bevorzugter Zonen für Pods angegeben wird.

Bei 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 Compute-Klassenmanifest ändert das Skalierungsverhalten so:

   1. GKE versucht, Pods entweder in us-central1-a oder in us-central1-b zu platzieren.
   2. Wenn in us-central1-a und us-central1-b keine Kapazität verfügbar ist, 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 allen 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. Benutzerdefinierte Compute-Klasse erstellen:

   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 von „locationZoneTypes“ verwenden

Für das Definieren von zonalen Einstellungen in Compute-Klassen mit Priorität für Standortzonentypen ist 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 erstellt oder ein vorhandener Knotenpool verwendet, der alle Zonen eines bestimmten Typs umfasst.

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

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

Weitere Informationen zu Standard- und KI-Zonen finden Sie unter 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, in der eine Liste bevorzugter Zonentypen für Pods angegeben wird.

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
   

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

   1. Die GKE versucht, Pods in einer der us-central1-c-Zonen zu platzieren.
   2. Wenn in us-central1-c keine Kapazität verfügbar ist, 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 aus allen 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. Benutzerdefinierte Compute-Klasse erstellen:

   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 wird zoneTypes im NAP ausgewertet

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

Hinweis: Da die kompakte 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, sofern seine 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 Zuschneiden

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

KI-Zonen als Zielvorhaben festlegen

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, aktivieren Sie KI-Zonen (Vorschau).

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

• KI-Zonen sind physisch von Standardzonen getrennt, um zusätzlichen Speicherplatz und zusätzliche Leistung zu bieten. 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 in einer KI-Zone nur ausführen, wenn Sie die folgenden Anforderungen erfüllen:

  • Sie führen bereits andere Arbeitslasten aus, für die TPU-VMs in derselben Zone verwendet werden.
  • Die Nicht-TPU-VMs sind entweder Spot-VMs, an eine Reservierung gebunden oder Teil eines Knotenpools mit einem bestimmten Verhältnis von Beschleuniger- zu VMs für allgemeine Zwecke.
  Hinweis: Auch wenn GKE das Erstellen des Knotenpools zulässt, werden die VMs von Compute Engine nur bereitgestellt, 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 hoher Verfügbarkeit empfehlen wir die Verwendung verschiedener Zonen. Verwenden Sie beispielsweise nicht sowohl us-central1-ai1a als auch us-central1-a für die Hochverfügbarkeit.

Standardmäßig werden Ihre Arbeitslasten in GKE nicht in KI-Zonen bereitgestellt. 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 Compute-Klassen.
• Automatische Knotenbereitstellung: Verwenden Sie eine nodeSelector oder nodeAffinity in Ihrer Pod-Spezifikation, 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 trägt dazu bei, dass Arbeitslasten, für die keine KI-/ML-Modelle ausgeführt werden, in Standardzonen verbleiben, sofern Sie nichts anderes konfigurieren. Ein Beispiel für ein Manifest, in dem nodeSelector verwendet wird, 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