Distribuerede systemer kan være svære at administrere, fordi de har mange bevægelige, skiftende elementer, som alle skal fungere korrekt, for at systemet kan fungere. Hvis et af elementerne svigter, skal systemet detektere det, omgå det og reparere det, og alt dette skal gøres automatisk. I denne Kubernetes Best Practices-serie lærer vi, hvordan du opsætter Readiness and Liveness-tests for at teste sundheden for en Kubernetes-klynge.
Health Check er en enkel måde at lade systemet vide, om din applikationsinstans kører eller ej. Hvis din applikationsforekomst er nede, bør andre tjenester ikke få adgang til den eller sende anmodninger til den. I stedet skal anmodningen sendes til en anden forekomst af applikationen, der allerede kører eller vil blive lanceret senere. Derudover bør systemet gendanne den tabte funktionalitet af din applikation.
Som standard vil Kubernetes begynde at sende trafik til en pod, når alle containere i podsene kører, og genstarte containere, når de går ned. Denne standardsystemadfærd kan være god nok til at begynde med, men du kan forbedre pålideligheden af din produktimplementering ved at bruge tilpassede sundhedstjek.
Heldigvis gør Kubernetes dette ret nemt at gøre, så der er ingen undskyldning for at ignorere disse kontroller. Kubernetes tilbyder to typer helbredstjek, og det er vigtigt at forstå forskellene i, hvordan de hver især bruges.
Readiness-testen er designet til at fortælle Kubernetes, at din applikation er klar til at håndtere trafik. Før Kubernetes tillader en tjeneste at sende trafik til en pod, skal Kubernetes bekræfte, at klarhedskontrollen er vellykket. Hvis parathedstesten mislykkes, stopper Kubernetes med at sende trafik til poden, indtil testen består.
Liveness-testen fortæller Kubernetes, om din applikation er levende eller død. I det første tilfælde vil Kubernetes lade det være, i det andet vil det slette den døde pod og erstatte det med en ny.
Lad os forestille os et scenarie, hvor din applikation tager 1 minut at varme op og starte. Din tjeneste begynder ikke at fungere, før applikationen er fuldt indlæst og kører, selvom arbejdsgangen allerede er startet. Du vil også have problemer, hvis du vil skalere denne implementering op til flere kopier, fordi disse kopier ikke bør modtage trafik, før de er helt klar. Men som standard vil Kubernetes begynde at sende trafik, så snart processer inde i containeren starter.
Når du bruger Readiness-testen, vil Kubernetes vente, indtil applikationen kører fuldt ud, før den tillader tjenesten at sende trafik til den nye kopi.
Lad os forestille os et andet scenarie, hvor applikationen hænger i lang tid og stopper serviceanmodninger. Da processen fortsætter med at køre, vil Kubernetes som standard antage, at alt er i orden og fortsætte med at sende anmodninger til den ikke-fungerende pod. Men når du bruger Liveness, vil Kubernetes registrere, at applikationen ikke længere leverer anmodninger og genstarter den døde pod som standard.
Lad os se på, hvordan beredskab og levedygtighed testes. Der er tre testmetoder - HTTP, Command og TCP. Du kan bruge enhver af dem til at tjekke. Den mest almindelige måde at teste en bruger på er en HTTP-probe.
Selvom din applikation ikke er en HTTP-server, kan du stadig oprette en letvægts-HTTP-server inde i din applikation for at interagere med Liveness-testen. Herefter vil Kubernetes begynde at pinge poden, og hvis HTTP-svaret er i intervallet 200 eller 300 ms, vil det indikere, at poden er sund. Ellers vil modulet blive markeret som "usundt".
Til kommandotests kører Kubernetes kommandoen inde i din container. Hvis kommandoen vender tilbage med en nul udgangskode, vil containeren blive markeret som sund, ellers vil containeren blive markeret som "syg" ved modtagelse af et udgangsstatusnummer fra 1 til 255. Denne testmetode er nyttig, hvis du ikke kan eller ønsker at køre en HTTP-server, men er i stand til at køre en kommando, der kontrollerer dit programs tilstand.
Den endelige verifikationsmekanisme er TCP-testen. Kubernetes vil forsøge at etablere en TCP-forbindelse på den angivne port. Hvis dette kan lade sig gøre, anses beholderen for at være sund, hvis ikke, anses den for at være ulevedygtig. Denne metode kan være nyttig, hvis du bruger et scenario, hvor test med en HTTP-anmodning eller kommandoudførelse ikke fungerer særlig godt. For eksempel vil de vigtigste tjenester til verifikation ved hjælp af TCP være gRPC eller FTP.
Test kan konfigureres på flere måder med forskellige parametre. Du kan angive, hvor ofte de skal udføres, hvad tærsklerne for succes og fiasko er, og hvor længe du skal vente på svar. For mere information, se dokumentationen til paratheds- og livenesstestene. Der er dog et meget vigtigt punkt i opsætningen af Liveness-testen - den indledende indstilling af testforsinkelsen initialDelaySeconds. Som jeg nævnte, vil fejl i denne test resultere i, at modulet genstartes. Så du skal sikre dig, at testen ikke starter, før applikationen er klar til at gå, ellers vil den begynde at cykle gennem genstarter. Jeg anbefaler at bruge P99-starttiden eller den gennemsnitlige applikationsstarttid fra bufferen. Husk at justere denne værdi, da din applikations opstartstid bliver hurtigere eller langsommere.
De fleste eksperter vil bekræfte, at sundhedstjek er et obligatorisk tjek for ethvert distribueret system, og Kubernetes er ingen undtagelse. Brug af servicesundhedstjek sikrer pålidelig, problemfri drift af Kubernetes og er ubesværet for brugerne.
Fortsættes meget snart...
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com