Processo di aggiornamento per il tuo cluster Kubernetes
Ad un certo punto, quando si utilizza un cluster Kubernetes, è necessario aggiornare i nodi in esecuzione. Ciò può includere aggiornamenti dei pacchetti, aggiornamenti del kernel o distribuzione di nuove immagini di macchine virtuali. Nella terminologia Kubernetes questo si chiama .
Questo post fa parte di una serie di 4 post:
- Questo post.
- Arresto corretto dei pod in un cluster Kubernetes
- Terminazione ritardata di un pod quando viene eliminato
- Come evitare i tempi di inattività del cluster Kubernetes utilizzando PodDisruptionBudgets
(circa. Aspettatevi le traduzioni dei restanti articoli della serie nel prossimo futuro)
In questo articolo descriveremo tutti gli strumenti forniti da Kubernetes per ottenere tempi di inattività pari a zero per i nodi in esecuzione nel tuo cluster.
Definizione del problema
Inizialmente adotteremo un approccio ingenuo, identificheremo i problemi e valuteremo i potenziali rischi di questo approccio e svilupperemo le conoscenze per risolvere ciascuno dei problemi che incontriamo durante il ciclo. Il risultato è una configurazione che utilizza hook del ciclo di vita, sonde di disponibilità e budget per l'interruzione dei pod per raggiungere il nostro obiettivo di tempi di inattività pari a zero.
Per iniziare il nostro viaggio, facciamo un esempio concreto. Supponiamo di avere un cluster Kubernetes di due nodi, in cui un'applicazione è in esecuzione con due pod posizionati dietro Service:
Iniziamo con due pod con Nginx e Service in esecuzione sui nostri due nodi del cluster Kubernetes.
Vogliamo aggiornare la versione del kernel di due nodi di lavoro nel nostro cluster. Come facciamo questo? Una soluzione semplice sarebbe avviare nuovi nodi con la configurazione aggiornata e quindi spegnere i vecchi nodi mentre si avviano quelli nuovi. Anche se funzionerà, ci saranno alcuni problemi con questo approccio:
- Quando disattivi i vecchi nodi, verranno disattivati anche i pod in esecuzione su di essi. Cosa succede se i pod devono essere cancellati per uno spegnimento regolare? Il sistema di virtualizzazione in uso potrebbe non attendere il completamento del processo di pulizia.
- Cosa succede se spegni tutti i nodi contemporaneamente? Otterrai tempi di inattività decenti mentre i pod si spostano su nuovi nodi.
Abbiamo bisogno di un modo per migrare con garbo i pod dai vecchi nodi garantendo al tempo stesso che nessuno dei nostri processi di lavoro sia in esecuzione mentre apportiamo modifiche al nodo. Oppure quando eseguiamo una sostituzione completa del cluster, come nell'esempio (ovvero sostituiamo le immagini della VM), vogliamo trasferire le applicazioni in esecuzione dai vecchi nodi a quelli nuovi. In entrambi i casi, vogliamo impedire che i nuovi pod vengano pianificati sui vecchi nodi e quindi eliminare da essi tutti i pod in esecuzione. Per raggiungere questi obiettivi possiamo utilizzare il comando kubectl drain.
Ridistribuzione di tutti i pod da un nodo
L'operazione di drenaggio consente di ridistribuire tutti i pod da un nodo. Durante l'esecuzione del drain, il nodo viene contrassegnato come non pianificabile (flag NoSchedule). Ciò impedisce la visualizzazione di nuovi pod su di esso. Quindi il drenaggio inizia a sfrattare i pod dal nodo, spegne i contenitori attualmente in esecuzione sul nodo, inviando un segnale TERM contenitori in un baccello.
Sebbene kubectl drain farà un ottimo lavoro nell'eliminare i pod, ci sono altri due fattori che possono causare il fallimento dell'operazione di scarico:
- La tua domanda deve essere in grado di terminare correttamente al momento dell'invio
TERMsegnale. Quando i pod vengono sfrattati, Kubernetes invia un segnaleTERMcontenitori e attende che si fermino per un determinato periodo di tempo, trascorso il quale, se non si sono fermati, li chiude forzatamente. In ogni caso, se il tuo contenitore non percepisce correttamente il segnale, puoi comunque spegnere erroneamente i pod se sono attualmente in esecuzione (ad esempio, è in corso una transazione sul database). - Perderai tutti i pod che contengono la tua applicazione. Potrebbe non essere disponibile quando nuovi contenitori vengono avviati su nuovi nodi oppure, se i tuoi pod vengono distribuiti senza controller, potrebbero non riavviarsi affatto.
Evitare i tempi di inattività
Per ridurre al minimo i tempi di inattività dovuti a interruzioni volontarie, ad esempio da un'operazione di drenaggio su un nodo, Kubernetes fornisce le seguenti opzioni di gestione degli errori:
Nel resto della serie utilizzeremo queste funzionalità Kubernetes per mitigare l'impatto della migrazione dei pod. Per rendere più semplice seguire l'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: 80Questa configurazione è un esempio minimo Deployment, che gestisce i pod nginx nel cluster. Inoltre, la configurazione descrive la risorsa Service, che può essere utilizzato per accedere ai pod nginx in un cluster.
Durante tutto il ciclo, espanderemo in modo iterativo questa configurazione in modo che alla fine includa tutte le funzionalità fornite da Kubernetes per ridurre i tempi di inattività.
Per una versione completamente implementata e testata degli aggiornamenti del cluster Kubernetes per zero tempi di inattività su AWS e oltre, visita .
Leggi anche altri articoli sul nostro blog:
Fonte: habr.com