Posiziona i pod GKE in zone specifiche

Autopilot Standard

Questa pagina mostra come indicare a Google Kubernetes Engine (GKE) di eseguire i pod sui nodi in zone Google Cloud specifiche utilizzando la topologia di zona. Questo tipo di posizionamento è utile in situazioni come le seguenti:

• I pod devono accedere ai dati archiviati in un disco permanente di Compute Engine a livello di zona.
• I pod devono essere eseguiti insieme ad altre risorse di zona, come le istanze Cloud SQL.

Puoi anche utilizzare il posizionamento a livello di zona con il routing del traffico sensibile alla topologia per ridurre la latenza tra client e workload. Per informazioni dettagliate sul routing del traffico sensibile alla topologia, consulta Routing sensibile alla topologia.

L'utilizzo della topologia a livello di zona per controllare il posizionamento dei pod è un meccanismo Kubernetes avanzato che dovresti utilizzare solo se la tua situazione richiede l'esecuzione dei pod in zone specifiche. Nella maggior parte degli ambienti di produzione, ti consigliamo di utilizzare risorse a livello di regione, che è l'impostazione predefinita di GKE, se possibile.

Metodi di posizionamento a livello di zona

La topologia a livello di zona è integrata in Kubernetes con l'etichetta del nodo topology.kubernetes.io/zone: ZONE. Per indicare a GKE di posizionare un pod in una zona specifica, utilizza uno dei seguenti metodi:

• nodeAffinity: specifica una regola nodeAffinity nella specifica del pod per una o più zone Google Cloud . Questo metodo è più flessibile di un nodeSelector perché consente di posizionare i pod in più zone.

• nodeSelector: specifica un nodeSelector nella specifica del pod per una singola zona Google Cloud .

• Classi di computing: configura il pod in modo che utilizzi una classe di computing GKE. Questo approccio ti consente di definire un elenco con priorità di insiemi di zone Google Cloud . Consente di spostare dinamicamente il workload nel set di zone preferito quando i nodi sono disponibili in queste zone. Per ulteriori informazioni, consulta Informazioni sulle classi di computing personalizzate.

Considerazioni

Il posizionamento dei pod a livello di zona utilizzando la topologia a livello di zona presenta le seguenti considerazioni:

• Il cluster deve trovarsi nella stessa regione Google Cloud delle zone richieste.
• Nei cluster Standard, devi utilizzare il provisioning automatico dei nodi o creare node pool con nodi nelle zone richieste. I cluster Autopilot gestiscono automaticamente questo processo.
• I cluster standard devono essere cluster a livello di regione.

Prezzi

La topologia a livello di zona è una funzionalità di pianificazione di Kubernetes ed è offerta senza costi aggiuntivi in GKE.

Per i dettagli sui prezzi, consulta Prezzi di GKE.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati di avere un cluster GKE esistente nella stessa regioneGoogle Cloud delle zone in cui vuoi posizionare i pod. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

Posiziona i pod in una zona multipla utilizzando nodeAffinity

nodeAffinity di Kubernetes fornisce un meccanismo di controllo della pianificazione flessibile che supporta più selettori di etichette e operatori logici. Utilizza nodeAffinity se vuoi consentire l'esecuzione dei pod in una zona di un insieme di zone (ad esempio, us-central1-a o us-central1-f).

1. Salva il seguente manifest come 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
   

   Questo manifest crea un deployment con tre repliche e posiziona i pod in us-central1-a o us-central1-f in base alla disponibilità dei nodi.

   Assicurati che il cluster si trovi nella regione us-central1. Se il tuo cluster si trova in una regione diversa, modifica le zone nel campo dei valori del manifest in zone valide nella regione del tuo cluster.

   (Facoltativo) Se esegui il provisioning di VM TPU, utilizza una zona AI, ad esempio us-central1-ai1a. Le zone AI sono località specializzate ottimizzate per i workload AI/ML all'interno delle regioni Google Cloud .

2. Crea il deployment:

   kubectl create -f multi-zone-affinity.yaml
   

   GKE crea i pod nei nodi in una delle zone specificate. Più pod potrebbero essere eseguiti sullo stesso nodo. Facoltativamente, puoi utilizzare l'anti-affinità dei pod per indicare a GKE di posizionare ogni pod su un nodo separato.

