Arresto dei nodi gestiti in GKE su Azure

A partire dalla versione 1.26, GKE su Azure abilita automaticamente l'arresto dei nodi gestiti. Questa funzionalità gestisce la terminazione controllata dei pod durante gli arresti dei nodi. La terminazione gestita consente ai pod di salvare il proprio stato e rilasciare risorse prima dell'arresto del nodo. Questo metodo di arresto dei pod riduce al minimo il rischio di perdita di dati. Inoltre, riduce al minimo il rischio di interruzioni di altri pod e servizi che dipendono o interagiscono con i pod in fase di arresto, migliorando così la resilienza dei tuoi cluster.

Come funziona

Un evento come la manutenzione pianificata, la scalabilità dei nodi o un problema di hardware attiva l'arresto di un nodo. Il componente kubelet rileva l'evento e avvia il processo di terminazione controllata del nodo indicando a systemd di ritardare l'arresto del sistema per un periodo di tempo specificato. Questo ritardo concede al nodo il tempo di svuotare ed eliminare i pod in esecuzione.

L'obiettivo della terminazione controllata dei nodi è terminare in modo controllato i pod di sistema non di sistema e critici prima dell'arresto del nodo. Vengono utilizzate le seguenti impostazioni predefinite:

• ShutdownGracePeriod: 30 secondi
• ShutdownGracePeriodCriticalPods: 15 secondi

Queste impostazioni concedere ai pod non di sistema 15 secondi per arrestarsi in modo controllato prima di essere arrestati forzatamente. I pod di sistema critici hanno 15 secondi di tempo per arrestarsi dopo l'arresto dei pod non di sistema. Tuttavia, poiché la funzionalità opera secondo il criterio del "best effort", è possibile che un nodo non riesca ad arrestarsi automaticamente entro il periodo di 30 secondi specificato.

Attivatori e limitazioni

Gli eventi che attivano l'arresto controllato dei nodi includono quelli pianificati come i seguenti:

• Arresti anomali controllati dall'utente
• Chiusura delle istanze
• Manutenzione pianificata
• Fare lo scale down di un cluster

In questi scenari, l'oggetto kubelet rileva l'evento di arresto del nodo e avvia il processo di arresto controllato del nodo.

Al contrario, l'arresto controllato del nodo non può essere attivato quando il comando di chiusura non attiva il meccanismo di blocco dell'inibitore systemd su cui fa affidamento il componente kubelet. Ecco alcuni esempi di questo tipo di situazioni:

• Disconnessioni di rete
• Malfunzionamenti hardware
• Risorse insufficienti come memoria o CPU
• Interruzioni di corrente impreviste.

In questi casi, il nodo potrebbe arrestarsi improvvisamente, causando potenzialmente interruzioni o perdita di dati.