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 specifiche Google Cloud utilizzando la topologia zonale. Questo tipo di posizionamento è utile in situazioni come le seguenti:

• I pod devono accedere ai dati archiviati in un disco permanente 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 sull'instradamento del traffico in base alla topologia, vedi Instradamento in base alla topologia.

L'utilizzo della topologia zonale per controllare il posizionamento dei pod è un meccanismo Kubernetes avanzato che devi utilizzare solo se la tua situazione richiede che i pod vengano eseguiti in zone specifiche. Nella maggior parte degli ambienti di produzione, ti consigliamo di utilizzare le risorse di regione, che sono l'impostazione predefinita di GKE, se possibile.

Metodi di posizionamento zonale

La topologia zonale è 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é ti consente di posizionare i pod in più zone.

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

• Classi di calcolo: configura il pod in modo che utilizzi una classe di calcolo 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 saperne di più, 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 regionali.

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 operazioni:

• 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 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 cluster si trova in una regione diversa, modifica le zone nel campo dei valori del manifest in zone valide nella regione del cluster.

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

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. Se vuoi, 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 zona singola, utilizza un nodeSelector nella specifica del pod. Un nodeSelector equivale a una regola nodeAffinity requiredDuringSchedulingIgnoredDuringExecution con una singola zona specificata.

Attenzione: i pod che posizioni in una singola zona utilizzando la topologia zonale 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 nel 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 a livello di zona consentono di definire le zone in cui vuoi che GKE posizioni i pod.

Attenzione: sconsigliamo di combinare le preferenze di zona nelle classi di calcolo con i metodi di topologia di zona precedenti in Kubernetes.

Utilizzo della priorità delle zone di localizzazione

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

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

Questi passaggi presuppongono che il tuo 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 modo che corrispondano a zone valide nella regione del 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 calcolo modifica il comportamento di scalabilità nel seguente modo:

   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 inserire 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 calcolo diventa disponibile in un secondo momento, il campo activeMigration.optimizeRulePriority: true fa in modo che GKE sposti i pod in quella zona da qualsiasi zona con priorità inferiore. Questa migrazione utilizza il budget di interruzione dei pod per garantire la disponibilità del servizio.

2. Crea la classe di calcolo personalizzata:

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

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

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 localizzazione

La definizione delle preferenze di zona nelle classi di calcolo utilizzando la priorità dei tipi di zona di località richiede GKE versione 1.35.2-gke.1842000 o successive. A seconda delle impostazioni, la selezione di un tipo di zona per i pod utilizzerà o creerà un nuovo pool di nodi che si estende a 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. Consigliato per i workload non ML.
• AI: zone specializzate ottimizzate per la capacità di AI/acceleratore. Consigliato per i workload AI/ML.
• CLUSTER_DEFAULT: le zone specificate in 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 calcolo 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

Il seguente esempio 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 calcolo 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 qualsiasi 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 calcolo personalizzata:

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

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

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. La specifica di locationPolicy: ANY consente all'orchestratore di scalabilità verticale di utilizzare indicatori di capacità in tempo reale per un posizionamento ottimale.

Come NAP valuta zoneTypes

Quando determina 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 zoneTypes richiesto. Se aggiorni una priorità in modo da includere tipi di zona più ampi (ad es. 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é i posizionamenti compatti 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.

Taglio consapevole del tipo di macchina

Se un tipo di macchina (come 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 le abbia abilitate per il tuo progettoGoogle Cloud . Per utilizzarli, attiva le zone AI (anteprima).

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

• Le zone AI sono fisicamente separate dalle zone standard per fornire ulteriore spazio di archiviazione ed energia. Questa separazione potrebbe comportare una latenza maggiore, che in genere è 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 si chiama 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 all'interno della stessa regione. Per i workload ad alta affidabilità, ti consigliamo di utilizzare zone diverse. Ad esempio, evita di utilizzare sia us-central1-ai1a sia us-central1-a per l'alta affidabilità.

Per impostazione predefinita, GKE non esegue il deployment dei carichi di lavoro 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 zona AI. ComputeClasses ti consente di definire un elenco prioritario di 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 di AI/ML rimangano nelle zone standard, a meno che tu non configuri diversamente. Per un esempio di manifest che utilizza nodeSelector, vedi 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, vedi Esegui il deployment dei carichi di lavoro TPU in GKE Standard.

Verifica il posizionamento del pod

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

1. Elenca i 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 in più zone per migliorare il failover in più domini in errore, utilizza topologySpreadConstraints.

Passaggi successivi

• Separare i workload GKE tra loro
• Mantieni il traffico di rete nella stessa topologia del nodo
• Distribuire i pod su più domini in errore