Liveness probes i Kubernetes kan vara farliga

Obs. övers.: Ledande ingenjör på Zalando — Henning Jacobs — har flera gånger noterat att användare av Kubernetes har problem med att förstå syftet med liveness (och readiness) probes och hur de ska användas korrekt. Därför har han samlat sina tankar i denna korta anteckning, som med tiden kommer att bli en del av K8s-dokumentationen.

De tillståndskontroller som i Kubernetes kallas liveness probes (dvs. bokstavligen "livskrafttester" — obs. övers.), kan vara bastante farliga. Jag rekommenderar att undvika dem om möjligt: undantagen är endast fall där de verkligen är nödvändiga och där du fullt ut förstår specifiken och konsekvenserna av deras användning. Denna publikation kommer att handla om liveness- och readiness-kontroller, och det kommer att diskuteras i vilka fall befinner sig och inte ska tillämpas.

Min kollega Sandor delade nyligen på Twitter de vanligaste felen han stöter på, inklusive de relaterade till användningen av readiness/liveness probes:

Felaktigt konfigurerad livenessProbe kan förvärra situationer med hög belastning (snöbollseffekt + potentiellt lång start av container/applikation) och leda till andra negativa konsekvenser som att beroenden faller (se även min senaste artikel om att begränsa antalet förfrågningar i kombinationen K3s+ACME). Ännu värre är det när en liveness probe kombineras med hälsokontroll av ett beroende (health check), som i detta fall är en extern databas: ett enda databasfel kommer att återstarta alla era containrar!

Det övergripande budskapet "Använd inte liveness probes" är i detta fall inte till stor hjälp, så låt oss titta på vad syftet med readiness- och liveness-kontroller är.

Obs: Största delen av testet nedan var ursprungligen inkluderat i den interna dokumentationen för utvecklare på Zalando.

Readiness och Liveness-kontroller

Kubernetes erbjuder två viktiga mekanismer som kallas liveness probes och readiness probes. De utför regelbundet en åtgärd — till exempel skickar en HTTP-förfrågan, öppnar en TCP-anslutning eller kör ett kommando i containern — för att bekräfta att applikationen fungerar korrekt.

Kubernetes använder readiness probes, för att förstå när en pod är redo att ta emot trafik. En pod anses vara redo om alla dess containrar är klara. En av tillämpningarna av denna mekanism är att kontrollera vilka pods som används som backend för Kubernetes-tjänster (och särskilt Ingress).

Livlighetspåståenden hjälper Kubernetes att förstå när det är dags att starta om en container. Till exempel kan en sådan kontroll fånga ett deadlock, när applikationen "fastnar" på en plats. Att starta om containern i ett sådant tillstånd hjälper till att få applikationen i rörelse igen, trots fel, men det kan också leda till kaskadeffekter (se nedan).

Om du försöker driftsätta en applikationsuppdatering som misslyckas med livlighets-/beredskapskontroller, kommer driftsättningen att stanna, eftersom Kubernetes väntar på status Redo från alla pods.

Exempel

Här är ett exempel på en beredskapskontroll som kontrollerar vägen /health via HTTP med standardinställningar (intervall: 10 sekunder, timeout: 1 sekund, framgångströskel: 1, misslyckandetröskel: 3):

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

Rekommendationer

1. För mikrotjänster med HTTP-endpoint (REST osv.) definiera alltid en beredskapskontroll, som kontrollerar om applikationen (pod) är redo att ta emot trafik.
2. Se till att beredskapskontrollen täckar beredskapen hos den faktiska webbserverporten:
   • använder portar för administrativa ändamål, kallade "admin" eller "management" (t.ex. 9090), för beredskapskontroll, se till att endpointen returnerar OK endast om den primära HTTP-porten (som 8080) är redo att ta emot trafik*;

     * Jag vet åtminstone om ett fall på Zalando där detta inte skedde, det vill säga beredskapskontroll kontrollerade "management"-porten, men servern startade aldrig på grund av problem med cache-laddningen.

   • att koppla beredskapskontrollen till en separat port kan leda till att belastningen på den primära porten inte speglas i hälsokontrollen (det vill säga trådpoolen på servern är fylld, men hälsokontrollen visar fortfarande att allt är OK).
3. Se till att beredskapskontrollen inkluderar initiering/migrering av databasen;
   • det enklaste sättet att uppnå detta är att bara göra HTTP-anrop efter att initieringen har slutförts (t.ex. databas-migrering med Flyway osv.); det vill säga istället för att ändra hälsokontrollens status, starta helt enkelt inte webbservern förrän databas-migreringen är klar*.

     * Det går också att köra databasöverflyttningar från init-containrar utanför podden. Jag är fortfarande en beundrare av fristående appar, där applikationens container vet hur den ska ställa in databasen utan extern koordination.

