Un aspetto importante nel lavoro 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ò fermare forzatamente le tue applicazioni per garantire la salute complessiva del sistema. In questa serie, esamineremo come aiutare Kubernetes a svolgere il suo lavoro in modo più efficiente e ridurre il tempo di inattività delle applicazioni.
Prima dell'implementazione dei contenitori, la maggior parte delle applicazioni funzionava su macchine virtuali o fisiche. Se un'applicazione andava in crash o si bloccava, ci volevano molto tempo per interrompere il compito in esecuzione e ricaricare il programma. Nel peggiore dei casi, a qualcuno toccava risolvere manualmente il problema nella notte, nel momento meno opportuno. Se un compito importante era eseguito da sole 1-2 macchine, tale guasto era del tutto inaccettabile.
Pertanto, invece di un riavvio manuale, si è iniziato a utilizzare il monitoraggio a livello di processo per il riavvio automatico delle applicazioni in caso di chiusura anomala. Se un programma andava in crash, il processo di monitoraggio acquisiva il codice di uscita e riavviava il server. Con l'emergere di sistemi come Kubernetes, questo tipo di risposta ai guasti è stato semplicemente integrato nell'infrastruttura.
Kubernetes utilizza un ciclo di eventi "osservazione - registrazione delle discrepanze - azione" per assicurarsi che le risorse rimangano operative durante il passaggio dai contenitori ai nodi stessi.
Ciò significa che non è più necessario avviare manualmente il monitoraggio dei processi. Se una risorsa non supera il controllo di salute, Kubernetes le fornirà automaticamente una sostituzione. Inoltre, Kubernetes fa molto di più che semplicemente monitorare i guasti delle tue applicazioni. Può creare più copie dell'applicazione per funzionare su più macchine, aggiornare l'applicazione o eseguire simultaneamente diverse versioni della tua applicazione.
Esistono quindi molteplici motivi per cui Kubernetes può interrompere un contenitore perfettamente funzionante. Ad esempio, se stai aggiornando il tuo deployment, Kubernetes interromperà lentamente i vecchi pod, avviando nel contempo quelli nuovi. Se disattivi un nodo, Kubernetes fermerà tutti i pod in quel nodo. Infine, se un nodo esaurisce le risorse, Kubernetes disabiliterà tutti i pod per liberare quelle risorse.
È quindi molto importante che la tua applicazione si spenga con il minimo impatto sugli utenti finali e con il minor tempo di recupero possibile. Ciò significa che prima di disattivarsi, deve salvare tutti i dati necessari, chiudere tutte le connessioni di rete, completare eventuali attività in sospeso e avere il tempo di eseguire altre task urgenti.
In pratica, questo 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 nei sistemi operativi Unix. Ricevendo questo messaggio, l'applicazione deve disattivarsi.
Una volta che Kubernetes decide di terminare un pod, si verifica una serie di eventi. Analizziamo ogni passaggio che Kubernetes compie nel momento in cui termina il lavoro di un contenitore o di un pod.
Supponiamo di voler chiudere uno dei pod. In quel momento, smetterà di ricevere nuovo traffico – i contenitori in esecuzione nel pod non saranno interessati, ma tutto il nuovo traffico sarà bloccato.
Esaminiamo il hook preStop — è un comando speciale o una richiesta HTTP che viene inviata ai contenitori nel pod. Se la tua applicazione non si spegne correttamente alla ricezione di SIGTERM, puoi utilizzare preStop per assicurarti una corretta chiusura.
La maggior parte delle applicazioni, alla ricezione del segnale SIGTERM, si chiudono in modo appropriato, ma se utilizzi codice di terze parti o un sistema che non puoi controllare completamente, il hook preStop è un ottimo modo per invocare uno spegnimento elegante senza modificare l'applicazione.
Dopo l'esecuzione di questo hook, Kubernetes invierà un segnale SIGTERM ai container nel pod, informandoli che saranno presto disattivati. Ricevendo questo segnale, il tuo codice passerà alla fase di disattivazione. Questo processo può includere la chiusura di qualsiasi connessione a lungo termine, come quella a un database o a un flusso WebSocket, il salvataggio dello stato corrente e simili.
Anche se utilizzi un hook preStop, è molto importante controllare cosa sta succedendo con la tua applicazione quando le viene inviato un segnale SIGTERM, come si comporta, affinché 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, o periodo di disattivazione corretto alla ricezione del segnale SIGTERM.
Per impostazione predefinita, questo periodo è di 30 secondi. È importante notare che si svolge in parallelo con l'hook preStop e il segnale SIGTERM. Kubernetes non attenderà che l'hook preStop e il segnale SIGTERM siano completati: se la tua applicazione termina prima della scadenza del periodo di TerminationGracePeriod, Kubernetes passerà immediatamente al passaggio successivo. Pertanto, assicurati che il valore di questo periodo in secondi non sia inferiore al tempo necessario per una corretta disattivazione del pod e, se supera i 30 secondi, aumenta il periodo fino al valore necessario nel YAML. Nell'esempio fornito è di 60 secondi.
E infine, l'ultimo passo: se i container continuano a funzionare dopo la scadenza del terminationGracePeriod, invieranno un segnale SIGKILL e saranno forzatamente rimossi. A questo punto, Kubernetes pulirà anche tutti gli altri oggetti del pod.
Kubernetes interrompe il funzionamento dei pod per molte ragioni, quindi assicurati che in ogni caso la tua applicazione venga terminata correttamente per garantire un servizio stabile.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono 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! Leggi di
Fonte: habr.com
