Kubernetes Readiness & Liveliness Probes - Best Practices

“Person som ser på maleri” av Antenna på Unsplash

I Kubernetes er pods de minste distribuerbare datamaskinene som kan opprettes og administreres. En pod er en gruppe av en eller flere containere (Docker, rakett, osv.), Med delt lagring / nettverk, og en spesifikasjon for hvordan du kjører containerne.

Beredskap og livlighetssonder kan generisk kalles i Kubernetes-sammenheng Helsesjekk. Beholderprober er små prosesser som kjøres med jevne mellomrom. Resultatet av disse sonderne (suksess, mislykket eller ukjent) bestemmer Kubernetes perspektiv på beholderens tilstand. Basert på dem bestemmer Kubernetes hvordan de skal behandle hver container for å opprettholde spenst, høy tilgjengelighet og høyere oppetid.

Helsesjekk er et krav for ethvert distribuert system!

Kubernetes helsekontroller:

Kubernetes tilbyr to typer helsekontroller: beredskap og livlighet, og begge har et eget formål. I sammenheng med denne artikkelen vil du velge:

  • /.well- known/live - for HTTP live sonde
  • /.well-known/ready - for HTTP-klar sonde

Med noen få ord betyr HTTP-sondering at Kubernetes utfører med bestemte tidsintervaller HTTP Få forespørsler på /.well-known/live og /.well-known/ready. Statuskoden til svaret brukes til å bestemme hva som må gjøres med poden. Hvis statuskoden er i intervallet [200, 300), er alt i orden. Ellers:

  • Hvis statuskoden for live-sonden er 4xx eller 5xx, startes poden på nytt
  • Hvis statuskoden for klar sonde er 4xx eller 5xx, er pod merket som usunn og HTTP-trafikk vil ikke lenger bli omdirigert til den for å øke påliteligheten og oppetiden.
Hvis containere er uavhengige av sikkerhetskopieringstjenester, kan containere ha livskraft og beredskapskontroller utsatt for den samme transportøren, og det som følger, gjelder ikke.

Sammen med lagkamerater fra Metro Systems Romania - Site Reliability Team, har vi identifisert en liste over beste fremgangsmåter for helsekontrollene og har rådet applikasjonsutviklerne til å følge dem. Slike beste fremgangsmåter er:

  1. Live & Ready-håndtere må være uavhengige funksjoner!

Som nevnt tidligere, for hvert produkt som er distribuert i en Kubernetes-sammenheng, skal to behandlere som svarer på HTTP-samtaler for “live” og “klar”, implementeres. Den første beste praksis med hensyn til disse probene er at hver behandler må ha sin egen funksjon implementert.

2. Ikke koble fra logikken for “live” / “klar” fra applikasjonen!

Dette gjelder applikasjoner for jobbbehandling. For Kubernetes er det viktig å vite om behandlingsappen kjører eller ikke. Hvis logikken for live / klar ble koblet fra i en ny prosess, er resultatet ikke avgjørende.

3. Ikke bruk noen logikk på “live” -handler. Den må returnere status 200 hvis hovedtråden kjører og 5xx hvis den ikke er det.

Denne sonden lar Kubernetes vite om applikasjonen er i live eller død. Avgjørelsen tas ved å sjekke statuskoden for /.well-known/live, og hvis applikasjonen er erklært død, starter Kubernetes poden på nytt. Fra pålitelighetssynspunktet må svaret for live sonde være sant hvis appens hovedtråd er oppe og går ellers.

I denne sammenheng betyr "logikk" å implementere en slags sjekker over de sammenkoblede tjenestene.

4. Implementer logikk i "klar" -handler for å tilby et fullstendig svar om beredskapen til appen.

Ready sonde lar Kubernetes vite om poden er klar til å motta HTTP-trafikk. Som utvikler er det viktig å implementere her litt logikk for å sjekke tilgjengeligheten til alle dine backend-avhengigheter for applikasjonen. Når den "klare" behandleren er implementert, er det veldig viktig å vite hva klart egentlig betyr for søknaden din. Med andre ord, på den "klare" -handleren er det viktig å kjøre alle trinn som bestemmer at appen er klar til å motta og å behandle https-forespørsler. Hvis for eksempel applikasjonen trenger å etablere en forbindelse til en database for å være klar til å behandle HTTP-forespørsler, er beredskapssonde viktig for å sjekke om forbindelsen til databasen er opprettet og klar til bruk.

La oss vurdere et spesifikt tilfelle: applikasjonen blir sittende fast og behandler på en egen tråd, men hovedtråden fungerer bra. Som utvikler vet du at en pod-omstart vil løse problemet, og du kan overbevise Kubernetes om å automatisk utføre det for deg. Alt du trenger å gjøre er å sørge for at applikasjonen svarer med 5xx på klar sonde og tvinge live-sonden til å returnere et minimumsbeløp på 5xx svar på Kubernetes samtaler. I dette tilfellet vil Kubernetes starte poden på nytt fordi den regnes som død.

5. Ikke prøv å gjenopprette beredskapsstatusen til appen på den klare behandleren. Dette er laget bare for å sjekke at appen er klar, ikke for å gjøre den klar.

Det anbefales at det ikke er implementert noen logikk som prøver å gjenopprette beredskapstilstanden. Å ha en slik logikk kan være farlig for noen av komponentene i systemet.

konklusjoner:

Live og Ready sonder er hjertet og sjelen til applikasjonene som er distribuert i Kubernetes. De er standard måter å kommunisere med hypervisoren og snakke om statusen og problemene sine. Levende og klare sonder er kraftige våpen som en utvikler og en applikasjon trenger for å sikre at applikasjonen er pålitelig og spenstig.

Spesiell takk til Ionut Ilie. En del av dette materialet er resultatet av hans forskning og visdom.