Questa pagina mostra come indicare a Google Kubernetes Engine (GKE) di pianificare i pod insieme, separatamente o in posizioni specifiche.
La separazione dei carichi di lavoro ti consente di utilizzare incompatibilità e tolleranze per indicare a GKE di separare i pod su nodi diversi, posizionare i pod su nodi che soddisfano criteri specifici o pianificare insieme carichi di lavoro specifici. Le operazioni da eseguire per configurare la separazione dei carichi di lavoro dipendono dalla configurazione del cluster GKE. La tabella seguente descrive le differenze:
Configurazione della separazione dei workload | |
---|---|
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à del nodo corrispondente e pianifica il pod sul nodo. Per istruzioni, consulta Separare i carichi di lavoro nei cluster Autopilot in questa pagina. |
|
Standard senza provisioning automatico dei nodi |
Per istruzioni, consulta Isolare i workload in node pool dedicati. |
Questa guida utilizza uno scenario di esempio in cui hai due carichi di lavoro, 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 carichi di lavoro è utile quando hai carichi di lavoro che svolgono ruoli diversi e non devono essere eseguiti sulle stesse macchine sottostanti. Alcuni scenari di esempio includono:
- Hai un workload del coordinatore batch che crea job che vuoi mantenere separati.
- Esegui un server di gioco con un carico di lavoro 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 norme.
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 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
inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo
gcloud components update
.
Assicurati di avere un cluster GKE. Per scoprire come creare un cluster, utilizza uno dei seguenti metodi:
Separare i workload nei cluster Autopilot
Per separare i carichi di lavoro, aggiungi una tolleranza e un selettore di nodi a ogni specifica del carico di lavoro che definisce il nodo su cui deve essere eseguito il carico di lavoro. Questo metodo funziona anche sui cluster Standard in cui è abilitato il provisioning automatico dei nodi.
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ò posizionare i pod sui nodi che hanno il taintgroup=servers:NoSchedule
. GKE non può pianificare pod che non hanno questa tolleranza su questi nodi.spec.nodeSelector
: GKE deve posizionare i pod sui nodi che hanno l'etichetta del nodogroup: servers
.
GKE aggiunge le etichette e le incompatibilità corrispondenti ai nodi che GKE esegue il provisioning automatico per eseguire questi pod.
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ò posizionare i pod sui nodi che hanno il taintgroup=jobs:NoSchedule
. GKE non può pianificare pod che non hanno questa tolleranza su questi nodi.spec.nodeSelector
: GKE deve posizionare i pod sui nodi che hanno l'etichetta del nodogroup: jobs
.
GKE aggiunge le etichette e le incompatibilità corrispondenti ai nodi che GKE esegue il provisioning automatico per eseguire questi pod.
Esegui il deployment dei carichi di lavoro:
kubectl apply -f batch-job.yaml web-server.yaml
Quando esegui il deployment dei carichi di lavoro, GKE esegue le seguenti operazioni per ciascun carico di lavoro:
- GKE cerca i nodi esistenti che hanno il taint e l'etichetta del nodo corrispondenti specificati nel manifest. Se esistono nodi con risorse disponibili, GKE pianifica il workload sul nodo.
- Se GKE non trova un nodo esistente idoneo per pianificare il carico di lavoro, crea un nuovo nodo e applica il taint e l'etichetta del nodo corrispondenti in base al manifest. GKE posiziona il pod sul nuovo nodo.
La presenza dell'effetto NoSchedule
nell'incompatibilità del nodo garantisce che i carichi di lavoro
senza tolleranza non vengano posizionati sul nodo.
Verifica 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 delle chiavi per la separazione dei carichi di lavoro:
- Chiavi specifiche di GKE e Kubernetes
- *cloud.google.com/
- *kubelet.kubernetes.io/
- *node.kubernetes.io/
Devi utilizzare chiavi univoche per la separazione dei carichi di lavoro.
Separare i carichi di lavoro nei cluster standard senza il provisioning automatico dei nodi
La separazione dei carichi di lavoro nei cluster Standard senza il provisioning automatico dei nodi richiede la creazione manuale di pool di nodi con i taint dei nodi e le etichette dei nodi appropriati per ospitare i carichi di lavoro. Per istruzioni, consulta Isolare i workload in node pool dedicati. Utilizza questo approccio solo se hai requisiti specifici che richiedono la gestione manuale dei pool di nodi.
Crea un cluster con taint dei nodi
Quando crei un cluster in GKE, puoi assegnare taint 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 i taint dal cluster. Se vuoi taint sul pool di nodi, devi utilizzare il flag --node-taints
quando crei il pool di nodi.
Se crei un cluster Standard con taint dei nodi che hanno l'effetto NoSchedule
o NoExecute
, GKE non può pianificare alcuni componenti gestiti da GKE, come kube-dns
o metrics-server
sul 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 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 taint 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
oNoExecute
.KEY=VALUE
: una coppia chiave-valore associata aEFFECT
.
Console
Crea un cluster con taint dei nodi:
Vai alla pagina Google Kubernetes Engine nella console Trusted Cloud .
Fai clic su add_box Crea.
Configura il cluster come preferisci.
Nel riquadro di navigazione, in Pool di nodi, espandi il pool di nodi che vuoi modificare, quindi fai clic su Metadati.
Nella sezione Taint dei nodi, fai clic su add Aggiungi taint.
Nell'elenco a discesa Effetto, seleziona l'effetto desiderato.
Inserisci la coppia chiave-valore desiderata nei campi Chiave e Valore.
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 contaminazioni da un pool di nodi
Per rimuovere tutti i taint 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 criteri di sicurezza predefiniti utilizzando il controller di ammissione PodSecurity
- Esegui un carico di lavoro full stack su larga scala