Liveness probes yn Kubernetes kinne gefaarlik wêze

Noat. transl.: Lead yngenieur út Zalando, Henning Jacobs, hat ferskate kearen problemen opmurken ûnder Kubernetes brûkers by it begripen fan it doel fan liveness (en reewilligens) probes en harren korrekte gebrûk. Dêrom sammele hy syn gedachten yn dizze romtlike notysje, dy't úteinlik diel wurde sil fan 'e K8s dokumintaasje.

Health kontrôles, bekend yn Kubernetes as liveness probes (d.w.s. letterlik, "leftbaarheidstests" - sawat oerset.), kin hiel gefaarlik. Ik riede oan om se as mooglik te foarkommen: de ienige útsûnderingen binne as se wirklik nedich binne en jo folslein bewust binne fan 'e spesifike en gefolgen fan har gebrûk. Dizze publikaasje sil prate oer liveness en reewilligens kontrôles, en sil jo ek fertelle yn hokker gefallen is wurdich en jo moatte se net brûke.

Myn kollega Sandor dielde koartlyn op Twitter de meast foarkommende flaters dy't hy tsjinkomt, ynklusyf dy relatearre oan it gebrûk fan reewilligens-/libbensprobes:

Ferkeard ynsteld livenessProbe kin situaasjes mei hege loads fergrutsje (sniebal ôfslute + potinsjeel lange opstarttiid fan kontener / applikaasje) en liede ta oare negative gefolgen lykas ôfhinklikensfallen (Sjoch ek myn resinte artikel oer it beheinen fan it oantal oanfragen yn 'e kombinaasje K3s + ACME). It is noch slimmer as de leefberenssonde wurdt kombinearre mei in sûnenskontrôle, dat is in eksterne database: in inkele DB-flater sil al jo konteners opnij starte!

Algemien berjocht "Gebrûk gjin liveness probes" yn dit gefal helpt it net folle, dus litte wy sjen wêr't de reewilligens- en libbenskontrôles foar binne.

Opmerking: It grutste part fan 'e test hjirûnder waard oarspronklik opnommen yn Zalando's ynterne ûntwikkeldersdokumintaasje.

Readiness en Liveness kontrôles

Kubernetes jout twa wichtige meganismen neamd liveness probes en readiness probes. Se fiere periodyk wat aksje út - lykas it ferstjoeren fan in HTTP-fersyk, it iepenjen fan in TCP-ferbining, of it útfieren fan in kommando yn 'e kontener - om te befestigjen dat de applikaasje wurket lykas ferwachte.

Kubernetes brûkt reewilligens sondesom te begripen wannear't de kontener klear is om ferkear te akseptearjen. In pod wurdt beskôge as klear foar gebrûk as al syn konteners klear binne. Ien gebrûk fan dit meganisme is om te kontrolearjen hokker pods wurde brûkt as backends foar Kubernetes-tsjinsten (en benammen Ingress).

Liveness probes helpe Kubernetes te begripen wannear't it tiid is om de kontener opnij te begjinnen. Sa kinne jo bygelyks in deadlock ûnderskeppe as in applikaasje op ien plak fêst komt te sitten. De kontener opnij starte yn dizze steat helpt de applikaasje fan 'e grûn te krijen nettsjinsteande flaters, mar it kin ek liede ta cascadearjende flaters (sjoch hjirûnder).

As jo ​​besykje in applikaasje-fernijing yn te setten dy't de liveness-/reeheidskontrôles net slagget, sil de útrol stoppe wurde as Kubernetes wachtet op de status Ready fan alle poddestuollen.

Foarbyld:

Hjir is in foarbyld fan in reewilligensprobe dy't in paad kontrolearret /health fia HTTP mei standertynstellingen (tuskenskoft: 10 sekonden, skoft:1 sekonde, súkses drompel: 1, falen drompel:3):

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

oanbefellings

1. Foar mikrotsjinsten mei HTTP-einpunt (REST, ensfh.) altyd definiearje in reewilligens sonde, dy't kontrolearret oft de applikaasje (pod) ree is om ferkear te akseptearjen.
2. Soargje derfoar dat de reewilligens sonde beslacht de beskikberens fan 'e eigentlike webserverpoarte:
   • gebrûk fan havens foar bestjoerlike doelen, neamd "admin" of "behear" (bygelyks 9090), foar readinessProbe, soargje derfoar dat it einpunt allinich OK weromkomt as de primêre HTTP-poarte (lykas 8080) klear is om ferkear te akseptearjen *;

     *Ik bin bewust fan op syn minst ien gefal by Zalando dêr't dit net barde, d.w.s. readinessProbe Ik kontrolearre de "behear" haven, mar de tsjinner sels begon net te wurkjen fanwege problemen mei it laden fan de cache.

   • it heakjen fan in reewilligensprobe oan in aparte poarte kin liede ta it feit dat oerbelêsting op 'e haadpoarte net reflektearre wurdt yn' e sûnenskontrôle (dat is, de threadpool op 'e tsjinner is fol, mar de sûnenskontrôle lit noch sjen dat alles goed is ).
3. Soargje dat reewilligensprobe makket databankinitialisaasje / migraasje mooglik;
   • De maklikste manier om dit te berikken is om kontakt op te nimmen mei de HTTP-tsjinner pas nei't inisjalisaasje foltôge is (bygelyks migrearje fan in databank fan Flyway ensafuorthinne.); dat is, ynstee fan it feroarjen fan de sûnenskontrôlestatus, start de webtsjinner gewoan net oant de databankmigraasje foltôge is *.

     * Jo kinne ek databasemigraasjes útfiere fan init-konteners bûten de pod. Ik bin noch altyd in fan fan selsstannige applikaasjes, dat is dejingen wêryn de applikaasjecontainer wit hoe't de databank yn 'e winske steat bringt sûnder eksterne koördinaasje.

4. Gebrûk httpGet foar reeheidskontrôles fia typyske einpunten foar sûnenskontrôle (bygelyks, /health).
5. Begryp de standertkontrôleparameters (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • de standertopsjes betsjutte dat de pod sil wurde net klear nei likernôch 30 sekonden (3 mislearre sanity kontrôles).
6. Brûk in aparte poarte foar "admin" of "behear" as de technologystapel (bgl
   • mar ferjit punt 2 net.
7. As it nedich is, kin de reewilligensprobe brûkt wurde om de cache op te waarmjen / te laden en in 503-statuskoade werom te jaan oant de kontener opwarmt:
   • Ik riede ek oan dat jo de nije kontrôle lêze startupProbe, ferskynde yn ferzje 1.16 (wy skreaunen deroer yn it Russysk hjir - ca. oerset.).

Caveats

1. Fertrouwe net op eksterne ôfhinklikens (lykas gegevenspakhuzen) by it útfieren fan tests foar reewilligens / libbenens - dit kin liede ta cascadearjende flaters:
   • Litte wy as foarbyld in steatlike REST-tsjinst nimme mei 10 pods ôfhinklik fan ien Postgres-database: as de kontrôle hinget ôf fan in wurkjende ferbining mei de DB, kinne alle 10 pods mislearje as d'r in fertraging is oan 'e netwurk / DB-kant - normaal is it alles einiget slimmer as it koe;
   • Tink derom dat Spring Data de databankferbining standert kontrolearret *;

     * Dit is it standertgedrach fan Spring Data Redis (it wie teminsten de lêste kear dat ik kontrolearre), wat late ta in "katastrofale" mislearring: doe't Redis in koarte tiid net beskikber wie, "crashten" alle pods.

   • "ekstern" yn dizze sin kin ek oare pods fan deselde applikaasje betsjutte, dat is, ideaal soe de kontrôle net ôfhingje fan 'e steat fan oare pods fan itselde kluster om cascadearjende crashes te foarkommen:
     • resultaten kinne fariearje foar applikaasjes mei ferspraat steat (Bygelyks caching yn it ûnthâld yn pods).
2. Brûk gjin liveness probe foar pods (útsûnderingen binne gefallen as se echt nedich binne en jo folslein bewust binne fan 'e spesifike en gefolgen fan har gebrûk):
   • In liveness probe kin helpe te herstellen hong konteners, mar sûnt jo hawwe folsleine kontrôle oer jo applikaasje, dingen lykas hong prosessen en deadlocks moatte by útstek net barre: it bêste alternatyf is om bewust crashe de applikaasje en bring it werom nei foarige steady state;
   • in mislearre liveness-probe sil de kontener opnij starte, wêrtroch't de effekten fan laden-relatearre flaters mooglik fergrutte wurde: it op 'e nij opstarten fan' e kontener sil resultearje yn downtime (op syn minst foar de doer fan it opstarten fan 'e applikaasje, sis 30-ûneven sekonden), wêrtroch nije flaters feroarsaakje , it fergrutsjen fan de lading op oare konteners en it fergrutsjen fan de kâns op har mislearjen, ensfh.
   • liveness kontrôles kombinearre mei in eksterne ôfhinklikens binne de slimst mooglike kombinaasje, driigjende cascading mislearrings: in lichte fertraging oan de databank kant sil liede ta in trochstart fan al jo containers!
3. Parameters fan liveness en reewilligens kontrôles moat oars:
   • jo kinne in libbensonde brûke mei deselde sûnenskontrôle, mar in hegere antwurddrompel (failureThreshold), bygelyks de status tawize net klear nei 3 besykjen en beskôgje dat de liveness sonde is mislearre nei 10 besykjen;
4. Brûk gjin exec-kontrôles, om't se ferbûn binne mei bekende problemen dy't liede ta it ferskinen fan zombieprosessen:
   • details: sjo presintaasje troch Datadog spesjalisten.

Gearfetting

• Brûk reewilligensprobes om te bepalen wannear't in pod ree is om ferkear te ûntfangen.
• Brûk liveness probes allinich as se echt nedich binne.
• Unjildich gebrûk fan probes foar reewilligens / libbenens kin liede ta fermindere beskikberens en cascadearjende mislearrings.

Oanfoljende materialen oer it ûnderwerp

• Kubernetes docs: Liveness and Readiness Probes ynstelle;
• Kubernetes Liveness and Readiness Probes opnij besocht: hoe kinne jo foarkomme dat jo sels yn 'e oare foet sjitte;
• NRE Labs Outage Post-mortem (hy praat ek oer livenessProbe).

Update nûmer 1 fan 2019-09-29

Oer init-konteners foar databankmigraasje: Fuotnoat tafoege.

EJ herinnerde my oer PDB: ien fan de problemen mei liveness kontrôles is it gebrek oan koördinaasje tusken pods. Kubernetes hat Pod Disruption Budgets (PDB) om it oantal tagelyk mislearrings te beheinen in applikaasje kin ûnderfine, de kontrôles nimme lykwols gjin rekken mei it PDB. Ideal kinne wy ​​​​K8s fertelle om "ien pod opnij te starten as syn test mislearret, mar start se net allegear opnij om te foarkommen dat dingen slimmer wurde."

Bryan sette it perfekt: "Brûk liveness-probing as jo krekt witte wat it bêste ding om te dwaan is de applikaasje te deadzjen"(wer, net meidwaan).

Update nûmer 2 fan 2019-09-29

Oangeande it lêzen fan de dokumintaasje foar gebrûk: Ik haw it oerienkommende fersyk makke (funksje fersyk) om dokumintaasje ta te foegjen oer liveness probes.

PS fan oersetter

Lês ek op ús blog:

• «Kubernetes: Pod Life";
• «7 bêste praktiken foar it brûken fan konteners neffens Google";
• «7 Prinsipes foar it ûntwerpen fan container-basearre applikaasjes".

Boarne: www.habr.com