Kubernetes Gereedheid & levendigheid Probes - Best Practices

In Kubernetes zijn pods de kleinste inzetbare rekeneenheden die kunnen worden gemaakt en beheerd. Een pod is een groep van een of meer containers (Docker, raket, enz.), Met gedeelde opslag / netwerk en een specificatie voor het uitvoeren van de containers.

Gereedheid en levendigheid Probes kunnen generiek worden genoemd in Kubernetes-context Health Checks. Containersondes zijn kleine processen die periodiek worden uitgevoerd. Het resultaat van deze sondes (Succes, Mislukt of Onbekend) bepaalt het perspectief van Kubernetes op de status van de container. Op basis hiervan beslist Kubernetes hoe elke container moet worden behandeld om de veerkracht, hoge beschikbaarheid en hogere uptime te behouden.

Gezondheidschecks zijn een vereiste voor elk gedistribueerd systeem!

Kubernetes gezondheidscontroles:

Kubernetes biedt twee soorten gezondheidscontroles: gereedheid en levendigheid, en beide hebben hun eigen doel. In de context van dit artikel zal kiezen:

  • /.well-known/live - voor HTTP live-probe
  • /.well-known/ready - voor HTTP-ready probe

Kort gezegd betekent HTTP-sondering dat Kubernetes met specifieke tijdsintervallen HTTP-aanvragen uitvoert op /.well-known/live en /.well-known/ready. De statuscode van het antwoord wordt gebruikt om te beslissen wat er met de pod moet worden gedaan. Als de statuscode binnen het interval [200, 300) ligt, is alles in orde. Anders:

  • als de statuscode voor de live probe 4xx of 5xx is, wordt de pod opnieuw gestart
  • Als de statuscode voor de ready-probe 4xx of 5xx is, wordt de pod gemarkeerd als ongezond en wordt HTTP-verkeer hier niet meer naartoe geleid voor een grotere betrouwbaarheid en uptime.
Als containers onafhankelijk zijn van back-updiensten, kunnen containers op dezelfde afhandelaar worden gecontroleerd en gereed zijn voor controle en is wat volgt niet van toepassing.

Samen met teamgenoten van Metro Systems Romania - Site Reliability Team hebben we een lijst met best practices voor de Health Checks geïdentificeerd en hebben we de applicatieontwikkelaars geadviseerd deze te volgen. Dergelijke best practices zijn:

  1. Live & Ready-handlers moeten onafhankelijke functies zijn!

Zoals eerder vermeld, moeten voor elk product dat in een Kubernetes-context wordt geïmplementeerd, 2 handlers die op HTTP-oproepen "live" en "ready" beantwoorden, worden geïmplementeerd. De eerste beste praktijk met betrekking tot deze sondes is dat elke handler zijn eigen functie moet hebben geïmplementeerd.

2. Koppel de logica voor "live" / "ready" niet los van uw toepassing!

Dit is van toepassing op apps voor taakverwerking. Voor Kubernetes is het belangrijk om te weten of de verwerkingsapp actief is of niet. Als de logica voor live / ready in een nieuw proces is ontkoppeld, is het resultaat niet overtuigend.

3. Voer geen logica uit op de "live" -handler. Het moet status 200 retourneren als de hoofdthread actief is en 5xx als dat niet het geval is.

Deze sonde laat Kubernetes weten of de toepassing levend of dood is. De beslissing wordt genomen door de statuscode voor /.well-known/live te controleren en als de toepassing dood wordt verklaard, start Kubernetes de pod opnieuw. Vanuit het oogpunt van betrouwbaarheid moet de respons voor live-sonde waar zijn als de hoofdthread van de app actief is en anders onwaar.

In deze context betekent "logica" het implementeren van een soort controles op de onderling verbonden diensten.

4. Implementeer logica in de "ready" -handler om een ​​volledig antwoord te bieden over de gereedheid van de app.

Ready-sonde laat Kubernetes weten of de pod klaar is om HTTP-verkeer te ontvangen. Als ontwikkelaar is het belangrijk om hier wat logica te implementeren om de beschikbaarheid van al uw backend-afhankelijkheden voor de toepassing te controleren. Wanneer de "ready" -handler is geïmplementeerd, is het erg belangrijk om duidelijk te weten wat ready echt betekent voor uw toepassing. Met andere woorden, op de "ready" -handler is het belangrijk om alle stappen uit te voeren die bepalen dat de app klaar is om https-aanvragen te ontvangen en te verwerken. Als de toepassing bijvoorbeeld een verbinding met een database moet maken om gereed te zijn voor het verwerken van HTTP-aanvragen, is een gereedheidssonde essentieel om te controleren of de verbinding met de database tot stand is gebracht en klaar is voor gebruik.

Laten we een specifiek geval bekijken: de toepassing loopt vast bij het verwerken van een afzonderlijke thread, maar de hoofdthread werkt goed. Als ontwikkelaar weet je dat een pod-herstart het probleem zal oplossen en dat je Kubernetes kunt overtuigen om het automatisch voor je uit te voeren. Het enige dat u hoeft te doen, is ervoor te zorgen dat de toepassing reageert met 5xx op de ready-probe en de live-probe dwingen om minimaal 5xx-antwoorden op Kubernetes-oproepen te retourneren. In dit geval zal Kubernetes de pod opnieuw opstarten omdat deze als dood wordt beschouwd.

5. Probeer niet om de gereedheidsstatus van de app opnieuw in te stellen op de ready-handler. Dit wordt alleen gedaan om te controleren of de app gereed is, niet om hem gereed te maken.

Er wordt geadviseerd dat er geen logica is geïmplementeerd die probeert de staat van gereedheid te herstellen. Een dergelijke logica kan gevaarlijk zijn voor sommige componenten van het systeem.

conclusies:

Live en Ready-sondes vormen het hart en de ziel van de applicaties die in Kubernetes worden ingezet. Dit zijn de standaardmanieren om met de hypervisor te communiceren en te praten over hun status en hun problemen. Live en ready-sondes zijn krachtige wapens die een ontwikkelaar en een applicatie nodig hebben om ervoor te zorgen dat de applicatie betrouwbaar en veerkrachtig is.

Speciale dank aan Ionut Ilie. Een deel van dit materiaal is het resultaat van zijn onderzoek en wijsheid.