I sistemi distribuiti possono essere difficili da gestire perché contengono molti elementi mobili e mutevoli che devono tutti funzionare correttamente affinché il sistema funzioni. Se uno degli elementi si guasta, il sistema deve rilevarlo, bypassarlo e ripararlo, e tutto ciò deve essere fatto automaticamente. In questa serie di best practice Kubernetes, impareremo come impostare i test di disponibilità e attività per testare l'integrità di un cluster Kubernetes.
Il controllo dello stato è un modo semplice per far sapere al sistema se l'istanza dell'applicazione è in esecuzione o meno. Se l'istanza dell'applicazione è inattiva, gli altri servizi non dovrebbero accedervi o inviarle richieste. La richiesta deve invece essere inviata a un'altra istanza dell'applicazione già in esecuzione o che verrà avviata successivamente. Inoltre, il sistema dovrebbe ripristinare la funzionalità perduta dell'applicazione.
Per impostazione predefinita, Kubernetes inizierà a inviare traffico a un pod quando tutti i contenitori all'interno dei pod sono in esecuzione e riavvierà i contenitori quando si arrestano in modo anomalo. Questo comportamento predefinito del sistema potrebbe essere sufficiente per iniziare, ma puoi migliorare l'affidabilità della distribuzione del prodotto utilizzando controlli di integrità personalizzati.
Fortunatamente, Kubernetes rende questa operazione abbastanza semplice, quindi non ci sono scuse per ignorare questi controlli. Kubernetes fornisce due tipi di controlli dello stato ed è importante comprendere le differenze nel modo in cui ciascuno viene utilizzato.
Il test di preparazione è progettato per indicare a Kubernetes che la tua applicazione è pronta a gestire il traffico. Prima di consentire a un servizio di inviare traffico a un pod, Kubernetes deve verificare che il controllo di idoneità abbia esito positivo. Se il test di idoneità fallisce, Kubernetes interromperà l'invio di traffico al pod finché il test non avrà esito positivo.
Il test di attività indica a Kubernetes se la tua applicazione è viva o morta. Nel primo caso Kubernetes lo lascerà stare, nel secondo cancellerà il pod morto e lo sostituirà con uno nuovo.
Immaginiamo uno scenario in cui l'applicazione impiega 1 minuto per riscaldarsi e avviarsi. Il tuo servizio non inizierà a funzionare finché l'applicazione non sarà completamente caricata e in esecuzione, sebbene il flusso di lavoro sia già avviato. Avrai problemi anche se desideri estendere questa distribuzione a più copie, perché tali copie non dovrebbero ricevere traffico finché non saranno completamente pronte. Tuttavia, per impostazione predefinita, Kubernetes inizierà a inviare traffico non appena iniziano i processi all'interno del contenitore.
Quando si utilizza il test di conformità, Kubernetes attenderà finché l'applicazione non sarà completamente in esecuzione prima di consentire al servizio di inviare traffico alla nuova copia.
Immaginiamo un altro scenario in cui l'applicazione si blocca a lungo, interrompendo le richieste di servizio. Mentre il processo continua a essere eseguito, per impostazione predefinita Kubernetes presuppone che tutto vada bene e continuerà a inviare richieste al pod non funzionante. Ma quando si utilizza Liveness, Kubernetes rileverà che l'applicazione non serve più le richieste e riavvierà il dead pod per impostazione predefinita.
Diamo un'occhiata a come vengono testate la disponibilità e la fattibilità. Esistono tre metodi di test: HTTP, Comando e TCP. Puoi usarne uno qualsiasi per controllare. Il modo più comune per testare un utente è un sondaggio HTTP.
Anche se la tua applicazione non è un server HTTP, puoi comunque creare un server HTTP leggero all'interno della tua applicazione per interagire con il test di attività. Successivamente, Kubernetes inizierà a eseguire il ping del pod e, se la risposta HTTP è compresa nell'intervallo di 200 o 300 ms, indicherà che il pod è integro. In caso contrario, il modulo verrà contrassegnato come "non integro".
Per i test dei comandi, Kubernetes esegue il comando all'interno del contenitore. Se il comando restituisce un codice di uscita pari a zero, il contenitore verrà contrassegnato come integro, altrimenti, dopo aver ricevuto un numero di stato di uscita da 1 a 255, il contenitore verrà contrassegnato come “malato”. Questo metodo di test è utile se non puoi o non vuoi eseguire un server HTTP, ma puoi eseguire un comando che controllerà lo stato della tua applicazione.
Il meccanismo di verifica finale è il test TCP. Kubernetes tenterà di stabilire una connessione TCP sulla porta specificata. Se ciò è possibile, il contenitore è considerato sano; in caso contrario, è considerato non vitale. Questo metodo può essere utile se si utilizza uno scenario in cui il test con una richiesta HTTP o l'esecuzione di un comando non funziona molto bene. Ad esempio, i principali servizi per la verifica tramite TCP sarebbero gRPC o FTP.
I test possono essere configurati in diversi modi con parametri diversi. È possibile specificare la frequenza con cui devono essere eseguiti, quali sono le soglie di successo e di fallimento e quanto tempo attendere per le risposte. Per ulteriori informazioni, vedere la documentazione per i test di disponibilità e attività. Tuttavia, c'è un punto molto importante nell'impostazione del test Liveness: l'impostazione iniziale del ritardo del test partialDelaySeconds. Come ho già detto, il fallimento di questo test comporterà il riavvio del modulo. È quindi necessario assicurarsi che il test non venga avviato finché l'applicazione non è pronta, altrimenti inizierà a ripetere i riavvii. Raccomando di utilizzare il tempo di avvio P99 o il tempo medio di avvio dell'applicazione dal buffer. Ricorda di modificare questo valore man mano che il tempo di avvio dell'applicazione diventa più veloce o più lento.
La maggior parte degli esperti confermerà che i controlli dello stato sono un controllo obbligatorio per qualsiasi sistema distribuito e Kubernetes non fa eccezione. L'utilizzo dei controlli dello stato del servizio garantisce un funzionamento affidabile e senza problemi di Kubernetes ed è semplice per gli utenti.
Continua molto presto...
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