Configura la separazione dei workload in GKE

Autopilot Standard

Questa pagina spiega come indicare a Google Kubernetes Engine (GKE) di pianificare i pod insieme, separatamente o in località specifiche.

La separazione dei workload consente di utilizzare incompatibilità e tolleranze per indicare a GKE di separare i pod su nodi diversi, di posizionare i pod su nodi che soddisfano criteri specifici o di pianificare insieme workload specifici. Le azioni da intraprendere per configurare la separazione dei workload dipendono dalla configurazione del cluster GKE. La tabella seguente descrive le differenze:

Configurazione della separazione dei workload
Autopilot Standard con provisioning automatico dei nodi	Aggiungi una tolleranza per una coppia chiave-valore specifica alla specifica del pod e seleziona la coppia chiave-valore utilizzando un nodeSelector. GKE crea i nodi, applica l'incompatibilità dei nodi corrispondente e pianifica il pod sul nodo. Per istruzioni, consulta Separare i workload nei cluster Autopilot in questa pagina.
Standard senza provisioning automatico dei nodi	Crea un pool di nodi con un'incompatibilità dei nodi e un'etichetta dei nodi Aggiungi una tolleranza per questa incompatibilità alla specifica del pod Per istruzioni, consulta Isolare i workload in node pool dedicati. Attenzione: con questo metodo, se i nodi con incompatibilità esistenti non dispongono di risorse sufficienti per supportare un pod con una tolleranza, il pod rimane nello stato In attesa.

Questa guida utilizza uno scenario di esempio in cui hai due workload, un job batch e un server web, che vuoi separare l'uno dall'altro.

Quando utilizzare la separazione dei workload in GKE

La separazione dei workload è utile quando hai workload che svolgono ruoli diversi e non devono essere eseguiti sulle stesse macchine sottostanti. Alcuni scenari di esempio includono i seguenti:

• Hai un workload di coordinatore batch che crea job che vuoi mantenere separati.
• Esegui un server di gioco con un workload di matchmaking che vuoi separare dai pod di sessione.
• Vuoi separare le parti dello stack, ad esempio un server da un database.
• Vuoi separare alcuni workload per motivi di conformità o di policy.

Avviso: la separazione dei workload non deve mai essere utilizzata come limite di sicurezza principale. Non è un metodo per isolare i workload non attendibili e non mitiga tutti i percorsi di escalation. La separazione dei workload non è destinata a essere utilizzata come meccanismo di difesa. Per scoprire di più sui rischi dell'utilizzo della pianificazione di Kubernetes come metodo di isolamento, consulta Evitare gli attacchi di escalation dei privilegi.

Prezzi

Nei cluster Autopilot, ti vengono addebitate le risorse richieste dai pod durante l'esecuzione. Per i dettagli, consulta Prezzi di Autopilot. I pod che utilizzano la separazione dei workload hanno richieste di risorse minime più elevate rispetto ai pod normali.

Nei cluster standard, la fatturazione si basa sulla configurazione hardware e sulle dimensioni di ogni nodo, indipendentemente dal fatto che i pod siano in esecuzione sui nodi. Per i dettagli, consulta Prezzi standard.

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. Per scoprire come creare un cluster, utilizza una delle seguenti opzioni:

  • Crea un cluster Autopilot (consigliato)
  • Crea un cluster standard con provisioning automatico dei nodi
  • Crea un cluster standard

Separare i workload nei cluster Autopilot

Per separare i workload, aggiungi una tolleranza e un selettore di nodi alla specifica di ogni workload che definisce il nodo su cui deve essere eseguito il workload. Questo metodo funziona anche sui cluster standard con il provisioning automatico dei nodi abilitato.

1. Salva il seguente manifest come web-server.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-server
   spec:
     replicas: 6
     selector:
       matchLabels:
         pod: nginx-pod
     template:
       metadata:
         labels:
           pod: nginx-pod
       spec:
         tolerations:
         - key: group
           operator: Equal
           value: "servers"
           effect: NoSchedule
         nodeSelector:
           group: "servers"
         containers:
         - name: web-server
           image: nginx
   

   Questo manifest include i seguenti campi:

   • spec.tolerations: GKE può inserire i pod sui nodi che hanno l'incompatibilità group=servers:NoSchedule. GKE non può pianificare i pod che non hanno questa tolleranza su questi nodi.
   • spec.nodeSelector: GKE deve inserire i pod sui nodi che hanno l'etichetta del nodo group: servers.

   GKE aggiunge le etichette e le incompatibilità corrispondenti ai nodi di cui GKE esegue automaticamente il provisioning per eseguire questi pod.

2. Salva il seguente manifest come batch-job.yaml:

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: batch-job
   spec:
     completions: 5
     backoffLimit: 3
     ttlSecondsAfterFinished: 120
     template:
       metadata:
         labels:
           pod: pi-pod
       spec:
         restartPolicy: Never
         tolerations:
         - key: group
           operator: Equal
           value: "jobs"
           effect: NoSchedule
         nodeSelector:
           group: "jobs"
         containers:
         - name: pi
           image: perl
           command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
   

   Questo manifest include i seguenti campi:

   • spec.tolerations: GKE può inserire i pod sui nodi che hanno l'incompatibilità group=jobs:NoSchedule. GKE non può pianificare i pod che non hanno questa tolleranza su questi nodi.
   • spec.nodeSelector: GKE deve inserire i pod sui nodi che hanno l'etichetta del nodo group: jobs.

   GKE aggiunge le etichette e le incompatibilità corrispondenti ai nodi di cui GKE esegue automaticamente il provisioning per eseguire questi pod.

