Posiziona i pod GKE in zone specifiche

Autopilot Standard

Questa pagina spiega come indicare a Google Kubernetes Engine (GKE) di eseguire i pod su 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 di Compute Engine a livello di zona.
• I pod devono essere eseguiti insieme ad altre risorse a livello di zona, come le istanze Cloud SQL.

Puoi anche utilizzare il posizionamento zonale con il routing del traffico con riconoscimento della topologia per ridurre la latenza tra client e workload. Per informazioni dettagliate sul routing del traffico con riconoscimento della topologia, consulta Routing con riconoscimento della topologia.

L'utilizzo della topologia zonale per controllare il posizionamento dei pod è un meccanismo avanzato di Kubernetes 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 a livello di regione, che è l'impostazione predefinita di GKE, quando possibile.

Metodi di posizionamento zonale

La topologia zonale è integrata in Kubernetes con l' topology.kubernetes.io/zone: ZONE etichetta del nodo. 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ù Google Cloud zone. Questo metodo è più flessibile di un nodeSelector perché ti consente di posizionare i pod in più zone.

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

• 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 Google Cloud zone. Consente di spostare dinamicamente il workload nell'insieme 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 zonali utilizzando la topologia zonale presenta le seguenti considerazioni:

• Il cluster deve trovarsi nella stessa Google Cloud regione 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 zonale è 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
• Se vuoi 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 gcloud components update comando. 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 compute/region proprietà. 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 Google Cloud regione 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 serie di zone (ad esempio, in 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 un'altra regione, modifica le zone nel campo dei valori del manifest con zone valide nella regione del cluster.

   (Facoltativo) Se esegui il provisioning delle 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 Google Cloud delle 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. 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 è equivalente 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 ti consente di definire un elenco di priorità di configurazione dei nodi. Le preferenze zonali ti consentono di definire le zone in cui vuoi che GKE posizioni i pod.

Attenzione: non è consigliabile combinare le preferenze zonali nelle classi di computing con i metodi di topologia zonale precedenti in Kubernetes.

Utilizzo della priorità delle zone di località

La definizione delle preferenze zonali nelle classi di computing 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 cluster si trovi nella regione us-central1. Se il cluster si trova in un'altra regione, modifica i valori delle zone nel manifest con 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 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 in un secondo momento diventa disponibile una zona con priorità più alta nella classe di computing, il campo activeMigration.optimizeRulePriority: true fa sì 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 computing personalizzata:

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

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

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 zona di località

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

Puoi specificare i seguenti tipi di zona nella classe di computing:

• STANDARD: zone per scopi generici in una regione. Google Cloud Consigliato per i workload non ML.
• AI: zone specializzate ottimizzate per la capacità AI/acceleratore. Consigliato per i workload AI/ML.
• CLUSTER_DEFAULT: zone specificate in autoprovisioning-locations del cluster (o le località del cluster se vuote).

Per ulteriori informazioni 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 inserisca 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à

L'esempio seguente 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 zona preferiti 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 in un secondo momento diventa disponibile una zona con priorità più alta nella classe di computing, il campo activeMigration.optimizeRulePriority: true fa sì 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 computing personalizzata:

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

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

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à orizzontale di utilizzare indicatori di capacità in tempo reale per un posizionamento ottimale.

In che modo 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 i zoneTypes richiesti. 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é le configurazioni di posizionamento compatto e multi-host TPU sono strettamente a zona singola, seguono una regola diversa. NAP riutilizzerà un pool di nodi a zona singola esistente purché la 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.

Rimozione con riconoscimento del 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 rimuove automaticamente l'elenco delle località del pool di nodi in modo da includere solo le zone in cui l'hardware è fisicamente presente.

Target delle zone AI

Le zone AI sono zone specializzate utilizzate per i workload di addestramento e inferenza AI/ML. Queste zone forniscono una capacità di accelerazione ML significativa. Per ulteriori informazioni, consulta la documentazione sulle zone AI.

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

Importante: l'accesso alle zone AI è limitato a meno che non le abbia abilitate per il tuo Google Cloud progetto. Per utilizzarle, abilita 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 è denominata us-central1-ai1a.
• Al momento sono supportate solo le VM TPU.
• Il piano di controllo 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, collegate a una prenotazione o fanno parte di un pool di nodi con un rapporto specifico tra VM acceleratore e VM per scopi generici.
  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 ulteriori informazioni, 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 disponibilità, ti consigliamo di utilizzare zone diverse. Ad esempio, evita di utilizzare sia us-central1-ai1a sia us-central1-a per l'alta disponibilità.

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 zona AI. ComputeClasses ti aiuta a definire un elenco con priorità di configurazioni hardware per i tuoi workload. Per un esempio, consulta Informazioni su ComputeClasses.
• Provisioning automatico dei nodi: utilizza un nodeSelector o nodeAffinity nella specifica del pod per indicare al provisioning automatico dei nodi di creare un pool di nodi nella zona AI. Se il workload non ha come target esplicito una zona AI, il provisioning automatico dei nodi considera 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 non configuri diversamente. 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 node pool, utilizza una zona AI nel flag --node-locations quando crei un node pool. 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. Più pod potrebbero essere eseguiti 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 su più zone per migliorare il failover su più domini di 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 di errore