Fordelt systemer kan være svære at administrere, fordi de har mange flygtige, ændrede elementer, der alle skal fungere korrekt for at sikre systemets funktionalitet. Hvis et af elementerne fejler, skal systemet opdage det, omgå det og rette det, og dette skal ske automatisk. I denne serie ‘Kubernetes Bedste Praksis’ vil vi lære, hvordan man konfigurerer Readiness- og Liveness-tests til at verificere, at Kubernetes-klyngen er levedygtig.
Sundhedstjek Health Check er en enkel måde for systemet at vide, om dit applikationsinstans fungerer eller ej. Hvis dit applikationsinstans ikke fungerer, bør andre tjenester ikke kontakte det eller sende forespørgsler til det. I stedet skal forespørgslen sendes til et andet applikationsinstans, som allerede kører eller vil køre senere. Derudover skal systemet returnere den tabte funktionalitet til din applikation.
Som standard begynder Kubernetes at sende trafik til en pod, når alle containere inden for pods er startet, og genstarter containere, når de fejler. I begyndelsen kan denne adfærd være tilstrækkelig, men du kan forbedre pålideligheden af din produktudrulning ved at bruge brugerdefinerede sundhedstjek.
Heldigvis gør Kubernetes det ret enkelt, så der er ingen undskyldninger for at ignorere disse tjek. Kubernetes tilbyder to typer Health Check, og det er vigtigt at forstå forskellene i anvendelsen af hver.
Readiness-testen er designet til at informere Kubernetes om, at din applikation er klar til at håndtere trafik. Før Kubernetes tillader tjenesten at sende trafik til pod'en, skal det sikre sig, at Readiness-testen er bestået. Hvis Readiness-testen fejler, vil Kubernetes stoppe med at sende trafik til pod'en, indtil testen er bestået.
Liveness-testet informerer Kubernetes om, hvorvidt din applikation er i live eller død. I det første tilfælde vil Kubernetes lade den være i fred, i det andet tilfælde vil den fjerne den døde pod og erstatte den med en ny.
Lad os forestille os et scenarie, hvor din applikation skal "opvarmes" og starte i 1 minut. Din service vil ikke begynde at fungere, før applikationen er helt indlæst og startet, selvom arbejdsprocessen allerede er begyndt. Du vil også opleve problemer, hvis du ønsker at skalere denne udrulning til flere kopier, for disse kopier må ikke modtage trafik, før de er helt klar. Men som standard vil Kubernetes begynde at sende trafik, så snart processerne inde i containeren starter.
Når du bruger readiness-testen, vil Kubernetes vente, indtil applikationen er helt startet, og først derefter tillade servicen at sende trafik til den nye kopi.
Lad os forestille os et andet scenarie, hvor applikationen hænger i lang tid og stopper med at betjene anmodninger. Da processen fortsætter med at køre, vil Kubernetes som standard tro, at alt er i orden, og fortsætte med at sende anmodninger til den ikke-fungerende pod. Men ved at bruge Liveness vil Kubernetes opdage, at applikationen ikke længere betjener anmodninger, og som standard genstarter den den ikke-fungerende pod.
Lad os se på, hvordan readiness og liveness testes. Der er tre måder at teste på - HTTP, Command og TCP. Du kan bruge en hvilken som helst af dem til at verificere. Den mest almindelige metode til bruger-test er HTTP probe.
Selv hvis din applikation ikke er en HTTP-server, kan du stadig oprette en letvægts HTTP-server inden i din applikation for at interagere med Liveness-testen. Derefter vil Kubernetes begynde at pinge pod'en, og hvis HTTP-svaret ligger inden for 200 eller 300 ms, betyder det, at pod'en er "sund". Ellers vil modulet blive markeret som "usundt".
Til tests kører Kubernetes en kommando inde i din container. Hvis kommandoen returnerer med en nul exit-kode, vil containeren blive markeret som sund; i modsætning hertil, ved modtagelse af et exit-statusnummer fra 1 til 255, vil containeren blive markeret som 'syg'. Denne testmetode er nyttig, hvis du ikke kan eller ikke ønsker at køre en HTTP-server, men kan køre en kommando, der kontrollerer 'sundheden' af din applikation.
Den sidste kontrolmekanisme er TCP-testen. Kubernetes vil forsøge at etablere en TCP-forbindelse på den angivne port. Hvis dette lykkes, betragtes containeren som sund; hvis ikke, anses den for usund. Denne metode kan være nyttig, hvis du bruger et scenarie, hvor test med HTTP-anmodninger eller udførelse af kommandoer ikke fungerer særlig godt. For eksempel vil gRPC eller FTP være de primære tjenester til TCP-test.
Tests kan konfigureres på flere måder med forskellige parametre. Du kan angive, hvor ofte de skal udføres, hvad succeskriterierne og fejlkriterierne er, og hvor længe der skal ventet på svar. Flere oplysninger findes i dokumentationen til Readiness- og Liveness-tests. Der er dog et meget vigtigt aspekt ved konfigurationen af Liveness-testen – den indledende installationsforsinkelse initialDelaySeconds. Som jeg nævnte, vil en mislykket udførelse af denne test føre til genstart af modulet. Derfor skal du sikre, at testningen ikke begynder, før applikationen er klar til drift; ellers vil den begynde at genstarte cyklisk. Jeg anbefaler at bruge P99-startoptid eller den gennemsnitlige opstartstid for applikationen fra hurtigbufferen. Husk at justere denne værdi, da opstartstiden for din applikation bliver hurtigere eller langsommere.
De fleste fagfolk vil bekræfte, at Health Check er en obligatorisk test for ethvert distribueret system, og Kubernetes er ingen undtagelse. Brug af 'sundheds' kontroller for tjenester sikrer en pålidelig og fejlfri drift af Kubernetes og udgør ikke nogen besvær for brugerne.
Fortsættelsen kommer snart…
Lidt reklame 🙂
Tak fordi du bliver hos os. Kan du lide vores artikler? Ønsker du at se flere interessante materialer? Støt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan
Kilde: habr.com