3. Esegui il deployment dei workload:

   kubectl apply -f batch-job.yaml web-server.yaml
   

Quando esegui il deployment dei workload, GKE esegue le seguenti operazioni per ogni workload:

1. GKE cerca i nodi esistenti che hanno l'incompatibilità dei nodi e l'etichetta dei nodi corrispondenti specificate nel manifest. Se esistono nodi e dispongono di risorse disponibili, GKE pianifica il workload sul nodo.
2. Se GKE non trova un nodo esistente idoneo per pianificare il workload, crea un nuovo nodo e applica l'incompatibilità dei nodi e l'etichetta dei nodi corrispondenti in base al manifest. GKE inserisce il pod sul nuovo nodo.

La presenza dell'effetto NoSchedule nell'incompatibilità dei nodi garantisce che i workload senza tolleranza non vengano inseriti sul nodo.

Verificare la separazione dei workload

Elenca i pod per trovare i nomi dei nodi:

kubectl get pods --output=wide

L'output è simile al seguente:

NAME                          READY   ...   NODE
batch-job-28j9h               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-78rcn               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-gg4x2               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-qgsxh               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-v4ksf               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
web-server-6bb8cd79b5-dw4ds   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm
web-server-6bb8cd79b5-g5ld6   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-jcdx5   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-pxdzw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-s66rw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-zq8hh   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm

Questo output mostra che i pod batch-job e i pod web-server vengono sempre eseguiti su nodi diversi.

Limitazioni della separazione dei workload con incompatibilità e tolleranze

Non puoi utilizzare i seguenti prefissi di chiave per la separazione dei workload:

• Chiavi specifiche di GKE e Kubernetes
• *cloud.google.com/
• *kubelet.kubernetes.io/
• *node.kubernetes.io/

Devi utilizzare chiavi univoche per la separazione dei workload.

Separare i workload nei cluster standard senza provisioning automatico dei nodi

La separazione dei workload nei cluster standard senza provisioning automatico dei nodi richiede la creazione manuale di node pool con le incompatibilità dei nodi e le etichette dei nodi appropriate per ospitare i workload. Per istruzioni, consulta Isolare i workload in node pool dedicati. Utilizza questo approccio solo se hai requisiti specifici che richiedono la gestione manuale dei node pool.

Creare un cluster con incompatibilità dei nodi

Quando crei un cluster in GKE, puoi assegnare incompatibilità dei nodi al cluster. In questo modo, le incompatibilità vengono assegnate a tutti i nodi creati con il cluster.

Se crei un pool di nodi, pool di nodi non eredita le incompatibilità dal cluster. Se vuoi che le incompatibilità siano presenti nel pool di nodi, devi utilizzare il flag --node-taints quando crei il pool di nodi.

Se crei un cluster standard con incompatibilità dei nodi che hanno l'effetto NoSchedule o NoExecute, GKE non può pianificare alcuni componenti gestiti da GKE, come kube-dns o metrics-server, nel pool di nodi predefinito creato da GKE quando crei il cluster. GKE non può pianificare questi componenti perché non hanno le tolleranze corrispondenti per le incompatibilità dei nodi. Devi aggiungere un nuovo pool di nodi che soddisfi una delle seguenti condizioni:

• Nessuna incompatibilità
• Un'incompatibilità con l'effetto PreferNoSchedule
• L'incompatibilità components.gke.io/gke-managed-components=true:NoSchedule

Una qualsiasi di queste condizioni consente a GKE di pianificare i componenti gestiti da GKE nel nuovo pool di nodi.

Per istruzioni, consulta Isolare i workload su nodi dedicati.

gcloud

Crea un cluster con incompatibilità dei nodi:

gcloud container clusters create CLUSTER_NAME \
    --node-taints KEY=VALUE:EFFECT

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del nuovo cluster.
• EFFECT: uno dei seguenti effetti: PreferNoSchedule, NoSchedule o NoExecute.
• KEY=VALUE: una coppia chiave-valore associata a EFFECT.

Console

Crea un cluster con incompatibilità dei nodi:

1. Nella Google Cloud console, vai alla pagina Crea un cluster Kubernetes.

   Vai a Crea un cluster Kubernetes

2. Configura il cluster come preferisci.

3. Nel riquadro di navigazione, in Node pool, espandi il pool di nodi che vuoi modificare, quindi fai clic su Metadati.

4. Nella sezione Incompatibilità dei nodi, fai clic su Aggiungi incompatibilità.

5. Nell'elenco a discesa Effetto, seleziona l'effetto desiderato.

6. Inserisci la coppia chiave-valore desiderata nei campi Chiave e Valore.

7. Fai clic su Crea.

API

Quando utilizzi l'API per creare un cluster, includi il campo nodeTaints in `nodeConfig:

POST https://container.googleapis.com/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/clusters

{
  'cluster': {
    'name': 'example-cluster',
    'nodeConfig': {
      'nodeTaints': [
        {
          'key': 'special',
          'Value': 'gpu',
          'effect': 'PreferNoSchedule'
        }
      ]
      ...
    }
    ...
  }
}

Rimuovere tutte le incompatibilità da un pool di nodi

Per rimuovere tutte le incompatibilità da un pool di nodi, esegui questo comando:

gcloud beta container node-pools update POOL_NAME \
    --node-taints="" \
    --cluster=CLUSTER_NAME

Sostituisci quanto segue:

• POOL_NAME: il nome del pool di nodi da modificare.
• CLUSTER_NAME: il nome del cluster del node pool.

Passaggi successivi

• Applicare policy di sicurezza predefinite utilizzando il controller di ammissione PodSecurity
• Eseguire un workload full-stack su larga scala