Gestionarea sistemelor distribuite poate fi dificilă din cauza numeroaselor elemente mobile și modificabile, toate acestea fiind necesare pentru funcționarea corectă a sistemului. Dacă unul dintre elemente se defectează, sistemul trebuie să-l identifice, să-l ocolească și să-l repare, și totul trebuie să se facă automat. În această serie de articole „Kubernetes Best Practices”, vom învăța cum să configurăm testele de Readiness și Liveness pentru a verifica viabilitatea cluster-ului Kubernetes.
Verificarea stării (Health Check) este un mod simplu de a permite sistemului să știe dacă instanța aplicației dvs. funcționează sau nu. Dacă instanța aplicației dvs. nu funcționează, celelalte servicii nu ar trebui să se adreseze acesteia sau să-i trimită cereri. În schimb, cererea ar trebui să fie direcționată către o altă instanță a aplicației care fie este deja activă, fie va fi activată ulterior. În plus, sistemul ar trebui să returneze aplicației dvs. funcționalitatea pierdută.
În mod implicit, Kubernetes va începe să direcționeze traficul către pod atunci când toate containerele din interiorul acestuia sunt active, și va reporni containerele atunci când acestea se opresc brusc. Deși acest comportament implicit poate fi suficient pentru început, puteți îmbunătăți fiabilitatea desfășurării produsului dvs. folosind verificări personalizate de sănătate.
Din fericire, Kubernetes permite realizarea acestora destul de simplu, astfel că ignorarea unor astfel de verificări nu este justificată. Kubernetes oferă două tipuri de teste de Health Check, și este important să înțelegeți diferențele dintre utilizările fiecăruia.
Testul de readiness este destinat să informeze Kubernetes despre disponibilitatea aplicației dvs. de a gestiona traficul. Înainte de a permite serviciului să trimită trafic către pod, Kubernetes trebuie să se asigure că testul de readiness a fost finalizat cu succes. Dacă testul de readiness eșuează, Kubernetes va înceta să trimită trafic către pod până când testul nu este realizat cu succes.
Testul de liveness informează Kubernetes dacă aplicația dvs. este vie sau mortă. În cazul în care este vie, Kubernetes o va lăsa în pace, iar în cazul în care este moartă, va elimina podul mort și îl va înlocui cu unul nou.
Să ne imaginăm un scenariu în care aplicația dumneavoastră necesită 1 minut pentru a fi "încălzită" și lansată. Serviciul dumneavoastră nu va începe să funcționeze până când aplicația nu se va încărca și lansa complet, chiar dacă fluxul de lucru a început deja. De asemenea, veți avea probleme dacă doriți să scalați acest deployment la mai multe copii, deoarece aceste copii nu ar trebui să primească trafic până nu sunt complet gata. Totuși, în mod implicit, Kubernetes va începe să redirecționeze traficul imediat după inițierea proceselor din interiorul containerului.
Folosind testul de disponibilitate (Readiness), Kubernetes va aștepta până când aplicația va fi complet lansată și abia după aceea va permite serviciului să redirecționeze traficul către noua copie.
Să ne imaginăm un alt scenariu în care aplicația se blochează pentru o perioadă îndelungată, fără a mai răspunde la cereri. Deoarece procesul continuă să ruleze, în mod implicit Kubernetes va considera că totul este în regulă și va continua să redirecționeze cererile către pod-ul nefuncțional. Însă, folosind Liveness, Kubernetes va detecta că aplicația nu mai răspunde la cereri și va reporni, în mod implicit, pod-ul nefuncțional.
Să analizăm instrumentele folosite pentru a testa disponibilitatea și viabilitatea. Există trei moduri de testare - HTTP, Command și TCP. Puteți folosi oricare dintre acestea pentru verificare. Cel mai utilizat mod de testare de utilizator este HTTP probe.
Chiar dacă aplicația dumneavoastră nu este un server HTTP, puteți crea totuși un server HTTP ușor în interiorul aplicației dumneavoastră pentru a interacționa cu testul Liveness. După aceea, Kubernetes va începe să ping-pongueze pod-ul, iar dacă răspunsul HTTP se încadrează între 200 sau 300 ms, aceasta va însemna că pod-ul este „sănătos”. În caz contrar, modul va fi marcat ca „nesănătos”.
Pentru testele folosind Command, Kubernetes va executa o comandă în interiorul containerului dumneavoastră. Dacă comanda se întoarce cu un cod de ieșire zero, containerul va fi marcat ca sănătos; în caz contrar, dacă se obține un cod de ieșire între 1 și 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 sunteți capabili să rulați o comandă care să verifice „sănătatea” aplicației dumneavoastră.
Ultimul mecanism de verificare este testul TCP. Kubernetes va încerca să stabilească o conexiune TCP pe portul specificat. Dacă reușește, containerul este considerat sănătos, altfel este considerat nesănătos. Această metodă poate fi utilă dacă utilizați un scenariu în care testarea cu un request HTTP sau executarea unei comenzi nu funcționează foarte bine. De exemplu, principalele servicii pentru testarea prin TCP vor fi gRPC sau FTP.
Testele pot fi configurate în mai multe moduri cu diferite parametrii. Puteți specifica cât de des ar trebui să fie efectuate, care sunt pragurile de succes și eșec, cât timp să aștepte răspunsuri. Informații mai detaliate sunt prezentate în documentația pentru testele Readiness și Liveness. Totuși, există un aspect foarte important în configurarea testului Liveness – întârzirea inițială de testare initialDelaySeconds. Așa cum menționam, o executare eșuată a acestui test va conduce la repornirea modulului. Prin urmare, trebuie să vă asigurați că testarea nu începe până când aplicația nu este pregătită să funcționeze, altfel va începe să repornească în mod ciclic. Recomand să utilizați timpul de start P99 sau timpul mediu de lansare a aplicației din buffer. Nu uitați să ajustați această valoare pe măsură ce timpul de lansare al aplicației devine tot mai rapid sau mai lent.
Cei mai mulți specialiști confirmă că Health Check-urile sunt verifi care obligatorii pentru orice sistem distribuit, iar Kubernetes nu face excepție. Utilizarea verificării "sănătății" serviciilor asigură o funcționare fiabilă și fără probleme a Kubernetes și nu reprezintă o problemă pentru utilizatori.
Continuarea va veni foarte curând…
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
