Distribuerte systemer kan være vanskelige å administrere fordi de har mange bevegelige, skiftende elementer som alle må fungere skikkelig for at systemet skal fungere. Hvis ett av elementene svikter, må systemet oppdage det, omgå det og fikse det, og alt dette må gjøres automatisk. I denne Kubernetes Best Practices-serien lærer vi hvordan du setter opp beredskaps- og liveness-tester for å teste helsen til en Kubernetes-klynge.
Helsesjekk er en enkel måte å fortelle systemet om applikasjonsforekomsten din kjører eller ikke. Hvis applikasjonsforekomsten din er nede, bør ikke andre tjenester få tilgang til den eller sende forespørsler til den. I stedet må forespørselen sendes til en annen forekomst av applikasjonen som allerede kjører eller vil bli lansert senere. I tillegg bør systemet gjenopprette den tapte funksjonaliteten til applikasjonen din.
Som standard vil Kubernetes begynne å sende trafikk til en pod når alle containere i podene kjører, og starte containere på nytt når de krasjer. Denne standard systematferden kan være god nok til å begynne med, men du kan forbedre påliteligheten til produktdistribusjonen ved å bruke tilpassede helsekontroller.
Heldigvis gjør Kubernetes dette ganske enkelt å gjøre, så det er ingen unnskyldning for å ignorere disse sjekkene. Kubernetes tilbyr to typer helsesjekker, og det er viktig å forstå forskjellene i hvordan hver av dem brukes.
Beredskapstesten er utformet for å fortelle Kubernetes at applikasjonen din er klar til å håndtere trafikk. Før du lar en tjeneste sende trafikk til en pod, må Kubernetes bekrefte at beredskapskontrollen er vellykket. Hvis beredskapstesten mislykkes, vil Kubernetes slutte å sende trafikk til poden til testen består.
Liveness-testen forteller Kubernetes om applikasjonen din er levende eller død. I det første tilfellet vil Kubernetes la det være i fred, i det andre vil det slette den døde poden og erstatte den med en ny.
La oss forestille oss et scenario der applikasjonen din tar 1 minutt å varme opp og starte. Tjenesten din vil ikke begynne å fungere før applikasjonen er fullastet og kjører, selv om arbeidsflyten allerede har startet. Du vil også få problemer hvis du vil skalere opp denne distribusjonen til flere kopier, fordi disse kopiene ikke skal motta trafikk før de er helt klare. Imidlertid vil Kubernetes som standard begynne å sende trafikk så snart prosessene inne i beholderen begynner.
Når du bruker beredskapstesten, vil Kubernetes vente til applikasjonen kjører fullt ut før den lar tjenesten sende trafikk til den nye kopien.
La oss forestille oss et annet scenario der applikasjonen henger i lang tid, og stopper serviceforespørsler. Ettersom prosessen fortsetter å kjøre, vil Kubernetes som standard anta at alt er bra og fortsette å sende forespørsler til den ikke-fungerende poden. Men når du bruker Liveness, vil Kubernetes oppdage at applikasjonen ikke lenger betjener forespørsler og vil starte den døde poden på nytt som standard.
La oss se på hvordan beredskap og levedyktighet testes. Det er tre testmetoder - HTTP, Command og TCP. Du kan bruke hvilken som helst av dem til å sjekke. Den vanligste måten å teste en bruker på er en HTTP-probe.
Selv om applikasjonen din ikke er en HTTP-server, kan du fortsatt lage en lett HTTP-server inne i applikasjonen din for å samhandle med Liveness-testen. Etter dette vil Kubernetes begynne å pinge poden, og hvis HTTP-responsen er i området 200 eller 300 ms, vil det indikere at poden er frisk. Ellers vil modulen merkes som "usunn".
For kommandotester kjører Kubernetes kommandoen inne i beholderen. Hvis kommandoen returnerer med en null utgangskode, vil beholderen bli merket som sunn, ellers, ved mottak av et utgangsstatusnummer fra 1 til 255, vil beholderen bli merket som "syk". Denne testmetoden er nyttig hvis du ikke kan eller ikke vil kjøre en HTTP-server, men er i stand til å kjøre en kommando som vil sjekke helsen til applikasjonen din.
Den siste verifiseringsmekanismen er TCP-testen. Kubernetes vil prøve å etablere en TCP-tilkobling på den angitte porten. Hvis dette kan gjøres, anses beholderen som sunn, hvis ikke, anses den som ulevedyktig. Denne metoden kan være nyttig hvis du bruker et scenario der testing med en HTTP-forespørsel eller kommandokjøring ikke fungerer veldig bra. For eksempel vil hovedtjenestene for verifisering ved bruk av TCP være gRPC eller FTP.
Tester kan konfigureres på flere måter med forskjellige parametere. Du kan spesifisere hvor ofte de skal utføres, hva suksess- og fiaskoterskelene er, og hvor lenge du skal vente på svar. For mer informasjon, se dokumentasjonen for beredskaps- og livenesstestene. Det er imidlertid ett veldig viktig poeng i å sette opp Liveness-testen - den første innstillingen av testforsinkelsen initialDelaySeconds. Som jeg nevnte, vil feil i denne testen føre til at modulen startes på nytt. Så du må sørge for at testingen ikke starter før applikasjonen er klar til å gå, ellers vil den begynne å sykle gjennom omstarter. Jeg anbefaler å bruke P99-oppstartstiden eller den gjennomsnittlige oppstartstiden for programmet fra bufferen. Husk å justere denne verdien ettersom programmets oppstartstid blir raskere eller langsommere.
De fleste eksperter vil bekrefte at helsesjekker er en obligatorisk sjekk for ethvert distribuert system, og Kubernetes er intet unntak. Å bruke tjenestens helsesjekk sikrer pålitelig, problemfri drift av Kubernetes og er uanstrengt for brukerne.
Fortsettelse snart...
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com