Un aspetto fondamentale nel funzionamento dei sistemi distribuiti è la gestione dei guasti. Kubernetes aiuta in questo, utilizzando controller che monitorano lo stato del tuo sistema e riavviano i servizi che hanno smesso di funzionare. Tuttavia, Kubernetes può forzare l'arresto delle tue applicazioni per garantire la sostenibilità complessiva del sistema. In questa serie esamineremo come aiutare Kubernetes a svolgere il suo lavoro in modo più efficace e ridurre i tempi di inattività delle applicazioni.
Prima dell'adozione dei contenitori, la maggior parte delle applicazioni funzionava su macchine virtuali o fisiche. Se un'applicazione si bloccava o andava in crash, ci voleva molto tempo per interrompere il compito in esecuzione e ricaricare il programma. Nel peggiore dei casi, qualcuno doveva affrontare questo problema manualmente di notte, nel momento meno opportuno. Se un compito critico era svolto da sole 1-2 macchine operative, un simile guasto era del tutto inaccettabile.
Pertanto, anziché effettuare riavvii manuali, si è iniziato a utilizzare un monitoraggio a livello di processo per riavviare automaticamente l'applicazione in caso di arresto anomalo. Se il programma si blocca, il processo di monitoraggio cattura il codice di uscita e riavvia il server. Con l'emergere di sistemi come Kubernetes, questo tipo di risposta ai guasti di sistema è stato semplicemente integrato nell'infrastruttura.
Kubernetes utilizza un ciclo di eventi "osservazione - registrazione delle differenze - azione" per garantire che le risorse mantengano la loro operatività lungo il percorso dai container ai nodi stessi.
Questo significa che non è più necessario avviare manualmente il monitoraggio dei processi. Se una risorsa non supera il controllo di integrità, Kubernetes provvede automaticamente a fornirle una sostituzione. Allo stesso tempo, Kubernetes fa molto più che monitorare i guasti delle tue applicazioni. Può creare copie aggiuntive dell'applicazione per essere eseguite su più macchine, aggiornare l'applicazione oppure eseguire contemporaneamente più versioni della tua applicazione.
Ci sono molte ragioni per cui Kubernetes può interrompere un contenitore perfettamente sano. Ad esempio, quando si aggiorna il proprio deployment, Kubernetes fermerà lentamente i vecchi pod mentre avvia nuovi pod. Se si disattiva un nodo, Kubernetes interromperà tutti i pod in quel nodo. Infine, se un nodo esaurisce le risorse, Kubernetes disabiliterà tutti i pod per liberare tali risorse.
È quindi fondamentale che la tua applicazione si spenga con un impatto minimo sugli utenti finali e con un tempo di recupero ridotto. Ciò significa che prima di spegnersi deve salvare tutti i dati necessari, chiudere tutte le connessioni di rete, completare il lavoro rimanente e gestire eventuali 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 il comando kill nei sistemi operativi Unix. Una volta ricevuto questo messaggio, l'applicazione deve spegnersi.
Dopo che Kubernetes ha deciso di terminare un pod, si innesca una serie di eventi. Esaminiamo ogni passaggio che Kubernetes esegue durante la chiusura di un contenitore o di un pod.
Immaginiamo di voler terminare uno dei pod. A questo punto, smetterà di ricevere nuovo traffico: i contenitori attivi nel pod non saranno interessati, ma tutto il nuovo traffico verrà bloccato.
Analizziamo il hook preStop: si tratta di un comando speciale o di una richiesta HTTP inviata ai contenitori nel pod. Se la tua applicazione non si spegne correttamente alla ricezione di SIGTERM, puoi utilizzare preStop per gestire correttamente la chiusura.
La maggior parte dei programmi termina correttamente alla ricezione del segnale SIGTERM, ma se stai usando codice di terze parti o un sistema che non puoi controllare completamente, il hook preStop è un ottimo modo per innescare una chiusura elegante senza modificare l'applicazione.
Dopo l'esecuzione di questo hook, Kubernetes invierà ai contenitori nel pod un segnale SIGTERM, il quale li avviserà che saranno disattivati a breve. Ricevendo questo segnale, il tuo codice passerà alla fase di spegnimento. Questo processo può includere la chiusura di eventuali connessioni a lungo termine, come connessioni al database o flussi WebSocket, il salvataggio dello stato attuale e simili.
Anche se utilizzi l'hook preStop, è molto importante verificare cosa succede alla tua applicazione quando le invii il segnale SIGTERM, come si comporta, in modo che eventi o cambiamenti nel funzionamento del sistema causati dalla disattivazione del pod non ti colgano di sorpresa.
A questo punto, prima di intraprendere ulteriori azioni, Kubernetes attenderà per il tempo specificato, chiamato terminationGracePeriodSecond, ovvero il periodo di rilascio per una disattivazione corretta alla ricezione del segnale SIGTERM.
Per impostazione predefinita, questo periodo è di 30 secondi. È importante notare che dura parallelamente al preStop hook e al segnale SIGTERM. Kubernetes non aspetterà che il preStop hook e SIGTERM siano completati: se la tua applicazione si arresta prima della fine del periodo di TerminationGracePeriod, Kubernetes passerà immediatamente al passaggio successivo. Assicurati quindi che il valore di questo periodo in secondi sia almeno pari al tempo necessario per arrestare correttamente il pod e, se supera i 30 secondi, aumenta il periodo all’entità necessaria nel YAML. Nell'esempio fornito, è di 60 secondi.
E infine, l'ultimo passaggio: se i container continuano a funzionare dopo il termine del terminationGracePeriod, verrà inviato il segnale SIGKILL e verranno forzatamente rimossi. In questo momento, Kubernetes pulirà anche tutti gli altri oggetti del pod.
Kubernetes interrompe i pod per molti motivi, quindi assicurati che la tua applicazione venga sempre arrestata correttamente per garantire un funzionamento stabile del servizio.
Un po' di pubblicità 🙂
Grazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, , un'alternativa unica ai server entry-level, che abbiamo creato per te: (disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Scopri di più su
Fonte: habr.com
