De PostgreSQL-database heeft het moeilijk: de latentie wordt vertienvoudigd. API-pods reageren binnen acht seconden in plaats van tweehonderd milliseconden. Er treedt een time-out op bij de HTTP-liveness-test na drie seconden. Kubernetes herstart de pods – verlies van verbindingen, koude cache, nieuwe storm in de database. Het incident wordt een cascade wanneer de applicatie tevreden had kunnen zijn met een tijdelijke verwijdering uit de load balancer.
Sondes zijn de thermometer die de kubelet gebruikt om te beslissen: verkeer sturen, wachten of doden. Omdat ze slecht gereguleerd zijn, veranderen ze achteruitgang in een ramp. Het scenario is gebruikelijk omdat tutorials één enkele '/health'-test voor alle rollen kopiëren - en omdat liveness wordt geconfigureerd voordat het team het verschil met gereedheid begrijpt.
Het goede nieuws: een goed gekalibreerde sonde kost een halve dag werk. Het slechte: een agressieve test kan uren crashloop kosten en een databasefout verergeren die op zichzelf had kunnen worden opgelost.
Levendigheid, gereedheid, opstarten: drie verschillende signalen
| Sonde | Effect | Vraag |
|---|---|---|
| Gereedheid | Uit service verwijderen | "Kan ik nu verkeer ontvangen?" » |
| Levendigheid | Start de pod | “Is het proces dood zonder herstel? » |
| Opstarten | Blokkeert anderen bij opstarten | “Is de applicatie gestart?” » |
Klassieke fout: slechts één /health URL voor alle drie de rollen. Onder belasting faalt de paraatheid en de levendigheid is dodelijk – dubbele straf. Gereedheid moet de pod uit het verkeer verwijderen wanneer een afhankelijkheid traag is; Levendigheid mag alleen ingrijpen als het proces daadwerkelijk vastloopt, en niet alleen maar langzaam.
Het herstarten van een langzame pod versnelt een verzadigde database niet; het voegt chaos toe.
Voor een inzet zonder levendigheid in eerste instantie is paraatheid plus Prometheus-waarschuwingen vaak voldoende. Voeg levendigheid toe als je duidelijk onderscheid maakt tussen ‘langzaam maar levend’ en ‘dood zonder herstel’.
Kalibreer time-outs, periode en foutdrempel
Drie parameters bepalen de agressiviteit:
- timeoutSeconds moeten onder normale belasting groter zijn dan 99 percentiel – niet onder ideale laboratoriumbelasting.
- periodSeconds stelt de frequentie van controles in; te agressief vermenigvuldigt de incidentele belasting.
- failureThreshold × periode = vertraging vóór actie; drie storingen elke tien seconden duren dertig seconden voordat opnieuw wordt opgestart.
Voorbeeld: als uw interface onder normale belasting binnen 400 ms reageert op percentiel 99, laat een time-out van drie seconden een comfortabele marge over. Als de basis vertraagt en het 99-percentiel stijgt naar zes seconden, faalt de paraatheid – maar levendigheid mag niet dodelijk zijn zolang het proces nog steeds reageert.
Gezondheid van eindpunten: gescheiden live en klaar
Afzonderlijke bedieningselementen in uw toepassing:
- /health/live: het proces reageert – geen zware basisoproepen.
- /health/ready: database bereikbaar, hot cache, migraties voltooid.
Zet geen dure basisoproepen in levendigheid. Als PostgreSQL niet beschikbaar is, mogen alle pods niet in de crashloop terechtkomen. De gereedheid is voldoende om ze tijdens de storing uit de service te verwijderen.
Configureer een startupProbe met dertig fouten per tien seconden als het opstarten langer duurt dan dertig seconden: hierdoor blijft er vijf minuten opstarten over zonder ongewenste levendigheid. Essentieel voor Java-applicaties, opstartmigraties of het laden van een grote cache.
Probes en Europees beheerde Kubernetes
Op beheerde Kubernetes OVHcloud, Scaleway Kapsule of andere Europese aanbiedingen beheert het controlevlak de sondes aan de Kubelet-kant - uw verantwoordelijkheid blijft de inhoud van de controle en de belasting ervan.
Punten van waakzaamheid:
- Zijcontainers die opstartlatentie toevoegen;
- Lage processorlimieten die time-outs veroorzaken onder belasting;
- Verwarring tussen de bediening van de externe lastverdeler en de podsonde: twee verschillende mechanismen.
Vergelijk Kubernetes-aanbiedingen via de overzicht en de vergelijking. Als u implementeert in een klein cluster, raadpleeg dan ook Kubernetes: Heeft u het echt nodig? voordat u de probe-complexiteit toevoegt aan een extra grote stapel.
Waarneembaarheid: correleer herstarts en probes
Nuttige incidentstatistieken:
- Herstartteller per inzet;
- 'Ongezonde' gebeurtenissen in 'kubectl beschrijven pod';
- Kubelet logt tijdens het opnieuw opstarten.
Aanbevolen runbook: if crashloop — schakel liveness tijdelijk uit na bevestiging dat het proces geen zombie is; corrigeer de hoofdoorzaak (trage basis, uitgeputte pool); reactiveren met ontspannen drempels. Schakel nooit de levendigheid in de productie uit zonder een parallelle waarschuwing over de beschikbaarheid.
Het correleren van herstarts en basislatentie in de productie brengt vaak een overdreven agressieve test aan het licht – geen applicatiefout. Zie Prometheus metrics om het 99-percentiel te instrumenteren voordat u time-outs instelt.
De top: opnieuw opstarten als een luie reflex
Een nuttige sonde verwijdert het verkeer. Een luie sonde start opnieuw op en hoopt dat het probleem verdwijnt. Het verschil ligt in de live/ready-scheiding, de time-outs die zijn gekalibreerd op echte metingen en de discipline om een configuratie die op een forum wordt gevonden niet te kopiëren zonder deze aan te passen aan je belasting.
Beslis en ga vooruit zonder blinde vlek
Gedurende een halve dag kunt u de sondes weer in dienst stellen van de stabiliteit:
- Implementeer afzonderlijke live en gebruiksklare eindpunten — live zonder basisoproep, klaar met kritieke afhankelijkheden.
- Configureer een startupProbe als het opstarten langer duurt dan dertig seconden; zonder dit zal liveness de applicatie beëindigen voordat het opstarten is voltooid.
- Stel time-outs in op basis van het 99e percentiel gemeten onder normale belasting – geen standaardinstelling voor de tutorial.
- Test in pre-productie met gesimuleerde basisverzadiging: pods moeten NotReady doorstaan, niet CrashLoopBackOff.
- Correleer herstarts en basislatentie in productie; pas de failThreshold aan voordat u replica's toevoegt.
- Vergelijk Kubernetes-aanbiedingen via de overzicht als u migreert naar een Europees beheerd cluster.
Veelgestelde vragen
Wat is het verschil tussen levendigheid en gereedheid?
Gereedheid verwijdert de pod uit de service zonder deze te doden - geschikt wanneer een afhankelijkheid tijdelijk niet beschikbaar is. Liveness herstart de container; reserveer het voor onherstelbare blokkades. Het verwarren van de twee veroorzaakt onnodig opnieuw opstarten tijdens tijdelijke degradatie.
Waarom veroorzaakt mijn liveness een crashloop?
Time-outs te kort, traag eindpunt onder belasting of controle die door dezelfde verzadigde database gaat. De kubelet doodt de pod zolang de paraatheid voldoende zou zijn. Verlaag de drempels of verplaats de basislijncontrole naar alleen gereedheid.
Waar wordt startupProbe voor gebruikt?
Het vertraagt de levendigheid en gereedheid tijdens lang opstarten: migraties, cache, externe verbindingen. Zonder dit beëindigt levendigheid de applicatie voordat het opstarten is voltooid. Configureer hem zodra het meer dan dertig seconden duurt voordat een pod operationeel wordt.
HTTP of exec voor een test?
HTTP op een lichtgewicht applicatie-eindpunt verdient de voorkeur. Exec- of TCP-socket controleren weinig op de bedrijfsgezondheid; reserveer ze als laatste redmiddel als HTTP niet beschikbaar is.
Een nuttige sonde laat het verkeer vallen; een luie sonde start opnieuw op en hoopt dat het probleem verdwijnt.