Gestire i sistemi distribuiti può essere difficile a causa della presenza di numerosi elementi variabili e modificabili, tutti i quali devono funzionare correttamente per garantire la funzionalità del sistema. Se uno degli elementi fallisce, il sistema deve rilevarlo, aggirarlo e correggerlo, e tutto ciò deve avvenire automaticamente. In questa serie di "Kubernetes Best Practices", scopriremo come configurare i test di Readiness e Liveness per verificare la vitalità di un cluster Kubernetes.
Il controllo di salute Health Check è un modo semplice per informare il sistema se l'istanza della tua applicazione sta funzionando o meno. Se l'istanza della tua applicazione non è attiva, altri servizi non devono accedervi o inviare richieste. Invece, la richiesta deve essere inviata a un'altra istanza dell'applicazione che è già attiva o che verrà avviata in seguito. Inoltre, il sistema deve restituire la funzionalità persa alla tua applicazione.
Per impostazione predefinita, Kubernetes inizierà a inviare traffico al pod quando tutti i contenitori all'interno di esso sono attivi e riavvierà i contenitori quando si arrestano in modo anomalo. All’inizio, questo comportamento predefinito può essere sufficientemente buono, tuttavia puoi migliorare l'affidabilità del dispiegamento del tuo prodotto utilizzando controlli di salute personalizzati.
Fortunatamente, Kubernetes consente di eseguire questa operazione in modo piuttosto semplice, quindi non ci sono scuse 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 prontezza Readiness serve a informare Kubernetes se la tua applicazione è pronta a gestire il traffico. Prima di permettere al servizio di inviare traffico al pod, Kubernetes deve assicurarsi che il controllo di prontezza sia stato superato con successo. Se il test di Readiness fallisce, Kubernetes smetterà di inviare traffico al pod fino a quando il test non avrà esito positivo.
Il test di vitalità Liveness informa Kubernetes se la tua applicazione è viva o morta. Nel primo caso, Kubernetes la lascerà in pace; nel secondo, rimuoverà il pod morto e lo sostituirà con uno nuovo.
Immaginiamo uno scenario in cui la tua applicazione richiede 1 minuto per avviarsi e caricarsi. Il tuo servizio non inizierà a funzionare finché l'applicazione non è completamente avviata, anche se il flusso di lavoro è già iniziato. Avrai anche problemi se desideri scalare questa distribuzione a più istanze, poiché tali istanze non dovrebbero ricevere traffico fino a quando non sono completamente pronte. Tuttavia, di default Kubernetes inizierà a instradare il traffico non appena i processi all'interno del contenitore iniziano.
Utilizzando il test di prontezza Readiness, Kubernetes aspetterà fino a quando l'applicazione non sarà completamente avviata e solo dopo consentirà al servizio di inviare traffico alla nuova istanza.
Immaginiamo un altro scenario in cui l'applicazione si blocca per un lungo periodo, smettendo di gestire le richieste. Poiché il processo continua a essere in esecuzione, per impostazione predefinita Kubernetes considererà che tutto sia a posto e continuerà a inviare richieste al pod non funzionante. Ma utilizzando Liveness, Kubernetes rileverà che l'applicazione non sta più gestendo le richieste e di default riavvierà il pod non funzionante.
Esaminiamo i metodi per testare la prontezza e la vitalità. Esistono tre modi per testare: HTTP, Command e TCP. Puoi utilizzare uno qualsiasi di questi metodi per il controllo. Il modo più comune di test utente è 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 rientra nell'intervallo di 200 o 300 ms, significa che il pod è "sano". In caso contrario, il modulo verrà contrassegnato come "malato".
Per i test tramite Command, Kubernetes esegue un comando all'interno del tuo contenitore. Se il comando restituisce un codice di uscita zero, il contenitore sarà contrassegnato come sano; in caso contrario, se si ottiene un codice di uscita da 1 a 255, il contenitore sarà segnalato come "malato". Questo metodo di test è utile se non puoi o non vuoi eseguire un server HTTP, ma sei in grado di eseguire un comando che verificherà la "salute" della tua applicazione.
L'ultimo meccanismo di verifica è il test TCP. Kubernetes tenterà di stabilire una connessione TCP sulla porta specificata. Se ci riesce, il contenitore viene considerato sano, altrimenti viene giudicato non attivo. Questo metodo può rivelarsi utile se si utilizza uno script in cui il test tramite richiesta HTTP o l'esecuzione di comandi non funziona molto bene. Ad esempio, i principali servizi per la verifica tramite TCP sono gRPC o FTP.
I test possono essere configurati in diversi modi con vari parametri. Puoi specificare con quale frequenza devono essere eseguiti, quali sono i valori soglia per il successo e il fallimento, e per quanto tempo attendere risposte. Informazioni più dettagliate sono disponibili nella documentazione sui test di Readiness e Liveness. Tuttavia, c'è un punto molto importante nella configurazione del test di Liveness: l'installazione iniziale del ritardo di test initialDelaySeconds. Come ho menzionato, un fallimento in 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 ciclicamente. 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 esperti confermerà che i controlli di salute sono test essenziali per qualsiasi sistema distribuito, e Kubernetes non fa eccezione. Utilizzare il controllo "salute" dei servizi garantisce un funzionamento affidabile e senza interruzioni di Kubernetes, senza costituire alcuna difficoltà per gli utenti.
Il seguito arriverà molto presto…
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
