🥇Liveness probes in Kubernetes kunnen gevaarlijk zijn

Opmerking vertaler.: De leidende ingenieur van Zalando, Henning Jacobs, heeft herhaaldelijk opgemerkt dat gebruikers van Kubernetes problemen hebben met het begrijpen van de functie en het juiste gebruik van liveness (en readiness) probes. Daarom heeft hij zijn gedachten samengebracht in deze beknopte notitie, die in de loop van de tijd deel zal uitmaken van de K8s-documentatie.

Statuscontroles, bekend in Kubernetes als liveness probes (dat wil zeggen, letterlijk, 'levensvatbaarheidsproeven' - opmerking vertaler), kunnen behoorlijk gevaarlijk zijn. Ik raad aan om ze indien mogelijk te vermijden: uitzonderingen zijn alleen situaties waarin ze echt nodig zijn en je volledig bewust bent van de specificiteit en consequenties van hun gebruik. In deze publicatie zullen we het hebben over liveness- en readiness-checks, en wanneer het niet aan te raden is ze toe te passen.

Mijn collega Sandor deelde onlangs op Twitter de meest voorkomende fouten die hij tegenkomt, waaronder die gerelateerd aan het gebruik van readiness/liveness probes:

Onjuist geconfigureerde livenessProbe kan situaties met hoge belasting verergeren (een lawine van instellingen die uitvallen + een potentieel langdurige opstarttijd van de container/toepassing) en leiden tot andere negatieve gevolgen, zoals het falen van afhankelijkheden. (zie ook mijn recente artikel over het beperken van het aantal verzoeken in de combinatie K3s+ACME). Nog erger is wanneer de liveness probe wordt gecombineerd met een afhankelijkheidscontrole (health check) waarbij een externe database betrokken is: een enkele databasefout zal al je containers opnieuw opstarten.!

De algemene boodschap "Gebruik geen liveness probes" helpt in dit geval niet veel, dus laten we bekijken waarvoor readiness- en liveness-checks bedoeld zijn.

Opmerking: het grootste deel van de onderstaande test was oorspronkelijk opgenomen in de interne documentatie voor ontwikkelaars bij Zalando.

Readiness- en Liveness-checks

Kubernetes biedt twee belangrijke mechanismen, genaamd liveness probes en readiness probes. Ze voeren periodiek een bepaalde actie uit - bijvoorbeeld het verzenden van een HTTP-verzoek, het openen van een TCP-verbinding of het uitvoeren van een opdracht in de container - om te bevestigen dat de toepassing goed functioneert.

Kubernetes gebruikt readiness probes, om te begrijpen wanneer de container klaar is om verkeer te accepteren. Een pod wordt als gereed beschouwd als al zijn containers gereed zijn. Een toepassing van dit mechanisme is om te controleren welke pods worden gebruikt als backends voor Kubernetes-services (en vooral voor Ingress).

Liveness probes helpen Kubernetes te begrijpen wanneer het tijd is om de container opnieuw op te starten. Bijvoorbeeld, zo'n controle kan een deadlock opvangen wanneer een toepassing 'vastzit'. Het herstarten van een container in een dergelijke toestand helpt de toepassing vooruit te duwen, ondanks fouten, maar kan ook leiden tot cascadefouten (zie hieronder).

Als je probeert een update van de toepassing uit te rollen die faalt in de liveness/readiness checks, zal de uitrol vastlopen omdat Kubernetes op de status wacht Klaar van alle pods.

Voorbeeld

