I sistemi distribuiti ponu esse difficiuli di gestisce perchè anu parechje elementi mudificanti è cambianti chì tutti anu bisognu di travaglià bè per u funziunamentu di u sistema. Se unu di l'elementi falla, u sistema deve detectà, bypassà è riparà, è tuttu questu deve esse fattu automaticamente. In questa serie di Kubernetes Best Practices, ampararemu cumu stabilisce e teste di Readiness and Liveness per pruvà a salute di un cluster Kubernetes.
A verificazione di salute hè un modu simplice per fà sapè à u sistema se a vostra istanza di applicazione hè in esecuzione o micca. Se l'istanza di l'applicazione hè in calata, altri servizii ùn devenu micca accede à ellu o mandà richieste. Invece, a dumanda deve esse mandata à un'altra istanza di l'applicazione chì hè digià in esecuzione o serà lanciata dopu. Inoltre, u sistema deve restaurà a funziunalità persa di a vostra applicazione.
Per automaticamente, Kubernetes cumincià à mandà u trafficu à un pod quandu tutti i cuntenituri in i pods sò in esecuzione, è riavvia i cuntenituri quandu si crash. Stu cumpurtamentu predeterminatu di u sistema pò esse abbastanza bè per principià, ma pudete migliurà l'affidabilità di a distribuzione di u vostru pruduttu usendu cuntrolli di sanità persunalizati.
Fortunatamente, Kubernetes rende questu abbastanza faciule da fà, cusì ùn ci hè scusa per ignurà questi cuntrolli. Kubernetes furnisce dui tipi di Cuntrolli di Salute, è hè impurtante capisce e differenze in cumu si usanu ognunu.
A prova di Readiness hè pensata per dì à Kubernetes chì a vostra applicazione hè pronta per trattà u trafficu. Prima di permette à un serviziu di mandà u trafficu à un pod, Kubernetes deve verificà chì a verificazione di preparazione hè successu. Se a prova di Readiness falla, Kubernetes cesserà di mandà u trafficu à u pod finu à chì a prova passa.
A prova Liveness dice à Kubernetes se a vostra applicazione hè viva o morta. In u primu casu, Kubernetes l'abbandunarà solu, in u sicondu sguasserà u pod mortu è rimpiazzà cù un novu.
Imaginemu un scenariu induve a vostra applicazione dura 1 minutu per riscalda è lancià. U vostru serviziu ùn hà micca cuminciatu à travaglià finu à chì l'applicazione hè cumpletamente caricata è in esecuzione, anche se u flussu di travagliu hè digià iniziatu. Averete ancu prublemi se vulete scalate sta implementazione à parechje copie, perchè queste copie ùn devenu micca riceve trafficu finu à ch'elli sò pronti. Tuttavia, per automaticamente, Kubernetes hà da cumincià à mandà u trafficu appena principia i prucessi in u containeru.
Quandu aduprate a prova di Readiness, Kubernetes aspittàrà finu à chì l'applicazione sia cumpletamente in esecuzione prima di permette à u serviziu di mandà u trafficu à a nova copia.
Imaginemu un altru scenariu in quale l'applicazione si ferma per un bellu pezzu, cessendu e dumande di serviziu. Cume u prucessu cuntinueghja à eseguisce, per difettu Kubernetes assumerà chì tuttu hè bè è cuntinueghja à mandà richieste à u pod chì ùn funziona. Ma quandu usa Liveness, Kubernetes detecterà chì l'applicazione ùn serve più richieste è riavviarà u pod mortu per difettu.
Fighjemu cumu a prontezza è a viabilità sò pruvati. Ci sò trè metudi di prova - HTTP, Command è TCP. Pudete aduprà qualsiasi di elli per verificà. U modu più cumuni per pruvà un utilizatore hè una sonda HTTP.
Ancu s'è a vostra applicazione ùn hè micca un servitore HTTP, pudete ancu creà un servitore HTTP ligeru in a vostra applicazione per interagisce cù a prova Liveness. Dopu questu, Kubernetes hà da cumincià à pinging u pod, è se a risposta HTTP hè in u intervallu 200 o 300 ms, indicà chì u pod hè sanu. Altrimenti, u modulu serà marcatu cum'è "insaluità".
Per i testi di Command, Kubernetes esegue u cumandamentu in u vostru containeru. Se u cumandamentu torna cù un codice di uscita zero, u cuntinuu serà marcatu cum'è sanu, altrimenti, dopu avè ricivutu un numeru di statutu di uscita da 1 à 255, u cuntinuu serà marcatu cum'è "malatu". Stu metudu di teste hè utile si ùn pudete micca o ùn vulete micca eseguisce un servitore HTTP, ma sò capaci di eseguisce un cumandamentu chì verificarà a salute di a vostra applicazione.
U mecanismu di verificazione finali hè a prova TCP. Kubernetes pruverà à stabilisce una cunnessione TCP nantu à u portu specificatu. Se questu pò esse fattu, u cuntinuu hè cunsideratu sanu; se no, hè cunsideratu inviable. Stu metudu pò esse utile s'è vo aduprate un scenariu induve a prova cù una dumanda HTTP o l'esekzione di cumanda ùn viaghja micca bè. Per esempiu, i servizii principali per a verificazione cù TCP seria gRPC o FTP.
I testi ponu esse cunfigurati in parechje manere cù diversi parametri. Pudete specificà quante volte deve esse eseguite, quale sò i soglia di successu è fallimentu, è quantu tempu aspittà per e risposte. Per più infurmazione, vede a documentazione per i testi di Readiness and Liveness. Tuttavia, ci hè un puntu assai impurtante in a stallazione di a prova Liveness - l'impostazione iniziale di u ritardu di prova initialDelaySeconds. Cumu l'aghju dettu, u fallimentu di sta prova hà da esse riavviatu u modulu. Dunque, avete bisognu di assicurà chì a prova ùn principia micca finu à chì l'applicazione hè pronta per andà, altrimenti principiarà in bicicletta per riavvia. I ricumandemu di utilizà u tempu di startup P99 o u tempu mediu d'iniziu di l'applicazione da u buffer. Ricurdatevi di aghjustà stu valore cum'è u tempu di startup di a vostra applicazione diventa più veloce o più lento.
A maiò parte di l'esperti cunfirmà chì i Cuntrolli di Salute sò un cuntrollu obligatoriu per qualsiasi sistema distribuitu, è Kubernetes ùn hè micca eccezzioni. Utilizà i cuntrolli di salute di u serviziu assicura un funziunamentu affidabile, senza prublemi di Kubernetes è hè senza sforzu per l'utilizatori.
Da cuntinuà assai prestu...
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com