Un punto importante nel funzionamento dei sistemi distribuiti è la gestione dei guasti. Kubernetes aiuta in questo utilizzando controller che monitorano lo stato del sistema e riavviano i servizi che hanno smesso di funzionare. Tuttavia, Kubernetes può interrompere forzatamente le tue applicazioni per garantire l'integrità generale del sistema. In questa serie vedremo come puoi aiutare Kubernetes a svolgere il suo lavoro in modo più efficiente e a ridurre i tempi di inattività delle applicazioni.
Prima dei contenitori, la maggior parte delle applicazioni veniva eseguita su macchine virtuali o fisiche. Se l'applicazione si bloccava o si bloccava, occorreva molto tempo per annullare l'attività in corso e ricaricare il programma. Nel peggiore dei casi, qualcuno ha dovuto risolvere manualmente il problema di notte, nelle ore meno opportune. Se solo 1-2 macchine funzionanti svolgessero un compito importante, tale interruzione sarebbe del tutto inaccettabile.
Pertanto, invece dei riavvii manuali, hanno iniziato a utilizzare il monitoraggio a livello di processo per riavviare automaticamente l'applicazione in caso di chiusura anomala. Se il programma fallisce, il processo di monitoraggio acquisisce il codice di uscita e riavvia il server. Con l’avvento di sistemi come Kubernetes, questo tipo di risposta ai guasti del sistema è stato semplicemente integrato nell’infrastruttura.
Kubernetes utilizza un ciclo di eventi osserva-differenza-agisci per garantire che le risorse rimangano integre mentre viaggiano dai container ai nodi stessi.
Ciò significa che non è più necessario eseguire manualmente il monitoraggio del processo. Se una risorsa non supera il controllo dello stato, Kubernetes le fornirà semplicemente automaticamente una sostituzione. Tuttavia, Kubernetes fa molto di più che monitorare semplicemente la tua applicazione per individuare eventuali errori. Può creare più copie dell'applicazione da eseguire su più macchine, aggiornare l'applicazione o eseguire più versioni dell'applicazione contemporaneamente.
Pertanto, ci sono molte ragioni per cui Kubernetes può terminare un contenitore perfettamente integro. Ad esempio, se aggiorni la tua distribuzione, Kubernetes arresterà lentamente i vecchi pod mentre ne avvierà di nuovi. Se spegni un nodo, Kubernetes interromperà l'esecuzione di tutti i pod su quel nodo. Infine, se un nodo esaurisce le risorse, Kubernetes spegnerà tutti i pod per liberare tali risorse.
Pertanto, è fondamentale che l'applicazione venga terminata con un impatto minimo sull'utente finale e tempi di ripristino minimi. Ciò significa che prima di spegnersi, deve salvare tutti i dati che devono essere salvati, chiudere tutte le connessioni di rete, completare il lavoro rimanente e gestire altre attività urgenti.
In pratica, ciò significa che la tua applicazione deve essere in grado di gestire il messaggio SIGTERM, il segnale di terminazione del processo che è il segnale predefinito per l'utilità kill sui sistemi operativi Unix. Dopo aver ricevuto questo messaggio, l'applicazione dovrebbe chiudersi.
Una volta che Kubernetes decide di terminare un pod, si verificano una serie di eventi. Diamo un'occhiata a ogni passaggio eseguito da Kubernetes quando si spegne un container o un pod.
Diciamo che vogliamo terminare uno dei pod. A questo punto, smetterà di ricevere nuovo traffico: i contenitori in esecuzione nel pod non saranno interessati, ma tutto il nuovo traffico verrà bloccato.
Diamo un'occhiata all'hook preStop, che è un comando speciale o una richiesta HTTP inviata ai contenitori in un pod. Se la tua applicazione non si chiude correttamente quando ricevi SIGTERM, puoi utilizzare preStop per spegnerla correttamente.
La maggior parte dei programmi si chiuderà correttamente quando ricevono un segnale SIGTERM, ma se stai utilizzando codice di terze parti o un sistema che non controlli completamente, l'hook preStop è un ottimo modo per forzare un arresto regolare senza modificare l'applicazione.
Dopo aver eseguito questo hook, Kubernetes invierà un segnale SIGTERM ai container nel pod, informandoli che presto verranno disconnessi. Dopo aver ricevuto questo segnale, il tuo codice procederà al processo di spegnimento. Questo processo può includere l'interruzione di qualsiasi connessione di lunga durata come una connessione al database o un flusso WebSocket, il salvataggio dello stato corrente e simili.
Anche se utilizzi un hook preStop, è molto importante verificare cosa succede esattamente alla tua applicazione quando le invii un segnale SIGTERM, e come si comporta, in modo che eventi o cambiamenti nel funzionamento del sistema causati da uno spegnimento del pod non si verifichino come una sorpresa per te.
A questo punto, Kubernetes attenderà un periodo di tempo specificato, chiamato terminationGracePeriodSecond, o il periodo necessario per arrestarsi normalmente quando riceve un segnale SIGTERM, prima di intraprendere ulteriori azioni.
Per impostazione predefinita questo periodo è di 30 secondi. È importante notare che funziona in parallelo con il gancio preStop e il segnale SIGTERM. Kubernetes non attenderà la fine dell'hook preStop e del SIGTERM: se l'applicazione termina prima del termine del TerminationGracePeriod, Kubernetes passerà immediatamente alla fase successiva. Verifica quindi che il valore di questo periodo in secondi non sia inferiore al tempo necessario per spegnere correttamente il pod e, se supera i 30 s, aumenta il periodo fino al valore desiderato in YAML. Nell'esempio fornito, sono gli anni '60.
Infine, l'ultimo passaggio è che se i contenitori sono ancora in esecuzione dopo la terminazioneGracePeriod, invieranno un segnale SIGKILL e verranno eliminati forzatamente. A questo punto, Kubernetes ripulirà anche tutti gli altri oggetti pod.
Kubernetes termina i pod per molti motivi, quindi assicurati che la tua applicazione venga terminata correttamente in ogni caso per garantire un servizio stabile.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com