Hier is een voorbeeld van een readiness probe die het pad controleert /health via HTTP met de standaardinstellingen (interval: 10 seconden, timeout: 1 seconde, success threshold: 1, failure threshold: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Aanbevelingen

Voor microservices met een HTTP-eindpunt (REST enz.) bepaal altijd een readiness probe, die controleert of de toepassing (pod) klaar is om verkeer te ontvangen.
Zorg ervoor dat de readiness probe de beschikbaarheid van de feitelijke webserverpoort dekt:
- door poorten voor administratieve doeleinden te gebruiken, genaamd 'admin' of 'management' (bijvoorbeeld 9090), voor readinessProbe, zorg ervoor dat het eindpunt alleen OK retourneert als de primaire HTTP-poort (zoals 8080) klaar is om verkeer te accepteren*;
  * Ik weet in ieder geval van een geval bij Zalando waar dit niet gebeurde, namelijk readinessProbe de 'management'-poort werd gecontroleerd, maar de server zelf startte nog steeds niet op vanwege problemen met het cachen van bestanden.
- het aanbrengen van een readiness probe op een aparte poort kan ertoe leiden dat de belasting op de primaire poort niet wordt weerspiegeld in de health check (dat wil zeggen, de threadpool op de server is vol, maar de health check toont nog steeds aan dat alles OK is).
Zorg ervoor dat de readiness probe omvat database-initialisatie/migratie;
- de eenvoudigste manier om dit te bereiken is om de HTTP-server pas aan te roepen nadat de initialisatie is voltooid (bijvoorbeeld de database-migratie met Flyway enz.); dat wil zeggen, in plaats van de status van de health check te wijzigen, start je de webserver gewoon niet op totdat de database-migratie is voltooid*.
  * Je kunt ook database-migraties uitvoeren vanuit init-containers buiten de pod. Ik blijf een voorstander van zelfvoorzienende applicaties, dat wil zeggen applicaties waarvan de container zonder externe coördinatie weet hoe de database in de juiste staat te brengen.
Gebruik httpGet voor readiness-controles via typische health check-eindpunten (bijvoorbeeld, /health).
Verken de standaardparameters van de controles (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- de standaardparameters betekenen dat de pod not-ready ongeveer 30 seconden later zal zijn (na 3 mislukte gezondheidschecks).
Gebruik een aparte poort voor "admin" of "management", als de technologie-stack (bijvoorbeeld Java/Spring) dit toelaat, om het beheer van de "gezondheid" en statistieken te scheiden van normaal verkeer:
- maar vergeet punt 2 niet.
Indien nodig kan de readiness probe worden gebruikt voor het opwarmen/laden van de cache en de statuscode 503 retourneren, terwijl de container nog niet is "opgewarmd":
- ik raad ook aan om de nieuwe controle startupProbe, te bekijken, die is geïntroduceerd in versie 1.16 (we schreven erover in het Russisch hier – opmerking vert.).

Waarschuwingen

Vertrouw niet op externe afhankelijkheden (zoals dataletsels) bij het uitvoeren van readiness/liveness-tests — dit kan leiden tot cascade-fouten:
- een voorbeeld is een stateful REST-service met 10 pods die afhankelijk zijn van dezelfde Postgres-database: wanneer de controle afhankelijk is van een werkende verbinding met de database, kunnen alle 10 pods uitvallen als er een vertraging in het netwerk/databank is — meestal eindigt dit veel slechter dan nodig was;
- let op dat Spring Data standaard de verbinding met de database controleert*;
  * Dit is het standaardgedrag van Spring Data Redis (althans, het was dat toen ik het voor het laatst controleerde), wat leidde tot een "catastrofale" uitval: toen Redis kortstondig niet bereikbaar was, zijn alle pods "uitgevallen".
- "extern" kan in deze context ook verwijzen naar andere pods van dezelfde applicatie, wat betekent dat de controle idealiter niet afhankelijk moet zijn van de status van andere pods in dezelfde cluster om cascade-uitvallen te voorkomen:
  - de resultaten kunnen variëren voor applicaties met een gedistribueerde status (bijvoorbeeld in-memory caching in pods).
Gebruik de liveness probe niet voor pods (behalve in gevallen waarin ze echt nodig zijn en je je volledig bewust bent van de specifieke details en gevolgen van hun gebruik):
- Een liveness probe kan helpen bij het herstellen van 'vastgelopen' containers, maar aangezien u volledige controle over uw applicatie heeft, zouden dingen zoals 'vastgelopen' processen en deadlocks idealiter niet voor moeten komen: de beste alternatieve aanpak is een opzettelijke crash van de applicatie en deze terugzetten naar de vorige stabiele staat;
- Een mislukte liveness probe leidt tot een herstart van de container, wat de gevolgen van fouten die samenhangen met de belasting potentieel verergert: een herstart van de container leidt tot downtime (ten minste tijdens de opstarttijd van de applicatie, laten we zeggen, meer dan 30 seconden), waardoor nieuwe fouten worden veroorzaakt, de belasting van andere containers toeneemt en de kans op hun falen groter wordt, enzovoort;
- Liveness checks in combinatie met een externe afhankelijkheid zijn de slechtste mogelijke combinatie, wat kan leiden tot cascade-falen: een kleine vertraging aan de databasezijde kan leiden tot een herstart van al uw containers!
De parameters van liveness- en readiness-checks moeten verschillend zijn:
- u kunt een liveness probe gebruiken met dezelfde health check, maar met een hogere drempelwaarde (failureThreshold), bijvoorbeeld door de status toe te wijzen not-ready na 3 pogingen en te beschouwen dat de liveness probe is mislukt na 10 pogingen;
Gebruik geen exec-checks, omdat deze bekende problemen met zich meebrengen die leiden tot zombieprocessen:
- details: zie de presentatie van experts van Datadog.

Samenvatting

Gebruik readiness probes om te bepalen wanneer de pod klaar is om verkeer te ontvangen.
Gebruik liveness probes alleen wanneer ze echt nodig zijn.
Onjuist gebruik van readiness/liveness probes kan leiden tot verminderde beschikbaarheid en cascade-falen.

Aanvullend materiaal over het onderwerp

Kubernetes docs: Configureer Liveness en Readiness Probes;
Kubernetes Liveness en Readiness Probes Herbekeken: Hoe jezelf niet in de voet te schieten;
NRE Labs Uitval Post-Mortem (dat ook over livenessProbe spreekt).

Update #1 van 2019-09-29

Over init-containers voor database-migratie: een voetnoot toegevoegd.

EJ herinnerde me aan PDB: een van de problemen met liveness-checks is het gebrek aan coördinatie tussen pods. In Kubernetes zijn er Pod Disruption Budgets (PDB) om het aantal gelijktijdige uitvallen dat een applicatie kan ervaren te beperken, maar de checks houden geen rekening met PDB. Idealiter kunnen we K8s opdracht geven: 'Herstart één pod als zijn check faalt, maar herstart ze niet allemaal om het niet nog erger te maken'.

Bryan verwoorde het uitstekend: «Gebruik liveness probing wanneer je zeker weet dat het beste wat je kunt doen, is de applicatie 'doden'» (wees opnieuw voorzichtig met overdrijven).