Een belangrijk punt bij de werking van gedistribueerde systemen is de afhandeling van storingen. Kubernetes helpt hierbij door controllers in te zetten die de gezondheid van uw systeem monitoren en services die niet meer werken opnieuw opstarten. Kubernetes kan uw applicaties echter geforceerd stopzetten om de algehele systeemgezondheid te garanderen. In deze serie bekijken we hoe u Kubernetes kunt helpen zijn werk efficiënter te doen en de downtime van applicaties te verminderen.
Vóór containers draaiden de meeste applicaties op virtuele of fysieke machines. Als de applicatie crashte of vastliep, duurde het lang om de lopende taak te annuleren en het programma opnieuw te laden. In het ergste geval moest iemand dit probleem 's nachts, op de meest ongelegen uren, handmatig oplossen. Als slechts 1-2 werkende machines een belangrijke taak zouden uitvoeren, was een dergelijke verstoring volkomen onaanvaardbaar.
Daarom begonnen ze, in plaats van handmatig opnieuw opstarten, monitoring op procesniveau te gebruiken om de applicatie automatisch opnieuw te starten in het geval van een abnormale beëindiging. Als het programma mislukt, vangt het monitoringproces de exitcode op en start de server opnieuw op. Met de komst van systemen als Kubernetes werd dit soort reactie op systeemstoringen eenvoudigweg geïntegreerd in de infrastructuur.
Kubernetes maakt gebruik van een gebeurtenislus om het verschil te observeren en actie te ondernemen om ervoor te zorgen dat bronnen gezond blijven terwijl ze van containers naar de knooppunten zelf reizen.
Dit betekent dat u de procesbewaking niet langer handmatig hoeft uit te voeren. Als een resource de Health Check niet doorstaat, voorziet Kubernetes deze eenvoudigweg automatisch van een vervanging. Kubernetes doet echter veel meer dan alleen uw applicatie monitoren op fouten. Het kan meer kopieën van de applicatie maken om op meerdere machines te draaien, de applicatie bijwerken of meerdere versies van uw applicatie tegelijkertijd uitvoeren.
Daarom zijn er veel redenen waarom Kubernetes een perfect gezonde container kan beëindigen. Als u bijvoorbeeld uw implementatie upgradet, stopt Kubernetes langzaam oude pods terwijl nieuwe worden gestart. Als u een knooppunt afsluit, stopt Kubernetes met het uitvoeren van alle pods op dat knooppunt. Ten slotte, als een knooppunt geen bronnen meer heeft, zal Kubernetes alle pods afsluiten om die bronnen vrij te maken.
Daarom is het van cruciaal belang dat uw applicatie wordt beëindigd met minimale gevolgen voor de eindgebruiker en minimale hersteltijd. Dit betekent dat het voordat het wordt uitgeschakeld alle gegevens moet opslaan die moeten worden opgeslagen, alle netwerkverbindingen moet sluiten, het resterende werk moet voltooien en andere urgente taken moet beheren.
In de praktijk betekent dit dat uw applicatie het SIGTERM-bericht moet kunnen verwerken, het procesbeëindigingssignaal dat het standaardsignaal is voor het kill-hulpprogramma op Unix-besturingssystemen. Wanneer u dit bericht ontvangt, moet de toepassing worden afgesloten.
Zodra Kubernetes besluit een pod te beëindigen, vinden er een aantal gebeurtenissen plaats. Laten we eens kijken naar elke stap die Kubernetes neemt bij het afsluiten van een container of pod.
Laten we zeggen dat we een van de pods willen beëindigen. Op dit punt zal het geen nieuw verkeer meer ontvangen. De containers die in de pod draaien, worden niet beïnvloed, maar al het nieuwe verkeer wordt geblokkeerd.
Laten we eens kijken naar de preStop hook, een speciaal commando of HTTP-verzoek dat naar containers in een pod wordt verzonden. Als uw applicatie niet correct wordt afgesloten bij ontvangst van SIGTERM, kunt u preStop gebruiken om correct af te sluiten.
De meeste programma's worden netjes afgesloten als ze een SIGTERM-signaal ontvangen, maar als je code van derden gebruikt of een systeem dat je niet volledig beheert, is de preStop-hook een prima manier om netjes af te sluiten zonder de applicatie te wijzigen.
Na het uitvoeren van deze hook stuurt Kubernetes een SIGTERM-signaal naar de containers in de pod, om hen te laten weten dat de verbinding binnenkort wordt verbroken. Zodra u dit signaal ontvangt, gaat uw code verder met het afsluitproces. Dit proces kan het stoppen van langlevende verbindingen omvatten, zoals een databaseverbinding of WebSocket-stream, het opslaan van de huidige status en dergelijke.
Zelfs als u een preStop-hook gebruikt, is het erg belangrijk om te controleren wat er precies met uw applicatie gebeurt wanneer u deze een SIGTERM-signaal verzendt, en hoe deze zich gedraagt, zodat gebeurtenissen of veranderingen in de werking van het systeem die worden veroorzaakt door het afsluiten van een pod niet als gevolg van een pod-uitschakeling optreden. een verrassing voor jou.
Op dit punt wacht Kubernetes een bepaalde tijd, terminatieGracePeriodSecond, of de periode voor het netjes afsluiten wanneer het een SIGTERM-signaal ontvangt, voordat verdere actie wordt ondernomen.
Standaard bedraagt deze periode 30 seconden. Het is belangrijk op te merken dat het parallel loopt met de preStop-haak en het SIGTERM-signaal. Kubernetes wacht niet tot de preStop hook en SIGTERM zijn beëindigd. Als uw applicatie wordt afgesloten voordat de TerminationGracePeriod eindigt, gaat Kubernetes onmiddellijk door naar de volgende stap. Controleer daarom of de waarde van deze periode in seconden niet korter is dan de tijd die nodig is om de pod correct uit te schakelen, en als deze langer is dan 30 seconden, verhoog dan de periode naar de gewenste waarde in YAML. In het gegeven voorbeeld is dat 60s.
En tot slot is de laatste stap dat als containers na beëindiging van GracePeriod nog steeds actief zijn, ze een SIGKILL-signaal zullen sturen en met geweld zullen worden verwijderd. Op dit punt zal Kubernetes ook alle andere pod-objecten opruimen.
Kubernetes beëindigt pods om vele redenen, dus zorg ervoor dat uw applicatie in elk geval correct wordt beëindigd om een stabiele service te garanderen.
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