Sistemele distribuite pot fi dificil de gestionat, deoarece au multe elemente în mișcare, schimbătoare, care trebuie să funcționeze corect pentru ca sistemul să funcționeze. Dacă unul dintre elemente eșuează, sistemul trebuie să îl detecteze, să îl ocolească și să îl repare, iar toate acestea trebuie făcute automat. În această serie de bune practici Kubernetes, vom învăța cum să configurați teste de pregătire și de funcționare pentru a testa starea de sănătate a unui cluster Kubernetes.
Verificarea sănătății este o modalitate simplă de a informa sistemul dacă instanța aplicației dumneavoastră rulează sau nu. Dacă instanța aplicației dvs. este inactivă, alte servicii nu ar trebui să o acceseze sau să îi trimită solicitări. În schimb, cererea trebuie trimisă către o altă instanță a aplicației care rulează deja sau va fi lansată ulterior. În plus, sistemul ar trebui să restabilească funcționalitatea pierdută a aplicației dvs.
În mod implicit, Kubernetes va începe să trimită trafic către un pod atunci când toate containerele din poduri rulează și va reporni containerele când se blochează. Acest comportament implicit al sistemului poate fi suficient de bun pentru început, dar puteți îmbunătăți fiabilitatea implementării produsului dvs. utilizând verificări personalizate.
Din fericire, Kubernetes face acest lucru destul de ușor de făcut, așa că nu există nicio scuză pentru a ignora aceste verificări. Kubernetes oferă două tipuri de verificări de sănătate și este important să înțelegeți diferențele în modul în care fiecare este utilizat.
Testul de pregătire este conceput pentru a spune lui Kubernetes că aplicația dvs. este pregătită să gestioneze traficul. Înainte de a permite unui serviciu să trimită trafic către un pod, Kubernetes trebuie să verifice dacă verificarea pregătirii a avut succes. Dacă testul de pregătire eșuează, Kubernetes va înceta să trimită trafic către pod până la trecerea testului.
Testul Liveness îi spune lui Kubernetes dacă aplicația dvs. este activă sau inactivă. În primul caz, Kubernetes îl va lăsa în pace, în al doilea va șterge podul mort și îl va înlocui cu unul nou.
Să ne imaginăm un scenariu în care aplicația dvs. durează 1 minut să se încălzească și să se lanseze. Serviciul dvs. nu va începe să funcționeze până când aplicația este complet încărcată și rulată, deși fluxul de lucru a început deja. De asemenea, veți avea probleme dacă doriți să extindeți această implementare la mai multe copii, deoarece acele copii nu ar trebui să primească trafic până când nu sunt complet gata. Cu toate acestea, în mod implicit, Kubernetes va începe să trimită trafic de îndată ce încep procesele din interiorul containerului.
Când utilizați testul de pregătire, Kubernetes va aștepta până când aplicația rulează complet înainte de a permite serviciului să trimită trafic către noua copie.
Să ne imaginăm un alt scenariu în care aplicația se blochează mult timp, oprind solicitările de service. Pe măsură ce procesul continuă să ruleze, în mod implicit Kubernetes va presupune că totul este în regulă și va continua să trimită cereri către podul care nu funcționează. Dar când folosește Liveness, Kubernetes va detecta că aplicația nu mai deservește cereri și va reporni în mod implicit podul mort.
Să ne uităm la modul în care sunt testate pregătirea și viabilitatea. Există trei metode de testare - HTTP, Command și TCP. Puteți folosi oricare dintre ele pentru a verifica. Cel mai comun mod de a testa un utilizator este o sondă HTTP.
Chiar dacă aplicația dvs. nu este un server HTTP, puteți crea în continuare un server HTTP ușor în interiorul aplicației pentru a interacționa cu testul Liveness. După aceasta, Kubernetes va începe să pună ping pe pod, iar dacă răspunsul HTTP este în intervalul de 200 sau 300 ms, va indica că podul este sănătos. În caz contrar, modulul va fi marcat ca „nesănătos”.
Pentru testele de comandă, Kubernetes rulează comanda în interiorul containerului dvs. Dacă comanda revine cu un cod de ieșire zero, atunci containerul va fi marcat ca sănătos, în caz contrar, la primirea unui număr de stare de ieșire de la 1 la 255, containerul va fi marcat ca „bolnav”. Această metodă de testare este utilă dacă nu puteți sau nu doriți să rulați un server HTTP, dar puteți rula o comandă care va verifica starea aplicației dvs.
Mecanismul final de verificare este testul TCP. Kubernetes va încerca să stabilească o conexiune TCP pe portul specificat. Dacă acest lucru se poate face, recipientul este considerat sănătos; dacă nu, este considerat neviabil. Această metodă poate fi utilă dacă utilizați un scenariu în care testarea cu o solicitare HTTP sau executarea unei comenzi nu funcționează foarte bine. De exemplu, principalele servicii de verificare folosind TCP ar fi gRPC sau FTP.
Testele pot fi configurate în mai multe moduri cu parametri diferiți. Puteți specifica cât de des ar trebui să fie executate, care sunt pragurile de succes și eșec și cât timp să așteptați răspunsuri. Pentru mai multe informații, consultați documentația pentru testele de pregătire și viabilitate. Cu toate acestea, există un punct foarte important în configurarea testului Liveness - setarea inițială a întârzierii de testare initialDelaySeconds. După cum am menționat, eșecul acestui test va duce la repornirea modulului. Deci, trebuie să vă asigurați că testarea nu începe până când aplicația este gata de funcționare, altfel va începe să parcurgă reporniri. Recomand să utilizați timpul de pornire P99 sau timpul mediu de pornire a aplicației din buffer. Nu uitați să ajustați această valoare pe măsură ce timpul de pornire al aplicației dvs. devine mai rapid sau mai lent.
Majoritatea experților vor confirma că verificările de sănătate sunt o verificare obligatorie pentru orice sistem distribuit, iar Kubernetes nu face excepție. Utilizarea verificărilor de sănătate a serviciului asigură funcționarea fiabilă și fără probleme a Kubernetes și este fără efort pentru utilizatori.
Va continua foarte curand...
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com