🥇Aggiornamento del cluster Kubernetes senza inattività

Il processo di aggiornamento per il tuo cluster Kubernetes

In qualche momento durante l'utilizzo del cluster Kubernetes, sorge la necessità di aggiornare i nodi in esecuzione. Questo può includere aggiornamenti dei pacchetti, aggiornamento del kernel o distribuzione di nuove immagini delle macchine virtuali. Nella terminologia di Kubernetes, questo viene chiamato "Interruzione Volontaria".

Questo post fa parte di un ciclo di 4 post:

Questo post.
Terminazione corretta dei pod nel cluster Kubernetes
Terminazione posticipata del pod durante la sua rimozione
Come evitare tempi di inattività nel funzionamento del cluster Kubernetes utilizzando i PodDisruptionBudgets

(nota del traduttore: le traduzioni degli altri articoli del ciclo arriveranno a breve)

In questo articolo descriveremo tutti gli strumenti forniti da Kubernetes per raggiungere zero tempi di inattività per i nodi in esecuzione nel tuo cluster.

Definizione del problema

Inizialmente adotteremo un approccio naïf, definendo i problemi e valutando i rischi potenziali di tale approccio, accumulando conoscenze per risolvere ciascuno dei problemi che incontreremo lungo il ciclo. Di conseguenza, otterremo una configurazione che usa lifecycle hooks, readiness probes e Pod disruption budgets per ottenere il nostro tempo di inattività nullo.

Per iniziare il nostro percorso, prendiamo un esempio concreto. Supponiamo di avere un cluster Kubernetes composto da due nodi, in cui è in esecuzione un'applicazione con due pod, situati dietro Servizio:

Iniziamo con due pod con Nginx e un servizio in esecuzione sui nostri due nodi del cluster Kubernetes.

Vogliamo aggiornare la versione del kernel di due nodi operativi nel nostro cluster. Come lo faremo? Una soluzione semplice sarebbe avviare nuovi nodi con una configurazione aggiornata e poi spegnere i nodi vecchi, mentre avviamo i nuovi. Anche se questo funzionerà, ci saranno alcuni problemi con questo approccio:

Quando spegnerai i nodi vecchi, i pod in esecuzione su di essi verranno anch'essi spenti. E se i pod devono essere puliti per una disconnessione corretta? Il sistema di virtualizzazione che stai utilizzando potrebbe non attendere la fine del processo di pulizia.
E se spegni tutti i nodi contemporaneamente? Otterrai un notevole tempo di inattività mentre i pod si trasferiranno sui nuovi nodi.

Abbiamo bisogno di un modo per migrare correttamente i pod dalle vecchie nodi e dobbiamo assicurarci che nessuno dei nostri processi di lavoro sia attivo mentre apportiamo modifiche alla nodo. Oppure quando facciamo una sostituzione completa del cluster, come nell'esempio (cioè sostituendo le immagini VM), vogliamo trasferire le applicazioni funzionanti dalle vecchie nodi a quelle nuove. In entrambi i casi, vogliamo evitare di pianificare nuovi pod sulle vecchie nodi e poi espellere tutti i pod attivi da esse. Per raggiungere questi obiettivi possiamo usare il comando kubectl drain.

Ridistribuzione di tutti i pod dalla nodo

L'operazione di drain consente di ridistribuire tutti i pod dalla nodo. Durante l'esecuzione del drain, la nodo viene contrassegnata come unschedulable (flag NoSchedule). Questo impedisce la creazione di nuovi pod su di essa. Successivamente, il drain inizia ad espellere i pod dalla nodo, terminando i contenitori attualmente attivi sulla nodo inviando un segnale TERM ai contenitori nel pod.

Sebbene kubectl drain ben si occupa dell'espulsione dei pod, ci sono anche due fattori che possono causare un fallimento nell'esecuzione dell'operazione di drain:

La tua applicazione deve essere in grado di terminare correttamente al ricevimento TERM del segnale. Quando i pod vengono espulsi, Kubernetes invia un segnale TERM ai contenitori e attende che si fermino per un tempo predefinito, dopo di che, se non si sono fermati, li termina forzatamente. In ogni caso, se il tuo contenitore non risponde correttamente al segnale, potresti comunque arrestare i pod in modo non corretto, se sono attivi in quel momento specifico (ad esempio, se è in corso una transazione nel database).
Perdi tutti i pod che contengono la tua applicazione. Potrebbe non essere disponibile al momento dell'avvio di nuovi contenitori sulle nuove nodi o, se i tuoi pod sono distribuiti senza controllori, potrebbero non riavviarsi affatto.

Evitare i tempi di inattività

Per minimizzare il tempo di inattività da disruption volontaria, come ad esempio dall'operazione di drain per la nodo, Kubernetes offre le seguenti opzioni per la gestione dei guasti:

Nelle altre parti del ciclo utilizzeremo queste funzioni di Kubernetes per mitigare le conseguenze del trasferimento dei pod. Per facilitare il tracciamento dell'idea principale, utilizzeremo il nostro esempio sopra con la seguente configurazione delle risorse:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Questa configurazione rappresenta un esempio minimo Deployment, che gestisce i pod nginx nel cluster. Inoltre, la configurazione descrive una risorsa Servizio, che può essere utilizzata per accedere ai pod nginx nel cluster.

Durante tutto il ciclo, espanderemo iterativamente questa configurazione, affinché alla fine includa tutte le funzionalità offerte da Kubernetes per ridurre i tempi di inattività.

Per ottenere una versione completamente integrata e testata degli aggiornamenti del cluster Kubernetes per un tempo di inattività nullo su AWS e altre risorse, visita Gruntwork.io.

Aggiornamento del cluster Kubernetes senza downtime

Definizione del problema

Ridistribuzione di tutti i pod dalla nodo

Evitare i tempi di inattività

Leggi anche altri articoli nel nostro blog: