Kubernetes Readiness Probes

Kubernetes er et fantastisk rammeverk for distribusjon av mikroservices og apper. Når pods ikke utfører ordentlig, startes de på nytt eller fjernet fra en tjeneste, noe som er en fantastisk funksjon. Kubernetes krever vår hjelp til å avgjøre om en pod er operativ eller ikke. Containerprober brukes til å sette opp dette. I denne artikkelen vil vi prøve å forstå hva Kubernetes Readiness Probes er og hvordan det fungerer.

Hva er beredskapsprober?

Kubernetes bruker beredskapsprober for å finne ut når det er trygt å overføre trafikk til en pod eller når det er på tide å flytte poden til klar tilstand.

En beredskapssonde vil evaluere om en spesifikk pod vil akseptere trafikk hvis den brukes som et backend -endepunkt for en tjeneste.

Readiness -sonden løper resten av podens liv; Dette betyr at den går selv etter at pod har nådd klar tilstand. Anvendelsen vår kan også gjøre seg utilgjengelig for vedlikehold eller noe bakgrunnsarbeid ved å svare på sonden med forskjellige svar.

Det indikerer om beholderen er klar til å godta spørsmål eller ikke. I tilfelle beredskapssonen ødelegger av en eller annen grunn, eliminerer endepunktene i IP -adressen til pods fra endepunktene blant alle tjenester som tilfredsstiller POD. Feil er standardtilstanden for beredskapen før den første forsinkelsen.

Når skal du bruke en beredskapssonde?

Beredskapssonden kan være akkurat som livlig sonde (som avgjør når en beholder skal startes på nytt) i dette scenariet. Men tilstedeværelsen av beredskapssonden i spesifikasjonen antyder at poden vil starte uten å akseptere noen trafikk og bare akseptere trafikk når sonden begynner å lykkes.

Du kan bruke både livlig og en beredskapssonde hvis appen din er veldig avhengig av backend -tjenester. Beredskapssonden sikrer at hver viktig backend -tjeneste er tilgjengelig, i tillegg til livlighetssonden, som passerer når appen er sunn. Dette forhindrer at trafikken blir sendt til pods som bare kan reagere med feilmeldinger.

En oppstartssonde kan hjelpe hvis containeren din krever lasting av en stor mengde data, konfigurasjonsfiler eller migrasjoner under oppstart. En beredskapssonde er ganske nyttig hvis du vil skille mellom en app som har mislyktes og den andre som fremdeles behandler sine første data.

Forutsetning

Noen få forutsetninger må oppfylles før du bruker Kubernetes beredskapsprober i praksis. Ubuntu 20.0 er et Linux -operativsystem som må installeres først. Fordi Kubernetes på Linux krever det, installer også Minikube -klyngen.

Før vi flytter til kommandolinjeterminalen, må vi først starte Ubuntu 20.04, som allerede er installert. Skriv "Terminal" i Ubuntu 20.04 Systemets søkeboks for raskt å starte terminalen.

Etter det bør Minikube startes. For å starte Minikube, bruk terminalkommandoen “Minikube Start.”Denne kommandoen vil lansere Kubernetes -klyngen og opprette en virtuell maskin som er i stand til å utføre klynge. Utgangen "Minikube Start" -kommandoen er avbildet nedenfor:

Eksempel på Kubernetes Readiness Probes

Vi kan konfigurere et eksempel -app. I dette tilfellet, en enkel Nginx -webserver, for å forstå hvordan beredskapsprober fungerer. Vi har utviklet en grunnleggende distribusjonskonfigurasjon her. Hvert aspekt av konfigurasjonsfilen presenteres i begge vedlagte skjermbilder:

Denne konfigurasjonen bør lagres i en fil som kalles beredskap.Yaml.

Etter det, bruk Kubectl Apply -f Readiness.Yaml for å bruke det. Instruksjonen og utdataene kan sees i følgende skjermbilde:

Vi har nå utviklet en tjeneste for fullstendig forståelse av eksemplet.

Lagre denne konfigurasjonen til SVC.YAML -fil.

Etter det, bruk Kubectl Apply -F SVC.Yaml for å bruke det. Instruksjonen og utdataene kan sees i følgende skjermbilde:

Selv om det ikke er noe spesielt endepunkt for beredskapsprober, kan vi få informasjon om deres nåværende tilstand ved å kjøre KUBECTL Beskriv Pods -kommandoen. Kjør Kubectl Get Pods -kommandoen og sjekk statusen til belgene og andre detaljer.

Pods vises, sammen med deres status og klare stater. Som du ser, kjører poden vår som planlagt. Instruksjonen og utdataene kan sees på skjermdumpen gitt nedenfor:

Resultatet av “Kubectl beskriv pod” er vedlagt nedenfor. Instruksjonen og utdataene kan sees i følgende skjermbilde:

Avsnittet av hendelser vises nederst i utgangen av følgende kommando:

Med Kubectl Get Endpoints -kommandoen, kan vi undersøke endepunktene. Nginx -tjenesten har et endepunkt, som det kan sees. Instruksjonen og utdataene kan sees i følgende skjermbilde:

Vi kan bruke KUBECTL Beskriv endepunkter Nginx -kommandoen for å se mer informasjon. Instruksjonen og utdataene kan sees i følgende skjermbilde:

Anta at vi setter portparameteren for beredskapssonden til 81 og lagre oppsettet. Først må du bekrefte podens status direkte. Staten "løper", som du kan se nedenfor. Instruksjonen og utdataene kan sees i følgende skjermbilde:

Fordi vi ikke har oppdatert Port 81, returnerte den en boolsk verdi av “True”, som vist på skjermbildet nedenfor. Hvis du endrer port 81, og hvis den blir oppdatert, vil den returnere "falsk" som indikerer at Nginx -tjenesten ikke har noen endepunkter fordi beholderen ikke er klar til å motta trafikk. Instruksjonen og utdataene kan sees på skjermdumpen nedenfor.

Konklusjon:

I denne artikkelen er beredskapssondens effekter blitt observert, og parametrene som kan konfigureres. Selv om vi fokuserte på HTTP -sjekken, kan teknikkene vi lærte brukes på noen av de andre testene. For å konfigurere og betjene beredskapsprober, må du først forstå arkitekturen og avhengighetene til applikasjonen din. Vi håper du fant denne artikkelen nyttig. Sjekk de andre Linux -hint -artiklene for flere tips og artikler.