Gedistribueerde systemen kunnen moeilijk te beheren zijn omdat ze veel bewegende, veranderende elementen bevatten die allemaal goed moeten werken om het systeem te laten functioneren. Als een van de elementen faalt, moet het systeem dit detecteren, omzeilen en repareren, en dit alles moet automatisch gebeuren. In deze serie Kubernetes Best Practices leren we hoe u Readiness- en Liveness-tests kunt instellen om de gezondheid van een Kubernetes-cluster te testen.
Health Check is een eenvoudige manier om het systeem te laten weten of uw applicatie-exemplaar actief is of niet. Als uw toepassingsexemplaar niet beschikbaar is, mogen andere services er geen toegang toe hebben en er geen verzoeken naartoe sturen. In plaats daarvan moet het verzoek worden verzonden naar een ander exemplaar van de applicatie dat al actief is of later zal worden gestart. Bovendien moet het systeem de verloren functionaliteit van uw applicatie herstellen.
Standaard begint Kubernetes met het verzenden van verkeer naar een pod wanneer alle containers in de pods actief zijn, en worden containers opnieuw opgestart wanneer ze crashen. Dit standaardsysteemgedrag is in het begin misschien goed genoeg, maar u kunt de betrouwbaarheid van uw productimplementatie verbeteren door aangepaste sanity checks te gebruiken.
Gelukkig maakt Kubernetes dit vrij eenvoudig, dus er is geen excuus om deze controles te negeren. Kubernetes biedt twee soorten Health Checks, en het is belangrijk om de verschillen te begrijpen in de manier waarop deze worden gebruikt.
De Readiness-test is ontworpen om Kubernetes te laten weten dat uw applicatie klaar is om verkeer te verwerken. Voordat een service verkeer naar een pod mag sturen, moet Kubernetes verifiëren dat de gereedheidscontrole succesvol is. Als de gereedheidstest mislukt, stopt Kubernetes met het verzenden van verkeer naar de pod totdat de test slaagt.
De Liveness-test vertelt Kubernetes of uw applicatie levend of dood is. In het eerste geval zal Kubernetes het met rust laten, in het tweede geval zal het de dode pod verwijderen en vervangen door een nieuwe.
Laten we ons een scenario voorstellen waarin uw toepassing één minuut nodig heeft om op te warmen en te starten. Uw service begint pas te werken als de applicatie volledig is geladen en actief is, ook al is de workflow al gestart. U zult ook problemen ondervinden als u deze implementatie wilt opschalen naar meerdere exemplaren, omdat deze kopieën pas verkeer mogen ontvangen als ze volledig gereed zijn. Standaard begint Kubernetes echter met het verzenden van verkeer zodra processen in de container beginnen.
Bij gebruik van de Readiness-test wacht Kubernetes totdat de applicatie volledig draait voordat de service verkeer naar de nieuwe kopie kan sturen.
Laten we ons een ander scenario voorstellen waarin de applicatie lange tijd blijft hangen, waardoor serviceverzoeken worden stopgezet. Terwijl het proces doorgaat, gaat Kubernetes er standaard van uit dat alles in orde is en blijft het verzoeken sturen naar de niet-werkende pod. Maar wanneer Liveness wordt gebruikt, zal Kubernetes detecteren dat de applicatie niet langer verzoeken verwerkt en de dode pod standaard opnieuw opstarten.
Laten we eens kijken hoe de gereedheid en levensvatbaarheid worden getest. Er zijn drie testmethoden: HTTP, Command en TCP. U kunt ze allemaal gebruiken om te controleren. De meest gebruikelijke manier om een gebruiker te testen is een HTTP-test.
Zelfs als uw applicatie geen HTTP-server is, kunt u nog steeds een lichtgewicht HTTP-server in uw applicatie maken voor interactie met de Liveness-test. Hierna begint Kubernetes de pod te pingen en als het HTTP-antwoord binnen het bereik van 200 of 300 ms ligt, geeft dit aan dat de pod in orde is. Anders wordt de module gemarkeerd als "ongezond".
Voor opdrachttests voert Kubernetes de opdracht uit in uw container. Als het commando terugkeert met een exitcode van nul, wordt de container gemarkeerd als gezond. Anders wordt de container bij ontvangst van een exitstatusnummer van 1 tot 255 gemarkeerd als 'ziek'. Deze testmethode is handig als u geen HTTP-server kunt of wilt uitvoeren, maar wel een opdracht kunt uitvoeren die de status van uw applicatie controleert.
Het laatste verificatiemechanisme is de TCP-test. Kubernetes zal proberen een TCP-verbinding tot stand te brengen op de opgegeven poort. Als dit mogelijk is, wordt de container als gezond beschouwd; als dit niet het geval is, wordt deze als niet-levensvatbaar beschouwd. Deze methode kan handig zijn als u een scenario gebruikt waarin testen met een HTTP-verzoek of opdrachtuitvoering niet erg goed werkt. De belangrijkste services voor verificatie met TCP zijn bijvoorbeeld gRPC of FTP.
Tests kunnen op verschillende manieren worden geconfigureerd met verschillende parameters. U kunt opgeven hoe vaak ze moeten worden uitgevoerd, wat de succes- en faaldrempels zijn en hoe lang u op reacties moet wachten. Zie voor meer informatie de documentatie voor de Readiness- en Liveness-tests. Er is echter één heel belangrijk punt bij het opzetten van de Liveness-test: de initiële instelling van de testvertraging initialDelaySeconds. Zoals ik al zei, zal het mislukken van deze test ertoe leiden dat de module opnieuw wordt opgestart. U moet er dus voor zorgen dat het testen pas begint als de applicatie gereed is voor gebruik, anders zal de applicatie opnieuw worden opgestart. Ik raad aan om de opstarttijd van P99 of de gemiddelde opstarttijd van applicaties uit de buffer te gebruiken. Vergeet niet deze waarde aan te passen naarmate de opstarttijd van uw toepassing sneller of langzamer wordt.
De meeste experts zullen bevestigen dat Health Checks een verplichte controle zijn voor elk gedistribueerd systeem, en Kubernetes vormt daarop geen uitzondering. Het gebruik van servicestatuschecks zorgt voor een betrouwbare, probleemloze werking van Kubernetes en is moeiteloos voor gebruikers.
Wordt zeer binnenkort vervolgd...
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com