Posiziona i pod in una zona singola utilizzando un nodeSelector

Per posizionare i pod in una singola zona, utilizza un nodeSelector nella specifica del pod. Un nodeSelector equivale a una regola nodeAffinity requiredDuringSchedulingIgnoredDuringExecution in cui è specificata una singola zona.

Attenzione: i pod posizionati in una singola zona utilizzando la topologia a livello di zona potrebbero non essere coperti dall'accordo sul livello del servizio (SLA) di Autopilot, che copre i pod Autopilot in più zone. Lo SLA di Compute Engine continua ad applicarsi.

1. Salva il seguente manifest come 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
   

   Questo manifest indica a GKE di posizionare tutte le repliche del deployment nella zona us-central1-a.

2. Crea il deployment:

   kubectl create -f single-zone-selector.yaml
   

Assegna la priorità al posizionamento dei pod nelle zone selezionate utilizzando una classe di computing

Le classi di computing GKE forniscono un meccanismo di controllo che consente di definire un elenco di priorità di configurazione dei nodi. Le preferenze di zona ti consentono di definire le zone in cui vuoi che GKE posizioni i pod.

Attenzione: Non consigliamo di combinare le preferenze zonali nelle classi di calcolo con i precedenti metodi di topologia zonale in Kubernetes.

Utilizzo della priorità delle zone di località

La definizione delle preferenze di zona nelle classi di computing utilizzando la priorità delle zone di località richiede GKE versione 1.33.1-gke.1545000 o successiva.

L'esempio seguente crea una classe di computing che specifica un elenco di zone preferite per i pod.

Questi passaggi presuppongono che il cluster si trovi nella regione us-central1. Se il tuo cluster si trova in una regione diversa, modifica i valori delle zone nel manifest in zone valide nella regione del tuo cluster.

1. Salva il seguente manifest come 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
   

   Questo manifest della classe di computing modifica il comportamento di scalabilità come segue:

   1. GKE tenta di posizionare i pod in us-central1-a o in us-central1-b.
   2. Se us-central1-a e us-central1-b non hanno capacità disponibile, GKE tenta di posizionare i pod in us-central1-c.
   3. Se us-central1-c non ha capacità disponibile, il campo whenUnsatisfiable: ScaleUpAnyway fa sì che GKE posizioni i pod in qualsiasi zona disponibile nella regione.
   4. Se una zona con priorità più alta nella classe di computing diventa disponibile in un secondo momento, il campo activeMigration.optimizeRulePriority: true fa sì che GKE sposti i pod in quella zona da qualsiasi zona con priorità più bassa. Questa migrazione utilizza il budget di interruzione dei pod per garantire la disponibilità del servizio.

2. Crea la classe di computing personalizzata:

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

   GKE crea una classe di computing personalizzata a cui i tuoi workload possono fare riferimento.

3. Salva il seguente manifest come 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. Crea il deployment:

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

Utilizzo della priorità dei tipi di zone di località

La definizione delle preferenze di zona nelle classi di computing utilizzando la priorità dei tipi di zona della località richiede GKE versione 1.35.2-gke.1842000 o successiva. La selezione di un tipo di zona per i pod, a seconda delle impostazioni, utilizzerà o creerà un nuovo pool di nodi che comprende tutte le zone di un determinato tipo.

Nella classe di computing puoi specificare i seguenti tipi di zone:

• STANDARD: per uso generico, Google Cloud zone in una regione. Opzione consigliata per i workload non ML.
• AI: zone specializzate ottimizzate per la capacità di AI/acceleratori. Opzione consigliata per i workload AI/ML.
• CLUSTER_DEFAULT: le zone specificate nel campo autoprovisioning-locations del cluster (o le località del cluster se vuote).

Per saperne di più sulle zone standard e AI, consulta Informazioni sulle zone AI.

Limitazioni per la combinazione di campi

Non puoi combinare il campo zoneTypes con il campo location.zones o il campo reservations.specific nella stessa voce di priorità. Puoi utilizzare il campo zoneTypes e il campo location.zones nella stessa classe di computing, purché li inserisci in voci di priorità separate.

Inoltre, il campo priorityDefaults si applica a ogni priorità nella classe di computing. Una conseguenza di questa regola è che l'impostazione del campo zoneTypes nel campo priorityDefaults impedisce di utilizzare il campo location.zones o il campo reservations.specific in qualsiasi priorità.

