Bästa praxis för Kubernetes. Kontroll av Kubernetes livskraft med hjälp av Readiness- och Liveness-tester

Bästa praxis för Kubernetes. Skapa små containrar
Bästa praxis för Kubernetes. Organisera Kubernetes med namnrymder

Det kan vara svårt att hantera distribuerade system eftersom de innehåller många rörliga och föränderliga komponenter, och alla måste fungera korrekt för att systemets funktionalitet ska upprätthållas. Om en av komponenterna går sönder, måste systemet upptäcka, kringgå och åtgärda den, och allt detta behöver ske automatiskt. I denna serie av "Kubernetes Best Practices" kommer vi att lära oss hur man konfigurerar Readiness- och Liveness-tester för att verifiera livskraften hos Kubernetes-klustret.

Health Check är ett enkelt sätt att låta systemet veta om din applikationsinstans fungerar eller inte. Om din applikationsinstans är nere bör andra tjänster inte kontakta den eller skicka förfrågningar till den. Istället bör förfrågningar skickas till en annan applikationsinstans som redan är igång eller kommer att startas senare. Dessutom bör systemet återföra den förlorade funktionen till din applikation.

Som standard börjar Kubernetes skicka trafik till en pod när alla behållare inuti podden har startat och omstartar behållare när de kraschar. För en början kan detta förvalda beteende av systemet vara tillräckligt bra, men du kan öka tillförlitligheten i din produkts distribution genom att använda anpassade livskontroller.

Lyckligtvis gör Kubernetes detta ganska enkelt, så det finns inga ursäkter för att ignorera sådana kontroller. Kubernetes erbjuder två typer av Health Check-tester, och det är viktigt att förstå skillnaderna i tillämpning av var och en.

Readiness-testet är avsett att informera Kubernetes om din applikation är redo att hantera trafik. Innan tjänsten tillåter att skicka trafik till podden måste Kubernetes säkerställa att Readiness-testet har lyckats. Om Readiness-testet misslyckas kommer Kubernetes att sluta skicka trafik till podden tills testen lyckas.

Liveness-testet informerar Kubernetes om din applikation är levande eller död. I det första fallet kommer Kubernetes att lämna den i fred, och i det andra fallet kommer den döda podden att tas bort och ersättas med en ny.

Låt oss föreställa oss ett scenario där din applikation behöver 1 minut för att "värmas upp" och startas. Din tjänst kommer inte att börja fungera förrän applikationen är helt laddad och igång, även om arbetsflödet redan har börjat. Och du kommer också att stöta på problem om du vill skala denna distribution till flera kopior, eftersom dessa kopior inte bör ta emot trafik förrän de är helt klara. Men som standard kommer Kubernetes att börja skicka trafik så snart processerna inuti containern startar.

När du använder Readiness-testet kommer Kubernetes att vänta tills applikationen är helt igång, och först då tillåter tjänsten att skicka trafik till den nya kopian.

Låt oss föreställa oss ett annat scenario där applikationen hänger ett tag och slutar behandla förfrågningar. Eftersom processen fortsätter att köra kommer Kubernetes som standard att tro att allt är i sin ordning och fortsätta att skicka förfrågningar till den icke-fungerande podden. Men med hjälp av Liveness kommer Kubernetes att upptäcka att applikationen inte längre behandlar förfrågningar och automatiskt starta om den icke-fungerande podden.

Låt oss titta på hur beredskap och livskraft testas. Det finns tre sätt att testa — HTTP, Command och TCP. Du kan använda vilket som helst för verifiering. Det vanligaste sättet för användartest är HTTP-prob.

Även om din applikation inte är en HTTP-server kan du ändå skapa en lättvikts-HTTP-server inuti din applikation för att interagera med Liveness-testet. Därefter kommer Kubernetes att börja pinga podden, och om HTTP-svaret ligger inom intervallet 200 eller 300 ms kommer det att betyda att podden är "frisk". Annars kommer modulen att märkas som "sjuk".

För tester med Command kör Kubernetes ett kommando inuti din container. Om kommandot returnerar med en noll exitskod kommer containern att märkas som frisk, annars, om den får ett exitsstatusnummer från 1 till 255, kommer containern att märkas som "sjuk". Denna typ av testning är användbar om du inte kan eller inte vill köra en HTTP-server, men kan köra ett kommando som kontrollerar "hälsan" i din applikation.

Den sista kontrollmetoden är en TCP-test. Kubernetes kommer att försöka upprätta en TCP-anslutning på den angivna porten. Om det lyckas anses containern vara frisk, om inte – ofungerande. Denna metod kan vara användbar om du använder ett scenario där testning med HTTP-förfrågningar eller kommandon inte fungerar så bra. Till exempel, de primära tjänsterna för att kontrollera med TCP kommer att vara gRPC eller FTP.

Tester kan konfigureras på flera sätt med olika parametrar. Du kan ange hur ofta de ska köras, vad trösklarna för framgång och misslyckande ska vara, samt hur länge du ska vänta på svar. Mer detaljerad information finns i dokumentationen för Readiness och Liveness-tester. Det finns dock en mycket viktig punkt i konfigurationen av Liveness-testet – den initiala fördröjningen för testningen, initialDelaySeconds. Som jag nämnde kan ett misslyckat utförande av detta test leda till att modulen startas om. Därför måste du se till att testningen inte börjar förrän applikationen är redo att köras, annars kommer den att börja startas om cykliskt. Jag rekommenderar att använda P99-starttiden eller genomsnittlig starttid för applikationen från bufferten. Glöm inte att justera detta värde i takt med att starttiden för din applikation blir snabbare eller långsammare.

De flesta specialister kommer att bekräfta att Health Check är en obligatorisk kontroll för alla distribuerade system, och Kubernetes är inget undantag. Användningen av "hälsokontroller" för tjänster säkerställer pålitlig och felfri drift av Kubernetes och innebär ingen ansträngning för användarna.

Fortsättningen kommer snart...

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com