Kubernetes beredskabs- og livelighedsundersøgelser - bedste praksis

“Person, der ser på maleri” af Antenna på Unsplash

I Kubernetes er pods de mindste distribuerbare computerenheder, der kan oprettes og styres. En pod er en gruppe af en eller flere containere (Docker, raket osv.) Med delt lager / netværk og en specifikation for, hvordan man kører containerne.

Beredskabs- og livelighedsundersøgelser kan kaldes generisk i Kubernetes-sammenhæng Sundhedscheck. Containerprober er små processer, der kører periodisk. Resultatet af disse sonder (Succes, Mislykket eller Ukendt) bestemmer Kubernetes perspektiv på beholderens tilstand. Baseret på dem beslutter Kubernetes, hvordan man skal behandle hver enkelt container for at opretholde modstandsdygtighed, høj tilgængelighed og højere oppetid.

Sundhedskontrol er et krav for ethvert distribueret system!

Kubernetes sundhedskontrol:

Kubernetes tilbyder to typer sundhedskontrol: beredskab og livlighed, og begge har deres eget formål. I forbindelse med denne artikel vælger du:

  • /.well- bekend/live - til HTTP live-sonde
  • /.well- bekend/ready - til HTTP klar sonde

Med få ord betyder HTTP-sondering, at Kubernetes udfører med bestemte tidsintervaller HTTP Få anmodninger om /.well-known/live og /.well-known/ready. Statuskoden for svaret bruges til at bestemme, hvad der skal gøres med poden. Hvis statuskoden er i intervallet [200, 300), er alt i orden. Ellers:

  • Hvis statuskoden for live-proben er 4xx eller 5xx, genstartes pod'en
  • Hvis statuskoden for den klare sonde er 4xx eller 5xx, markeres pod som usund, og HTTP-trafik vil ikke længere blive omdirigeret til den for at øge pålideligheden og oppetiden.
Hvis containere er uafhængige af nogen sikkerhedskopieringstjenester, kan containere have livskraft og beredskabskontrol udsat for den samme operatør, og det følgende gælder ikke.

Sammen med holdkammerater fra Metro Systems Rumænien - Site Reliability Team har vi identificeret en liste over bedste praksis for sundhedscheck og har rådet applikationsudviklerne om at følge dem. Sådanne bedste fremgangsmåder er:

  1. Live & Ready-håndterere skal være uafhængige funktioner!

Som nævnt tidligere skal der for hvert produkt, der er implementeret i en Kubernetes-sammenhæng, implementeres 2 behandlere, der svarer på HTTP-opkald til “live” og “klar”. Den første bedste praksis med hensyn til disse sonder er, at hver behandler skal have sin egen funktion implementeret.

2. Frakobl ikke logikken for “live” / “klar” fra din ansøgning!

Dette gælder for jobbehandlingsapps. For Kubernetes er det vigtigt at vide, om behandlingsappen kører eller ej. Hvis logikken for live / klar blev afkoblet i en ny proces, er resultatet ikke afgørende.

3. Implementér ikke nogen logik på "live" -handler. Den skal returnere status 200, hvis hovedtråden kører og 5xx, hvis den ikke er det.

Denne sonde lader Kubernetes vide, om applikationen er i live eller død. Beslutningen træffes ved at kontrollere statuskoden for /.well-known/live, og hvis applikationen erklæres død, genstarter Kubernetes poden. Fra pålidelighedssynspunktet skal svaret til live-probe være sandt, hvis appens hovedtråd er i gang og ellers falsk.

I denne sammenhæng betyder "logik" at implementere en slags kontrol over de sammenkoblede tjenester.

4. Implementer logik i "klar" -handler for at tilbyde et komplet svar om appens parathed.

Klar sonde lader Kubernetes vide, om poden er klar til at modtage HTTP-trafik. Som udvikler er det vigtigt at implementere her en vis logik for at kontrollere tilgængeligheden af ​​alle dine backend-afhængigheder for applikationen. Når "klar" -handleren er implementeret, er det meget vigtigt at vide, hvad klar virkelig betyder for din ansøgning. Med andre ord på "klar" -handleren er det vigtigt at køre alle trin, der bestemmer, at appen er klar til at modtage og behandle https-anmodninger. Hvis applikationen f.eks. Skal etablere en forbindelse til en database for at være klar til at behandle HTTP-anmodninger, er beredskabssonden vigtig for at kontrollere, om forbindelsen til databasen er etableret og klar til brug.

Lad os overveje et specifikt tilfælde: applikationen sidder fast og laver en vis behandling på en separat tråd, men hovedtråden fungerer godt. Som udvikler ved du, at en pod-genstart vil løse problemet, og du kan overbevise Kubernetes om automatisk at udføre det for dig. Alt hvad du skal gøre er at sikre, at applikationen reagerer med 5xx på den klare sonde og tvinger den levende sonde til at returnere et minimumsbeløb på 5xx svar på Kubernetes-opkald. I dette tilfælde genstarter Kubernetes poden, fordi den betragtes som død.

5. Forsøg ikke at gendanne appens beredskabsstatus på den klar håndterer. Dette gøres kun for at kontrollere, om appen er klar, ikke for at gøre den klar.

Det tilrådes, at der ikke er implementeret nogen logik, der forsøger at genoprette beredskabstilstanden. At have en sådan logik kan være farligt for nogle af systemets komponenter.

konklusioner:

Live og Ready sonder er hjertet og sjælen i de applikationer, der er implementeret i Kubernetes. De er standardmåderne til at kommunikere med hypervisoren og tale om deres status og deres problemer. Live og klar sonder er kraftfulde våben, som en udvikler og en applikation har brug for for at sikre, at applikationen er pålidelig og robust.

Særlig tak til Ionut Ilie. En del af dette materiale er resultatet af hans forskning og visdom.