Questa pagina mostra come utilizzare le VM preemptive in Google Kubernetes Engine (GKE).
Panoramica
Le VM prerilasciabili sono istanze VM di Compute Engine che hanno un prezzo inferiore rispetto alle VM standard e non offrono garanzie di disponibilità. Le VM prerilasciabili offrono funzionalità simili alle VM spot, ma durano solo fino a 24 ore dopo la creazione.
In alcuni casi, una VM prerilasciabile potrebbe durare più di 24 ore. Ciò può verificarsi quando la nuova istanza Compute Engine viene avviata troppo rapidamente e Kubernetes non riconosce che è stata creata una VM Compute Engine diversa. L'istanza di Compute Engine sottostante avrà una durata massima di 24 ore e seguirà il comportamento VM prerilasciabile preemptible.
Confronto con le VM spot
Le VM prerilasciabili condividono molte somiglianze con le VM spot, tra cui:
- Terminata quando Compute Engine richiede le risorse per eseguire le VM standard.
- Utile per l'esecuzione di carichi di lavoro stateless, batch o a tolleranza di errore.
- Prezzi inferiori rispetto alle VM standard.
- Nei cluster che eseguono GKE versione 1.20 e successive, l'arresto controllato dei nodi è abilitato per impostazione predefinita.
- Funziona con il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi.
A differenza delle VM spot, che non hanno un tempo di scadenza massimo, le VM preemptible durano solo fino a 24 ore dopo la creazione.
Puoi attivare le VM prerilasciabili su nuovi cluster e pool di nodi, utilizzare nodeSelector
o l'affinità dei nodi per controllare la pianificazione e utilizzare incompatibilità e tolleranze per evitare
problemi con i carichi di lavoro di sistema quando i nodi vengono prerilasciati.
Terminazione e arresto controllato delle VM prerilasciabili
Quando Compute Engine deve recuperare le risorse utilizzate dalle VM preemptible, a GKE viene inviata una notifica di prerilascio. Le VM prerilasciabili vengono terminate 30 secondi dopo aver ricevuto un avviso di terminazione.
Per impostazione predefinita, i cluster utilizzano l'arresto controllato dei nodi. Kubelet rileva la notifica di terminazione e termina normalmente i pod in esecuzione sul nodo. Se i pod fanno parte di un carico di lavoro gestito, ad esempio un deployment, il controller crea e pianifica nuovi pod per sostituire quelli terminati.
In base al principio del best effort, kubelet concede un periodo di terminazione controllata di 15 secondi per i pod non di sistema, dopodiché i pod di sistema (con le priorityClass system-cluster-critical
o system-node-critical
) hanno 15 secondi per terminare in modo controllato. Durante l'arresto controllato del nodo, kubelet
aggiorna lo stato dei pod e assegna una fase Failed
e un motivo Terminated
ai pod terminati.
La VM si arresta 30 secondi dopo l'invio della notifica di terminazione, anche se
specifichi un valore maggiore di 15 secondi nel campo terminationGracePeriodSeconds
del manifest del pod.
Quando il numero di pod terminati raggiunge una soglia di 1000 per i cluster con meno di 100 nodi o 5000 per i cluster con 100 nodi o più, la garbage collection pulisce i pod.
Puoi anche eliminare manualmente i pod terminati utilizzando i seguenti comandi:
kubectl get pods --all-namespaces | grep -i NodeShutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n
kubectl get pods --all-namespaces | grep -i Terminated | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n
Modifiche al comportamento di Kubernetes
L'utilizzo di VM preemptible su GKE modifica le garanzie fornite da Kubernetes PodDisruptionBudgets
. Il recupero delle VM prerilasciabili
è involontario e non è coperto dalle garanzie di
PodDisruptionBudgets
.
Potresti riscontrare una maggiore indisponibilità rispetto al PodDisruptionBudget
configurato.
Limitazioni
- La funzionalità di arresto controllato dei nodi di Kubelet è abilitata solo nei cluster che eseguono GKE versione 1.20 e successive. Per le versioni di GKE precedenti alla 1.20, puoi utilizzare il gestore eventi di terminazione dei nodi Kubernetes su GCP per terminare normalmente i pod quando le VM prerilasciabili vengono terminate.
- Le VM prerilasciabili non supportano i node pool Windows Server.
- In GKE, non puoi modificare la durata del periodo di tolleranza per
l'arresto dei nodi. I campi di configurazione
shutdownGracePeriod
eshutdownGracePeriodCriticalPods
di kubelet sono immutabili.
Crea un cluster o un pool di nodi con VM preemptible
Puoi utilizzare Google Cloud CLI per creare un cluster o un pool di nodi con VM preemptive.
Per creare un cluster con VM prerilasciabili, esegui questo comando:
gcloud container clusters create CLUSTER_NAME \
--preemptible
Sostituisci CLUSTER_NAME
con il nome del nuovo cluster.
Per creare un pool di nodi con VM prerilasciabili, esegui questo comando:
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--preemptible
Sostituisci POOL_NAME
con il nome del nuovo pool di nodi.
Utilizza nodeSelector per pianificare i pod sulle VM prerilasciabili
GKE aggiunge le etichette cloud.google.com/gke-preemptible=true
e
cloud.google.com/gke-provisioning=preemptible
(per i nodi che eseguono
GKE 1.25.5-gke.2500 o versioni successive) ai nodi che utilizzano
VM preemptive. Puoi utilizzare un nodeSelector
nei tuoi deployment per indicare
a GKE di pianificare i pod sulle VM preemptible.
Ad esempio, i seguenti filtri di deployment per le VM prerilasciabili utilizzano l'etichetta
cloud.google.com/gke-preemptible
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-app
spec:
replicas: 3
selector:
matchLabels:
app: hello-app
template:
metadata:
labels:
app: hello-app
spec:
containers:
- name: hello-app
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
resources:
requests:
cpu: 200m
nodeSelector:
cloud.google.com/gke-preemptible: "true"
Utilizza i taint dei nodi per le VM preemptible
Puoi applicare incompatibilità ai nodi che utilizzano VM prerilasciabili in modo che GKE possa inserire solo i pod con la tolleranza corrispondente su questi nodi.
Per aggiungere un taint del nodo a un pool di nodi che utilizza VM prerilasciabili, utilizza il flag --node-taints
durante la creazione del pool di nodi, in modo simile al seguente comando:
gcloud container node-pools create POOL2_NAME \
--cluster=CLUSTER_NAME \
--node-taints=cloud.google.com/gke-preemptible="true":NoSchedule
Ora, solo i pod che tollerano l'incompatibilità del nodo vengono pianificati sul nodo.
Per aggiungere la tolleranza pertinente ai tuoi pod, modifica i deployment e aggiungi quanto segue alla specifica del pod:
tolerations:
- key: cloud.google.com/gke-preemptible
operator: Equal
value: "true"
effect: NoSchedule
Taint dei nodi per le VM prerilasciabili con GPU
Le VM prerilasciabili supportano l'utilizzo delle GPU. Prima di aggiungere un node pool GPU che utilizza VM preemptible, devi creare almeno un altro node pool nel cluster che non utilizzi VM preemptible. Un pool di nodi standard garantisce che GKE possa posizionare in modo sicuro i componenti di sistema come il DNS.
Se crei un nuovo cluster con pool di nodi GPU che utilizzano VM prerilasciabili o se aggiungi un nuovo pool di nodi GPU che utilizza VM prerilasciabili a un cluster che non ha già un pool di nodi standard, GKE non aggiunge automaticamente il taint nvidia.com/gpu=present:NoSchedule
ai nodi. GKE
potrebbe pianificare i pod di sistema sulle VM prerilasciabili, il che può causare
interruzioni. Questo comportamento aumenta anche il consumo di risorse, perché i nodi GPU
sono più costosi dei nodi non GPU.
Passaggi successivi
- Scopri come eseguire un'applicazione GKE su VM spot con nodi on demand come fallback.
- Scopri di più sulle VM spot in GKE.
- Scopri di più su incompatibilità e tolleranze.