Distribuerade system kan vara svåra att hantera eftersom de har många rörliga, föränderliga element som alla måste fungera korrekt för att systemet ska fungera. Om ett av elementen misslyckas måste systemet upptäcka det, kringgå det och fixa det, och allt detta måste göras automatiskt. I den här Kubernetes Best Practices-serien kommer vi att lära oss hur du ställer in beredskaps- och liveness-tester för att testa hälsan hos ett Kubernetes-kluster.
Health Check är ett enkelt sätt att låta systemet veta om din applikationsinstans körs eller inte. Om din applikationsinstans är nere bör andra tjänster inte komma åt den eller skicka förfrågningar till den. Istället måste begäran skickas till en annan instans av programmet som redan körs eller som kommer att startas senare. Dessutom bör systemet återställa den förlorade funktionaliteten i din applikation.
Som standard kommer Kubernetes att börja skicka trafik till en pod när alla containrar i podarna körs och starta om containrar när de kraschar. Detta standardsystembeteende kan vara tillräckligt bra till att börja med, men du kan förbättra tillförlitligheten för din produktdistribution genom att använda anpassade hälsokontroller.
Lyckligtvis gör Kubernetes detta ganska enkelt att göra, så det finns ingen ursäkt för att ignorera dessa kontroller. Kubernetes tillhandahåller två typer av hälsokontroller, och det är viktigt att förstå skillnaderna i hur var och en används.
Beredskapstestet är utformat för att tala om för Kubernetes att din applikation är redo att hantera trafik. Innan en tjänst tillåter att skicka trafik till en pod måste Kubernetes verifiera att beredskapskontrollen är framgångsrik. Om beredskapstestet misslyckas kommer Kubernetes att sluta skicka trafik till podden tills testet går igenom.
Liveness-testet talar om för Kubernetes om din applikation är levande eller död. I det första fallet kommer Kubernetes att lämna det ifred, i det andra kommer det att radera den döda podden och ersätta den med en ny.
Låt oss föreställa oss ett scenario där din applikation tar 1 minut att värma upp och starta. Din tjänst kommer inte att börja fungera förrän applikationen är helt laddad och körs, även om arbetsflödet redan har startat. Du kommer också att få problem om du vill skala upp den här distributionen 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 processer inuti behållaren startar.
När du använder beredskapstestet kommer Kubernetes att vänta tills applikationen körs fullt ut innan tjänsten låter tjänsten skicka trafik till den nya kopian.
Låt oss föreställa oss ett annat scenario där applikationen hänger sig länge och stoppar serviceförfrågningar. När processen fortsätter att köras kommer Kubernetes som standard att anta att allt är bra och fortsätta skicka förfrågningar till den icke-fungerande poden. Men när du använder Liveness kommer Kubernetes att upptäcka att applikationen inte längre betjänar förfrågningar och kommer att starta om den döda podden som standard.
Låt oss titta på hur beredskap och livsduglighet testas. Det finns tre testmetoder - HTTP, Command och TCP. Du kan använda vilken som helst av dem för att kontrollera. Det vanligaste sättet att testa en användare är en HTTP-sond.
Även om din applikation inte är en HTTP-server kan du fortfarande skapa en lätt HTTP-server i din applikation för att interagera med Liveness-testet. Efter detta kommer Kubernetes att börja pinga podden, och om HTTP-svaret är inom intervallet 200 eller 300 ms kommer det att indikera att poden är frisk. Annars kommer modulen att markeras som "ohälsosam".
För kommandotester kör Kubernetes kommandot inuti din behållare. Om kommandot returnerar med en noll utgångskod kommer behållaren att markeras som frisk, annars kommer behållaren att markeras som "sjuk när du får ett utgångsstatusnummer från 1 till 255". Den här testmetoden är användbar om du inte kan eller vill köra en HTTP-server, men kan köra ett kommando som kontrollerar din applikations tillstånd.
Den sista verifieringsmekanismen är TCP-testet. Kubernetes kommer att försöka upprätta en TCP-anslutning på den angivna porten. Om detta kan göras anses behållaren vara frisk, om inte anses den vara olämplig. Den här metoden kan vara användbar om du använder ett scenario där testning med en HTTP-begäran eller kommandokörning inte fungerar särskilt bra. Till exempel skulle de huvudsakliga tjänsterna för verifiering med TCP vara gRPC eller FTP.
Tester kan konfigureras på flera sätt med olika parametrar. Du kan ange hur ofta de ska utföras, vilka trösklar för framgång och misslyckande är och hur länge du ska vänta på svar. För mer information, se dokumentationen för Readiness and Liveness-testen. Det finns dock en mycket viktig punkt i att ställa in Liveness-testet - den initiala inställningen av testfördröjningen initialDelaySeconds. Som jag nämnde kommer ett misslyckande av detta test att resultera i att modulen startas om. Så du måste se till att testningen inte startar förrän applikationen är redo att gå, annars börjar den gå igenom omstarter. Jag rekommenderar att du använder P99-starttiden eller den genomsnittliga applikationsstarttiden från bufferten. Kom ihåg att justera detta värde eftersom din applikations starttid blir snabbare eller långsammare.
De flesta experter kommer att bekräfta att hälsokontroller är en obligatorisk kontroll för alla distribuerade system, och Kubernetes är inget undantag. Att använda hälsokontroller för tjänster säkerställer tillförlitlig, problemfri drift av Kubernetes och är enkelt för användarna.
Fortsättning snart...
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com