Esempio valido: priorità separate

L'esempio seguente è valido perché zones e zoneTypes sono specificati in voci di priorità separate:

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

Esempio non valido: stessa priorità

Il seguente esempio non è valido perché zones e zoneTypes sono specificati nella stessa voce di priorità:

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

Esempio non valido: conflitto con i valori predefiniti

L'esempio seguente non è valido perché l'impostazione del campo zoneTypes nella sezione priorityDefaults è in conflitto con il campo zones nella voce di priorità:

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

Esempio di utilizzo

L'esempio seguente crea una classe di computing che specifica un elenco di tipi di zone preferite per i pod.

1. Salva il seguente manifest come 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
   

   Questo manifest della classe di computing modifica il comportamento di scalabilità come segue:

   1. GKE tenta di posizionare i pod nella zona us-central1-c.
   2. Se us-central1-c non ha capacità disponibile, GKE tenta di posizionare i pod in qualsiasi zona AI della regione.
   3. Se nessuna delle zone AI ha capacità disponibile, GKE tenta di posizionare i pod in una delle zone CLUSTER_DEFAULT.
   4. Se nessuna delle zone CLUSTER_DEFAULT ha capacità disponibile, il campo whenUnsatisfiable: ScaleUpAnyway fa sì che GKE posizioni i pod in qualsiasi zona disponibile nella regione.
   5. Se una zona con priorità più alta nella classe di computing diventa disponibile in un secondo momento, il campo activeMigration.optimizeRulePriority: true fa sì che GKE sposti i pod in quella zona da qualsiasi zona con priorità più bassa. Questa migrazione utilizza il budget di interruzione dei pod per garantire la disponibilità del servizio.

2. Crea la classe di computing personalizzata:

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

   GKE crea una classe di computing personalizzata a cui i tuoi workload possono fare riferimento.

3. Salva il seguente manifest come 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. Crea il deployment:

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

Nota: quando utilizzi il campo zoneTypes, in particolare con un campo reservation.affinity impostato sul valore AnyBestEffort, ti consigliamo di impostare il campo locationPolicy su ANY. Se specifichi locationPolicy: ANY, l'orchestratore di scale up può utilizzare gli indicatori di capacità in tempo reale per un posizionamento ottimale.

In che modo NAP valuta zoneTypes

Per determinare se riutilizzare un pool di nodi esistente o crearne uno nuovo, il provisioning automatico dei nodi (NAP) in genere richiede una corrispondenza esatta tra le zone esistenti del node pool e il valore zoneTypes richiesto. Se aggiorni una priorità per includere tipi di zone più ampi (ad esempio, passando da [AI] a [AI, STANDARD]), NAP eseguirà il provisioning di un nuovo pool di nodi in modo che corrisponda alla nuova forma esatta.

Nota: poiché il posizionamento compatto e le configurazioni multi-host TPU sono rigorosamente a zona singola, seguono una regola diversa. NAP riutilizzerà un pool di nodi a zona singola esistente, purché la sua zona sia un sottoinsieme dei tipi di zona selezionati. Non tenterà di creare un nuovo pool di nodi solo perché la priorità definisce un intervallo più ampio di zone accettabili.

Trimming sensibile al tipo di macchina

Se un tipo di macchina (ad esempio h3-standard-88) è disponibile solo in un sottoinsieme delle zone definite da un tipo (ad esempio, solo in us-central1-a), GKE riduce automaticamente l'elenco delle località dei pool di nodi in modo da includere solo le zone in cui l'hardware è fisicamente presente.

Zone AI target

Le zone AI sono zone specializzate utilizzate per i workload di addestramento e inferenza AI/ML. Queste zone offrono una capacità significativa di acceleratori ML. Per saperne di più, consulta la documentazione relativa alle zone AI.

In questo documento e nella documentazione di GKE, "zone standard" o "zone" si riferiscono alle zone non AI all'interno di una regione Google Cloud .

Importante: l'accesso alle zone AI è limitato, a meno che non siano state attivate per il tuo progettoGoogle Cloud . Per utilizzarle, attiva le zone AI (Anteprima).

Prima di utilizzare una zona AI in GKE, considera le seguenti caratteristiche:

