Gedecentraliseerde systemen zijn moeilijk te beheren vanwege de vele dynamische elementen die erin aanwezig zijn, en al deze elementen moeten goed functioneren om ervoor te zorgen dat het systeem functioneert. Als een van de elementen faalt, moet het systeem dit detecteren, omzeilen en corrigeren, en dit moet allemaal automatisch worden gedaan. In deze serie 'Kubernetes Best Practices' leren we hoe we Readiness- en Liveness-tests kunnen configureren om de levensvatbaarheid van een Kubernetes-cluster te controleren.
Health Check is een eenvoudige manier om het systeem te laten weten of de instantie van uw applicatie functioneert of niet. Als de instantie van uw applicatie niet functioneert, mogen andere diensten deze niet benaderen of verzoeken naar deze instantie sturen. In plaats daarvan moet het verzoek naar een andere instantie van de applicatie worden gestuurd, die al draait of later zal draaien. Bovendien moet het systeem uw applicatie teruggeven naar de verworven functionaliteit.
Standaard begint Kubernetes verkeer naar een pod te sturen wanneer alle containers binnen de pods zijn gestart, en herstart het containers wanneer ze crashen. Aanvankelijk kan dit standaardgedrag van het systeem goed genoeg zijn, maar u kunt de betrouwbaarheid van uw productimplementatie verhogen door gebruik te maken van aangepaste gezondheidscontroles.
Gelukkig maakt Kubernetes het vrij eenvoudig, zodat er geen excuses zijn voor het negeren van dergelijke controles. Kubernetes biedt twee soorten Health Check-tests en het is belangrijk om de verschillen in het gebruik van elk ervan te begrijpen.
De Readiness-test is bedoeld om Kubernetes te informeren over de gereedheid van uw applicatie om verkeer te verwerken. Voordat een service verkeer naar een pod toestaat, moet Kubernetes verifiƫren dat de Readiness-test succesvol is. Als de Readiness-test faalt, stopt Kubernetes met het verzenden van verkeer naar de pod totdat de test succesvol is.
De Liveness-levensvatbaarheidstest informeert Kubernetes of uw applicatie actief of inactief is. In het eerste geval laat Kubernetes deze met rust, in het tweede geval verwijdert het de inactieve pod en vervangt deze door een nieuwe.
Stel je voor dat je applicatie een opwarmperiode van 1 minuut nodig heeft voordat deze volledig draait. Je service begint niet met werken totdat de applicatie volledig is geladen en gestart, hoewel het werkproces al is begonnen. Bovendien zult u ook problemen ondervinden als u deze implementatie wilt opschalen naar meerdere exemplaren, omdat deze exemplaren geen verkeer mogen ontvangen totdat ze volledig klaar zijn. Standaard begint Kubernetes echter onmiddellijk met het verzenden van verkeer zodra de processen binnen de container starten.
Bij gebruik van de Readiness-test wacht Kubernetes totdat de applicatie volledig is opgestart en staat het de service alleen daarna toe om verkeer naar de nieuwe kopie te sturen.
Stel je een ander scenario voor waarbij de applicatie lange tijd vastloopt en geen verzoeken meer verwerkt. Aangezien het proces doorgaat met uitvoeren, zal Kubernetes standaard aannemen dat alles in orde is en doorgaan met het verzenden van verzoeken naar de niet-functionerende pod. Maar met Liveness zal Kubernetes ontdekken dat de applicatie geen verzoeken meer verwerkt en de niet-functionerende pod standaard opnieuw opstarten.
Laten we bekijken hoe we de gereedheid en levensvatbaarheid testen. Er zijn drie manieren om te testen ā HTTP, Command en TCP. U kunt een van deze methoden gebruiken voor de verificatie. De meest voorkomende manier van gebruikerstests is de HTTP-probe.
Zelfs als uw applicatie geen HTTP-server is, kunt u nog steeds een lichte HTTP-server binnen uw applicatie maken voor interactie met de Liveness-test. Daarna zal Kubernetes de pod beginnen te pingen, en als de HTTP-respons binnen de 200 of 300 ms valt, betekent dit dat de pod 'gezond' is. Anders wordt de module gemarkeerd als 'ongeschikt'.
Voor tests met behulp van Command voert Kubernetes de opdracht uit binnen uw container. Als de opdracht retourneert met een exitcode van nul, wordt de container als gezond gemarkeerd; in andere gevallen, bij een exitstatus van 1 tot 255, wordt de container als 'ziek' gemarkeerd. Deze testmethode is nuttig als u geen HTTP-server kunt of wilt starten, maar wel een opdracht kunt uitvoeren die de 'gezondheid' van uw applicatie controleert.
De laatste controlemechanisme is de TCP-test. Kubernetes zal proberen een TCP-verbinding op de opgegeven poort tot stand te brengen. Als dit lukt, wordt de container als gezond beschouwd; als dit niet lukt, als onbruikbaar. Deze methode kan van pas komen als u een scenario gebruikt waarbij testen met een HTTP-aanroep of het uitvoeren van een opdracht niet goed werkt. Bijvoorbeeld, de belangrijkste services voor controle via TCP zijn gRPC of FTP.
Tests kunnen op verschillende manieren worden ingesteld met verschillende parameters. U kunt opgeven hoe vaak ze moeten worden uitgevoerd, wat de drempelwaarden voor succes en falen zijn, en hoe lang op antwoorden moet worden gewacht. Meer gedetailleerde informatie is te vinden in de documentatie voor Readiness- en Liveness-tests. Echter, er is Ć©Ć©n heel belangrijk punt bij het instellen van de Liveness-test ā de initiĆ«le vertraging initialDelaySeconds. Zoals ik al zei, zal een mislukte uitvoering van deze test leiden tot herstarten van de module. Daarom moet u ervoor zorgen dat de test niet begint totdat de applicatie klaar is voor gebruik, anders zal deze in een herstartcyclus terechtkomen. Ik raad aan de P99-opstarttijd of de gemiddelde opstarttijd van de applicatie uit de buffer te gebruiken. Vergeet niet deze waarde aan te passen naarmate de opstarttijd van uw applicatie sneller of langzamer wordt.
De meeste specialisten bevestigen dat Health Checks een essentiƫle controle zijn voor elke gedistribueerd systeem, en Kubernetes is daarop geen uitzondering. Het gebruik van 'gezond' controleren van services waarborgt de betrouwbare en foutloze werking van Kubernetes en is voor gebruikers geen klus.
De voortzetting volgt zeer binnenkort...
Een beetje reclame š
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 ā 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB ā vanaf $99! Lees over hoe
Bron: habr.com
