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

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

Puoi anche utilizzare il posizionamento zonale con il routing del traffico sensibile alla topologia per ridurre la latenza tra client e workload. Per informazioni dettagliate sul routing del traffico in base alla topologia, vedi Routing in base alla 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 risorse regionali, ovvero l'impostazione predefinita di GKE, quando 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 nella specifica del pod per una singola zona. Google Cloud
Classi di calcolo: configura il pod in modo che utilizzi una classe di calcolo GKE. Questo approccio ti consente di definire un elenco prioritario di insiemi di Google Cloud zone. 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 di zona è una funzionalità di pianificazione di Kubernetes e viene 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:

Attiva l'API Google Kubernetes Engine.

Attiva 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 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

Kubernetes nodeAffinity 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 delle zone di un insieme (ad esempio, in us-central1-a o us-central1-f).

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 inserisce 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 in zone valide nella regione del 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 .

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

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.

Crea il deployment:

kubectl create -f single-zone-selector.yaml

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

Le classi di calcolo GKE forniscono un meccanismo di controllo che ti 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. La definizione delle preferenze di zona nelle classi di calcolo 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 tuo cluster si trova in un'altra regione, modifica i valori delle zone nel manifest in modo che corrispondano a zone valide nella regione del cluster.

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à 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 inserire i pod in us-central1-c.
3. Se us-central1-c non ha capacità disponibile, il campo whenUnsatisfiable: ScaleUpAnyway fa in modo che GKE posizioni i pod in qualsiasi zona disponibile della 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 per l'interruzione dei pod per garantire la disponibilità del servizio.
Crea la classe di calcolo personalizzata:
```
kubectl create -f zones-custom-compute-class.yaml
```
GKE crea una classe di computing personalizzata a cui i tuoi carichi di lavoro possono fare riferimento.

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

Crea il deployment:

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

Zone AI target

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

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 più elevata, 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 node pool, 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 carichi di lavoro a disponibilità elevata, ti consigliamo di utilizzare zone diverse. Ad esempio, evita di utilizzare sia us-central1-ai1a che 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 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 node pool 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 garantisce che i workload che non eseguono modelli AI/ML rimangano nelle zone standard, a meno che tu non configuri diversamente. Per un esempio di manifest che utilizza un nodeSelector, vedi Imposta le zone predefinite per i nodi creati automaticamente.
GKE Standard: se gestisci direttamente i tuoi node pool, utilizza una zona AI nel flag --node-locations quando crei un node pool. Per un esempio, consulta la sezione 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. In un singolo nodo potrebbero essere eseguiti più pod, quindi potresti non vedere i pod distribuiti su più zone se hai utilizzato nodeAffinity.

Elenca i tuoi pod:
```
kubectl get pods -o wide
```
L'output è un elenco di pod in esecuzione e del nodo GKE corrispondente.

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 tuoi pod in modo uniforme su più zone per un failover migliore su più domini di errore, utilizza topologySpreadConstraints.