• Per utilizzare una zona AI con i cluster GKE esistenti, il control plane deve eseguire la versione 1.36.4-gke.1495002 o successiva oppure 1.37.1-gke.1552000 o successiva. Queste versioni consentono al control plane di riconoscere la zona e registrare i nodi. Se il control plane esegue la versione 1.35 o precedente o una versione precedente a questi minimi, esegui l'upgrade del control plane prima di creare i node pool nella AI Zone. Se l'upgrade non è possibile, contatta l'assistenza clienti Google Cloud.
• Le zone AI sono separate fisicamente dalle zone standard per fornire spazio di archiviazione e potenza aggiuntivi. Questa separazione potrebbe comportare una latenza più elevata, che è generalmente tollerabile per i workload AI/ML.
• Le zone AI hanno un suffisso con la notazione ai. Ad esempio, una zona AI nella regione us-central1 è denominata us-central1-ai1a.
• Al momento sono supportate solo le VM TPU.
• Il control plane del cluster viene eseguito in una o più zone standard all'interno della stessa regione della zona AI.

• Puoi eseguire VM senza TPU collegate in una zona AI solo se soddisfi i seguenti requisiti:

  • Stai già eseguendo altri workload che utilizzano VM TPU nella stessa zona.
  • Le VM non TPU sono VM spot, associate a una prenotazione o parte di un pool di nodi con un rapporto specifico tra VM con acceleratore e VM per uso generico.
  Nota: anche se GKE ti consente di creare il pool di nodi, Compute Engine esegue il provisioning delle VM solo se queste condizioni sono soddisfatte. Per saperne di più, consulta Zone AI.

• Le zone AI condividono componenti, come connessioni di rete e implementazioni software, con le zone standard che hanno lo stesso suffisso nella stessa regione. Per i workload ad alta affidabilità, ti consigliamo di utilizzare zone diverse. Ad esempio, evita di utilizzare sia us-central1-ai1a che us-central1-a per l'alta affidabilità.

Per impostazione predefinita, GKE non esegue il deployment dei workload nelle zone AI. Per utilizzare una zona AI, devi configurare una delle seguenti opzioni:

• (Consigliato) ComputeClasses: imposta la priorità più alta per richiedere TPU on demand in una AI Zone. Le classi di computing ti aiutano a definire un elenco con priorità delle configurazioni hardware per i tuoi workload. Per un esempio, consulta Informazioni su ComputeClasses.
• Provisioning automatico dei nodi: utilizza un nodeSelector o un nodeAffinity nella specifica del pod per indicare al provisioning automatico dei nodi di creare un pool di nodi nella zona AI. Se il tuo workload non ha come target esplicito una zona AI, il provisioning automatico dei nodi prende in considerazione solo le zone standard o le zone di --autoprovisioning-locations durante la creazione di nuovi node pool. Questa configurazione contribuisce a garantire che i workload che non eseguono modelli AI/ML rimangano nelle zone standard, a meno che tu non li configuri esplicitamente in modo diverso. Per un esempio di manifest che utilizza un nodeSelector, consulta Imposta le zone predefinite per i nodi creati automaticamente.
• GKE Standard: se gestisci direttamente i tuoi pool di nodi, utilizza una zona AI nel flag --node-locations quando crei un pool di nodi. Per un esempio, consulta Esegui il deployment dei workload TPU in GKE Standard.

Verifica il posizionamento dei pod

Per verificare il posizionamento dei pod, elenca i pod e controlla le etichette dei nodi. In un singolo nodo potrebbero essere eseguiti più pod, quindi potresti non vedere i pod distribuiti in più zone se hai utilizzato nodeAffinity.

1. Elenca i tuoi pod:

   kubectl get pods -o wide
   

   L'output è un elenco di pod in esecuzione e del nodo GKE corrispondente.

2. Descrivi i nodi:

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

   Sostituisci NODE_NAME con il nome del nodo.

   L'output è simile al seguente:

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

Se vuoi che GKE distribuisca i pod in modo uniforme su più zone per migliorare il failover su più domini in errore, utilizza topologySpreadConstraints.

Passaggi successivi

• Separa i workload GKE l'uno dall'altro
• Mantieni il traffico di rete nella stessa topologia del nodo
• Distribuisci i pod su più domini in errore