Gestire i sistemi distribuiti può essere complicato a causa del numero elevato di elementi variabili che devono tutti funzionare correttamente per garantire la funzionalità del sistema. Se uno di questi elementi smette di funzionare, il sistema deve poterlo rilevare, aggirarlo e correggerlo, il tutto in modo automatico. In questa serie di "Kubernetes Best Practices" scopriremo come configurare i test di Readiness e Liveness per verificare la vitalità del cluster Kubernetes.
Il controllo dello stato Health Check è un modo semplice per far sapere al sistema se l'istanza della tua applicazione è operativa oppure no. Se l'istanza della tua applicazione non funziona, altrettanto le altre applicazioni non devono fare riferimento a essa o inviarle richieste. Al contrario, la richiesta deve essere inviata a un'altra istanza dell'applicazione che è già in esecuzione o che verrà avviata in seguito. Inoltre, il sistema deve restituire la funzionalità perduta alla tua applicazione.
Per impostazione predefinita, Kubernetes inizia a instradare il traffico verso i pod quando tutti i contenitori all'interno di essi sono avviati e riavvia i contenitori quando si arrestano in modo anomalo. All'inizio, questo comportamento predefinito del sistema può essere adeguato, tuttavia, puoi migliorare l'affidabilità del deployment del tuo prodotto utilizzando controlli di integrità personalizzati.
Fortunatamente, Kubernetes rende questo piuttosto semplice, quindi non ci sono scusanti per ignorare tali controlli. Kubernetes offre due tipi di test di Health Check, ed è importante comprendere le differenze nell'applicazione di ciascuno di essi.
Il test di disponibilità Readiness è progettato per informare Kubernetes sulla prontezza della tua applicazione a gestire il traffico. Prima di consentire al servizio di indirizzare il traffico verso un pod, Kubernetes deve assicurarsi che il test di disponibilità abbia avuto esito positivo. Se il test Readiness fallisce, Kubernetes smetterà di indirizzare il traffico verso il pod finché il test non avrà esito positivo.
Il test di liveness informa Kubernetes se la tua applicazione è viva o morta. Nel primo caso, Kubernetes la ignorerà, mentre nel secondo eliminerà il pod morto e lo sostituirà con uno nuovo.
Immagina uno scenario in cui la tua applicazione richiede 1 minuto per il 'riscaldamento' e l'avvio. Il tuo servizio non inizierà a funzionare fino a quando l'applicazione non sarà completamente caricata e avviata, anche se il flusso di lavoro è già iniziato. Inoltre, avrai problemi se desideri scalare questo deployment a più repliche, poiché queste repliche non dovrebbero ricevere traffico fino a quando non saranno completamente pronte. Tuttavia, per impostazione predefinita, Kubernetes inizierà a inviare traffico non appena i processi all'interno del contenitore iniziano.
Utilizzando il test di prontezza Readiness, Kubernetes attenderà che l'applicazione sia completamente avviata e solo dopo consentirà al servizio di inviare traffico alla nuova copia.
Immaginiamo un altro scenario in cui l'applicazione si blocca per lungo tempo, smettendo di rispondere alle richieste. Poiché il processo continua a essere eseguito, per impostazione predefinita Kubernetes considererà che tutto vada bene e continuerà a inviare richieste al pod non funzionante. Ma utilizzando Liveness, Kubernetes rileverà che l'applicazione non sta più rispondendo alle richieste e per impostazione predefinita riavvierà il pod non funzionante.
Esaminiamo i metodi utilizzati per testare la prontezza e la vitalità. Ci sono tre metodi di test: HTTP, Command e TCP. Puoi utilizzare cualquiera di essi per la verifica. Il metodo di test più comune è il probe HTTP.
Anche se la tua applicazione non è un server HTTP, puoi comunque creare un leggero server HTTP all'interno della tua applicazione per interagire con il test di Liveness. Dopo di che, Kubernetes inizierà a pingare il pod e se la risposta HTTP si trova nell'intervallo di 200 o 300 ms, ciò indicherà che il pod è "sano". In caso contrario, il modulo sarà contrassegnato come "malato".
Per i test, Kubernetes esegue il comando all'interno del tuo container. Se il comando restituisce un codice di uscita pari a zero, il container sarà contrassegnato come sano; in caso contrario, con un numero di stato di uscita da 1 a 255, il container sarà considerato "malato". Questo metodo di test è utile se non puoi o non vuoi avviare un server HTTP, ma puoi eseguire un comando che verifichi la "salute" della tua applicazione.
L'ultimo meccanismo di verifica è il test TCP. Kubernetes cercherà di stabilire una connessione TCP sulla porta specificata. Se ciò riesce, il container viene considerato sano; in caso contrario, non vitale. Questo metodo può tornare utile se utilizzi uno scenario in cui i test tramite richiesta HTTP o l'esecuzione di comandi non funzionano molto bene. Ad esempio, i principali servizi di verifica tramite TCP saranno gRPC o FTP.
I test possono essere configurati in vari modi con diverse impostazioni. Puoi specificare con quale frequenza devono essere eseguiti, quali sono le soglie di successo e fallimento e quanto tempo attendere le risposte. Maggiori dettagli sono forniti nella documentazione sui test di Readiness e Liveness. Tuttavia, c'è un aspetto molto importante nella configurazione del test di Liveness: l'impostazione iniziale del ritardo nel test, initialDelaySeconds. Come ho accennato, un esito negativo di questo test porterà al riavvio del modulo. Pertanto, devi assicurarti che il test non inizi finché l'applicazione non è pronta per funzionare, altrimenti inizierà a riavviarsi in ciclo. Ti consiglio di utilizzare il tempo di avvio P99 o il tempo medio di avvio dell'applicazione dal buffer. Non dimenticare di regolare questo valore man mano che il tempo di avvio della tua applicazione diventa più veloce o più lento.
La maggior parte degli specialisti conferma che il Health Check è un controllo essenziale per qualsiasi sistema distribuito, e Kubernetes non fa eccezione. Utilizzare il controllo della "salute" dei servizi garantisce il funzionamento affidabile e senza interruzioni di Kubernetes e non comporta alcuno sforzo per gli utenti.
Continuazione in arrivo molto presto…
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
