Denne artikkelen fokuserer på oppstartssonder. Oppstartssondenes rolle kan utelukke andre sonder sekvensielt. Det er viktig å i tillegg bruke oppstartssonder ved siden av liv og beredskapsprober. Arbeidsmengden kan ikke endres av oppstartssonden på egen hånd. I denne artikkelen vil du gjennomgå hvordan Kubernetes evaluerer applikasjonens helsetilstand gjennom oppstartssonder og konfigurerer helsekontrollene ved hjelp av oppstartssonder.
Hva er Kubernetes sonder?
Prober kalles også helsekontroller som er teknikken for Kubernetes -applikasjoner for å gi overvåking av den interne tilstanden til applikasjonen ved hjelp av informasjon. De lar klyngen identifisere løpspodene (containere) som overvåker helsen til en applikasjon og sørger for at bare de sunne belgene serverer trafikken.
Programmer kan bli upålitelige av forskjellige årsaker som midlertidig tilkoblingstap, konfigurasjonsfeil og applikasjonsfeil. Utviklere overvåker applikasjonshelsen deres ved hjelp av sonder. Prober hjelper utviklerne til å bli kjent med applikasjonsstatus, ressursutnyttelse og feil. Det er enkelt å fikse applikasjonsproblemer, ressursstyring og organisering av ressurser effektivt ved å overvåke applikasjonsinformasjonen.
Prober brukes til å oppdage følgende:
Hva er typene Kubernetes sonder?
Det er tre typer Kubernetes -sonder. Disse inkluderer:
Livlig sonder
Det er ansvarlig å starte beholderen på nytt hvis den oppdager en dødvakt og ikke svarer.
Beredskapsprober
Det regnes som en dørvakt for innkommende trafikk. Denne sonden er ansvarlig for å fortelle at denne poden er klar til å motta trafikken.
Oppstartprober
Det er ansvarlig for applikasjonen som er distribuert inne i beholderen. Det indikerer om applikasjonen startet vellykket.
Hva er en oppstartssonde?
Kubernetes kan avgjøre om programvaren din, som kjøres i en beholder inne i en pod, har begynt å bruke oppstartssonder ordentlig.
Som du kan se i følgende figur, applikasjonen inne i POD Viktige punkter for oppstartssonder Forutsetninger for å lage oppstartssonde Før du jobber med oppstartssonden, er forutsetninger en Kubernetes-klynge med to noder som ikke fungerer som verter og Kubectl-kommandolinjeprogramvare som må konfigureres for å kommunisere mellom klynger. Hvis du ikke har opprettet en klynge, kan du bruke Minikube til å lage en klynge. Det er andre Kubernetes lekeplasser som er tilgjengelige på nettet som du kan bruke til å lage en klynge. Det er fire grunnleggende Kubernetes -teknikker som støttes av oppstartssonder: Exec: Utfører en kommando i beholderen. Nullkoden indikerer suksess og de andre kodene indikerer feil. Http: Sjekk helsen til søknaden ved hjelp av Get Request -kommandoen. HTTP-sonden anses som sunn hvis responsen er innenfor området [200-399]. Hvis applikasjonen din ikke støtter en HTTP -server, oppretter du HTTP -serveren din i applikasjonen din og svarer på Livende sonde. TCP: Kubernetes åpner forbindelsen mellom en spesifikk TCP -port og en beholder. Hvis forbindelsen er vellykket, aksepterer den trafikken. Ellers klarer det ikke å opprette en forbindelse. TCP -port jobber på vegne av HTTP -sonder når HTTP -sonden ikke kan jobbe. GRPC: Bestemmer om sonden er vellykket ved å sende en GRPC Health Check -forespørsel til en port inne i beholderen og bruke responsen. Suksesskriteriet for sonden og hvor ofte den blir bekreftet styres av noen få grunnleggende variabler: Initialdelayseconds: Angir hvor lang tid som må passere mellom den tiden beholderen starter og første gang sonden brukes (standard: 0, minimum: 0). Periodsekunder: Definerer hvor ofte sonden er sjekket etter den første forsinkelsen (standard: 10, minimum: 1). TimeoutSeconds: Angir hvor lang tid å vente på at sonden skal fullføres og bli merket som mislykket etter at tiden er overskredet (standard: 1, minimum: 1). Failurethreshold: Kubernetes krever at minimum etterfølgende svikt for at sonden blir ansett som usunn hvis den har lyktes. Containeren startes bare på nytt når repetisjonene er usunn (standard: 3, minimum: 1). Hvordan lage en oppstartssonde Oppstartprober er laget ved å legge til en startupprobe -disiplin innen spesifikasjonen.containere del av en pods distinkt. Exec -tilnærmingen brukes i det enkle oppstartssondeeksemplet som er vist på følgende der kommandoen kjører inne i beholderen: Ved å bruke Kubectl, legg poden til klyngen din med følgende kommando: Hvordan beskytte de langsomme startbeholderne med oppstartssonder? Gjennom følgende formel kan du finne lenge nok til å dekke starttidstiden i verste fall: Konklusjon Livlighet, beredskap og oppstartssonder for containerne dine som er distribuert under Kubernetes -containere, må konfigureres på riktig måte hvis du vil opprettholde en sunn Kubernetes -klynge. Dette innlegget konsentrerte seg om oppstartssonden, noe som er avgjørende siden det lar containerne dine varsle Kubernetes når de starter opp og er forberedt på å bli evaluert for liv og beredskap. Det er bra å legge til en oppstartssonde når du bruker liv og beredskapsprober. Ellers kan beholderen bli startet på nytt før de er ferdig med å initialisere. Denne artikkelen implementerer det grunnleggende konfigurasjonsoppsettet til oppstartssonen og beskriver parametrene som kan brukes av sonder.
Sti:/Healthz er helse endepunktet for applicExample-startup-probation. Failurethreshold: 12 er Kubernetes prøver i tilfelle sonden mislykkes. Periodekunder: 12 er hvor ofte inspeksjonen blir utført.> KUBECTL Bruk -f Startup-Probe-Example.yml
Containeren starter og kjører normalt. Du kan validere dette med detaljene som vises i Kubectl:> Failurethreshold * Periodeseconds
Maksimal starttid for applikasjonen er 3 minutter (20 * 10 = 200). Når oppstartssonden lykkes for første gang, fortsetter Livivity -sonden for å gi en rask respons på containerens dødlokker. Beholderen avsluttes etter 200 sekunder og er underlagt podens omstartpolicy hvis oppstartssonen aldri lykkes.