4. Använd httpGet för readiness-kontroller via typiska health check-endpoints (till exempel, /health).
5. Förstå standardinställningarna för kontrollerna (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • standardinställningarna innebär att podden kommer att bli not-ready ungefär efter 30 sekunder (3 misslyckade hälsokontroller).
6. Använd en separat port för "admin" eller "management", om teknikstacken (till exempel, Java/Spring) tillåter det, för att separera "hälsosam" och metrics från vanlig trafik:
   • men glöm inte punkt 2.
7. Om nödvändigt kan readiness probe användas för att förvärma/ladda cachen och returnera statuskod 503, tills containern är "färdig":
   • Jag rekommenderar också att bekanta sig med den nya kontrollen startupProbe, som introducerades i version 1.16 (vi skrev om den på ryska här — anm. red.).

Varningar

1. Lita inte på externa beroenden (såsom datalagringssystem) vid utförande av readiness/liveness tester – detta kan leda till kaskadfel:
   • som ett exempel, låt oss ta en stateful REST-tjänst med 10 poddar som är beroende av en enda Postgres-databas: när kontrollen beror på en fungerande databasanslutning kan alla 10 poddar krascha om det blir en fördröjning i nätverket/vid databasen – vanligtvis slutar allt detta sämre än det borde;
   • Notera att Spring Data som standard kontrollerar databasanslutningen*;

     * Detta är standardbeteendet för Spring Data Redis (åtminstone var det så när jag kontrollerade senast), vilket ledde till ett "katastrofalt" fel: när Redis var otillgänglig under en kort tid, föll alla poddar.

   • "externt" i detta sammanhang kan också betyda andra poddar av samma applikation, så i idealfallet bör kontrollen inte bero på tillståndet hos andra poddar i samma kluster för att förhindra kaskadfel:
     • resultaten kan variera för applikationer med distribuerat tillstånd (till exempel, in-memory caching i poddar).
2. Använd inte liveness probe för poddar (undantag ges för fall när de verkligen behövs och du är fullt medveten om specifikationen och konsekvenserna av att använda dem):
   • liveness-proben kan hjälpa till att återställa "hängande" containrar, men eftersom du har full kontroll över din applikation bör sådana saker som "hängande" processer och dödlägen i idealfallet inte inträffa: det bästa alternativet är att avsiktligt stänga ner applikationen och återföra den till ett tidigare stabilt tillstånd;
   • ett misslyckat liveness-prover leder till att containern startas om, vilket potentiellt förvärrar konsekvenserna av fel relaterade till lastning: omstart av containern kommer att orsaka stillestånd (åtminstone under applikationens starttid, säg mer än 30 sekunder), vilket skapar nya fel, ökar belastningen på andra containrar och ökar risken för deras misslyckande, etc.;
   • liveness-kontroller i kombination med externa beroenden är den värsta av möjliga kombinationer och hotar med kaskadmisslyckanden: en obetydlig fördröjning från databasen leder till att alla dina containrar startas om!
3. Parametrar för liveness- och readiness-kontroller bör vara olika:
   • liveness-proben kan använda samma hälsokontroll, men med en högre tröskel för utlösning (failureThreshold), till exempel, ge status not-ready efter 3 försök och betrakta att liveness-proben misslyckas efter 10 försök;
4. Använd inte exec-kontroller, eftersom de är förknippade med välkända problem som leder till zombiprocesser:
   • detaljer: se Datadogs experters presentation.

Sammanfattning

• Använd readiness probes för att bestämma när podden är redo att ta emot trafik.
• Använd liveness probes endast när de verkligen är nödvändiga.
• Felaktig användning av readiness/liveness probes kan leda till minskad tillgänglighet och kaskadmisslyckanden.

Ytterligare material om ämnet

• Kubernetes-dokumentation: Konfigurera Liveness- och Readiness-Probes;
• Kubernetes Liveness- och Readiness-Probes Återbesökt: Hur man Undviker att Skjuta Sig Själv i Foten;
• NRE Labs Avbrott Post-Mortem (berättar även om livenessProbe).

Uppdatering nr 1 från 2019-09-29

Om init-containrar för databasflyttningar: en fotnot har lagts till.

EJ påminde mig om PDB: en av problemen med liveness-kontroller är bristen på samordning mellan poddar. I Kubernetes finns det Pod Disruption Budgets (PDB) för att begränsa antalet parallella kraschningar som en applikation kan uppleva, men kontrollerna tar inte hänsyn till PDB. I idealfallet kan vi be K8s: "Starta om en pod om dess kontroll misslyckas, men starta inte om alla, för att inte göra det ännu värre."

Bryan uttryckte det utmärkt: "Använd liveness-probing när du är säker på att det bästa som kan göras är att "döda" applikationen" (återigen, var försiktig med detta).

Uppdatering #2 från 2019-09-29

När det kommer till att läsa dokumentationen innan användning: jag skapade en relevant begäran (feature request) för att komplettera dokumentationen om liveness probes.

P.S. från översättaren

Läs även i vår blogg:

• «Kubernetes: livscykel för en pod»;
• «7 bästa praxis för containerhantering enligt Google»;
• «7 principer för design av containerbaserade applikationer».

Källa: habr.com