ProHoster >> Blog >> Administrimi >> Provat e jetëgjatësisë në Kubernetes mund të jenë të rrezikshme

Provat e jetëgjatësisë në Kubernetes mund të jenë të rrezikshme

ShĂ«n. pĂ«rk.: Inxhinier i kryesor nga kompania Zalando — Henning Jacobs — shpesh ka vĂ«rejtur te pĂ«rdoruesit e Kubernetes probleme nĂ« kuptimin e qĂ«llimit tĂ« provave tĂ« jetĂ«gjatĂ«sisĂ« (dhe gatishmĂ«risĂ«) dhe pĂ«rdorimit tĂ« saktĂ« tĂ« tyre. Prandaj ai ka mbledhur mendimet e tij nĂ« kĂ«tĂ« nota tĂ« shkurtĂ«r, e cila me kalimin e kohĂ«s do tĂ« bĂ«het pjesĂ« e dokumentacionit K8s.

Provat e jetëgjatësisë në Kubernetes mund të jenë të rrezikshme

Kontrolli i gjendjes, i njohur nĂ« Kubernetes si provat e jetĂ«gjatĂ«sisĂ« (dmth, nĂ« dosje, ‘testet pĂ«r jetĂ«gjatĂ«si’ — shĂ«n. pĂ«rkth.), mund tĂ« jenĂ« mjaft tĂ« rrezikshme. Rekomandoj tĂ« shmangni ato sa mĂ« shumĂ« qĂ« tĂ« jetĂ« e mundur: pĂ«rjashtimet janĂ« vetĂ«m rastet kur ato janĂ« me tĂ« vĂ«rtetĂ« tĂ« nevojshme dhe ju e kuptoni plotĂ«sisht specifikat dhe pasojat e pĂ«rdorimit tĂ« tyre. NĂ« kĂ«tĂ« publikim do tĂ« flasĂ« pĂ«r provat e jetĂ«gjatĂ«sisĂ« dhe gatishmĂ«risĂ«, si dhe do tĂ« diskutohet se kur kushtojnĂ« dhe kur nuk duhen aplikuar.

Kolegu im Sandor së fundmi ndau në Twitter gabimet më të zakonshme që i takohen, përfshirë ato që lidhen me përdorimin e provave të gatishmërisë/jetëgjatësisë:

Provat e jetëgjatësisë në Kubernetes mund të jenë të rrezikshme

Konfiguruar gabim livenessProbe mund të përkeqësojë situatat me ngarkesë të lartë (ndërprerje në zinxhir + nisje potencialisht e gjatë të kontejnerit/aplikacionit) dhe të sjellë pasojat e tjera negative siç janë rëniet e varësive (shih gjithashtu artikullin tim të fundit për kufizimin e numrit të kërkesave në kombinimin K3s+ACME). Akoma më keq, kur liveness probe kombinohet me kontrollin e shëndetit të varësisë (health check), e cila është një bazë të dhënash e jashtme: një dështim i vetëm i DB do të rinisë të gjithë kontejnerët tuaj!

Mesazhi i përgjithshëm «Mos përdorni liveness probes» në këtë rast ndihmon pak, prandaj le të shqyrtojmë për çfarë janë krijuar kontrollet readiness dhe liveness.

Shënim: pjesa më e madhe e testit të mëposhtëm ishte fillimisht përfshirë në dokumentacionin e brendshëm për zhvilluesit e Zalando.

Kontrolli Readiness dhe Liveness

Kubernetes ofron dy mekanizma tĂ« rĂ«ndĂ«sishĂ«m, tĂ« quajtur liveness probes dhe readiness probes. Ato kryejnĂ« njĂ« veprim tĂ« caktuar nĂ« mĂ«nyrĂ« periodike — pĂ«r shembull, dĂ«rgojnĂ« njĂ« kĂ«rkesĂ« HTTP, hapin njĂ« lidhje TCP ose ekzekutojnĂ« njĂ« komandĂ« nĂ« kontejner — pĂ«r tĂ« konfirmuar qĂ« aplikacioni funksionon siç duhet.

Kubernetes përdor readiness probes, për të kuptuar se kur kontejneri është gati për të pranuar trafik. Pod-i konsiderohet i gatshëm për punë kur të gjitha kontejnerët e tij janë gati. Një nga përdorimet e këtij mekanizmi është të kontrollojë cilat pod-e përdoren si backend për shërbimet Kubernetes (dhe sidomos Ingress-in).

Kontrollet e gatishmërisë ndihmojnë Kubernetes të kuptojë kur është koha për të rinisur kontejnerin. Për shembull, një verifikim i tillë lejon kapjen e ngërçit, kur aplikacioni "ngjitet" në një vend. Rinisi i kontejnerit në një gjendje të tillë ndihmon në lëvizjen e aplikacionit nga pika e vdekur, pavarësisht nga gabimet, megjithatë, ai gjithashtu mund të çojë në dështime kaskadë (shih më poshtë).

Nëse përpiqeni të implementoni një përditësim të aplikacionit që dështon në kontrollet e gatishmërisë/gjallërisë, nxjerrja e tij do të ngecë, sepse Kubernetes do të presë statusin Gati nga të gjitha pod-et.

Shembuj

Ja një shembull i një kontrolli të gatishmërisë, që kontrollon rrugën /health nëpërmjet HTTP me cilësimet e parazgjedhura (interval: 10 sekonda, koha e skadimit: 1 sekondë, kufi suksesi: 1, kufi dështimi: 3):

# часть ĐŸĐ±Ń‰Đ”ĐłĐŸ ĐŸĐżĐžŃĐ°ĐœĐžŃ deployment'Đ°/стДĐșĐ°
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

R rekomandimet

  1. Për mikroshërbimet me endpoint HTTP (REST etj.) këtu duhet të përcaktoni gjithmonë një kontroll gatishmërie, e cila kontrollon nëse aplikacioni (pod-i) është gati për të pranuar trafik.
  2. Sigurohuni që kontrolli i gatishmërisë mbulon gatishmërinë e portit të vërtetë të serverit të uebit:
    • duke pĂ«rdorur porte pĂ«r nevoja administrative, tĂ« quajtur "admin" ose "management" (p.sh. 9090), pĂ«r readinessProbe, sigurohuni qĂ« endpoint-i kthen OK vetĂ«m nĂ«se porta kryesore HTTP (si 8080) Ă«shtĂ« e gatshme tĂ« pranojĂ« trafik*;

      * Kam dijeni për të paktën një rast në Zalando kur kjo nuk ndodhi, domethënë readinessProbe verifikoi portin "management", por serveri vetë nuk filloi ndonjëherë të punonte për shkak të problemeve me ngarkimin e caches.

    • varĂ«simi i readiness probe nĂ« njĂ« port tĂ« veçantĂ« mund tĂ« çojĂ« nĂ« atĂ« qĂ« ngarkesa nĂ« portin kryesor nuk pasqyrohet nĂ« health check (domethĂ«nĂ«, porta e fijeve nĂ« server Ă«shtĂ« e mbushur, por health check vazhdon tĂ« tregojĂ« se gjithçka Ă«shtĂ« OK).
  3. Sigurohuni që readiness probe përfshin inicializimin/migrimin e bazës së të dhënave;
    • mĂ«nyra mĂ« e thjeshtĂ« pĂ«r ta arritur kĂ«tĂ« Ă«shtĂ« tĂ« kontaktoni me serverin HTTP vetĂ«m pas pĂ«rfundimit tĂ« inicializimit (p.sh. migrimi i DB me Flyway etj.); domethĂ«nĂ«, nĂ« vend qĂ« tĂ« ndryshoni statusin e health check-it, thjesht mos e nise serverin e uebit deri sa tĂ« pĂ«rfundojĂ« migrimi i DB*.

      * Po ashtu mund tĂ« filloni migrimet e DB nga init-kontejnerĂ«t jashtĂ« pod’it. Ende jam njĂ« adhurues i aplikacioneve tĂ« vetĂ«-mjaftueshme, domethĂ«nĂ« atyre ku konteineri i aplikacionit e di si ta çojĂ« DB-nĂ« nĂ« gjendjen e duhur pa koordinim tĂ« jashtĂ«m.

  4. PĂ«rdorni httpGet pĂ«r kontrollet e gatishmĂ«risĂ« pĂ«rmes endpoint’ëve tipikĂ« tĂ« kontrolleve tĂ« shĂ«ndetit (pĂ«r shembull, /health).
  5. Shqyrtoni parametrat e kontrolleve të caktuar si parazgjedhje (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
    • parametrat e parazgjedhur do tĂ« thotĂ« se pod-i do tĂ« bĂ«het not-ready afĂ«rsisht pas 30 sekondave (3 dĂ«shtime tĂ« kontrolleve tĂ« funksionit).
  6. Përdorni një port të veçantë për 'admin' ose 'menaxhim', nëse stoku i teknologjisë (për shembull, Java/Spring) e lejon këtë, për të ndarë menaxhimin e 'shëndetit' dhe metrikave nga trafiku normal:
    • por mos harroni pikĂ«n 2.
  7. Nëse është e nevojshme, mund të përdorni readiness probe për të ngrohur/ngarkuar cache-në dhe të ktheni kodin e statusit 503, derisa konteineri të 'ngrohet':

Paralajmërime

  1. Mos u mbĂ«shtetni nĂ« varĂ«si tĂ« jashtme (si tĂ« dhĂ«nat e ruajtjes) gjatĂ« testeve pĂ«r gatishmĂ«ri/gjendemĂ«ri — kjo mund tĂ« çojĂ« nĂ« dĂ«shtime tĂ« kaskadĂ«s:
    • si njĂ« shembull, le tĂ« marrim njĂ« shĂ«rbim stateful REST me 10 pod’ë qĂ« varen nga njĂ« bazĂ« tĂ« dhĂ«nash Postgres: kur kontrolli varet nga njĂ« lidhje aktive me DB, tĂ« gjithĂ« 10 pod’ët mund tĂ« dĂ«shtojnĂ« nĂ«se ka njĂ« vonesĂ« nĂ« rrjet/nĂ« anĂ«n e DB-sĂ« — zakonisht kjo pĂ«rfundon mĂ« keq se sa mund tĂ« kishte qenĂ«;
    • vini re se Spring Data kontrollon lidhjen me DB si parazgjedhje*;

      * Kjo Ă«shtĂ« sjellja e parazgjedhjes sĂ« Spring Data Redis (tĂ« paktĂ«n ka qenĂ« kĂ«shtu kur e kontrolova herĂ«n e fundit), e cila çoi nĂ« njĂ« dĂ«shtim "katastrofik": kur Redis ishte pĂ«r njĂ« kohĂ« tĂ« shkurtĂ«r i paqasshĂ«m, tĂ« gjithĂ« pod’ët "dĂ«shtuan".

    • "jashtĂ«" nĂ« kĂ«tĂ« kuptim gjithashtu mund tĂ« nĂ«nkuptojĂ« pod’ët e tjerĂ« tĂ« tĂ« njĂ«jtit aplikacion, domethĂ«nĂ« nĂ« idealin kontrolli nuk duhet tĂ« varet nga gjendja e pod’ëve tĂ« tjerĂ« tĂ« tĂ« njĂ«jtit grup pĂ«r tĂ« parandaloi dĂ«shtimet e kaskadĂ«s:
      • rezultatet mund tĂ« ndryshojnĂ« pĂ«r aplikacionet me gjendje tĂ« shpĂ«rndarĂ« (p.sh., caching nĂ« memorie nĂ« pod’ë).
  2. Mos përdorni liveness probe për pod'ët (përjashtimet janë rastet kur ato janë me të vërtetë të nevojshme dhe ju jeni plotësisht në dijeni të specifikave dhe pasojave të përdorimit të tyre):
    • probe liveness mund tĂ« ndihmojĂ« nĂ« rikuperimin e konteinerĂ«ve 'tĂ« ngecur', por, pasi keni kontroll tĂ« plotĂ« mbi aplikacionin tuaj, situata tĂ« tilla si proceset 'tĂ« ngecura' dhe deadlock nuk duhet tĂ« ndodhin nĂ« mĂ«nyrĂ« ideale: alternativa mĂ« e mirĂ« Ă«shtĂ« rĂ«nia e qĂ«llimshme e aplikacionit dhe rikthimi nĂ« gjendjen e mĂ«parshme tĂ« qĂ«ndrueshme;
    • dĂ«shtimi i probe liveness do tĂ« shkaktojĂ« ribĂ«rjen e konteinerit, duke pĂ«rkeqĂ«suar potencialisht pasojat e gabimeve tĂ« lidhura me ngarkesĂ«n: ribĂ«rja e konteinerit do tĂ« çojĂ« nĂ« pezullim (tĂ« paktĂ«n pĂ«r kohĂ«n e nisjes sĂ« aplikacionit, le tĂ« themi, pĂ«r mĂ« shumĂ« se 30 sekonda), duke shkaktuar gabime tĂ« reja, duke rritur ngarkesĂ«n nĂ« konteinerĂ«t e tjerĂ« dhe duke rritur shanset pĂ«r dĂ«shtimin e tyre, etj.;
    • kontrollimet e liveness nĂ« kombinim me njĂ« varĂ«si tĂ« jashtme janĂ« kombinimi mĂ« i keq i mundshĂ«m, qĂ« rrezikon dĂ«shtime nĂ« cascada: njĂ« vonesĂ« e vogĂ«l nĂ« anĂ«n e DB do tĂ« çojĂ« nĂ« ribĂ«rjen e tĂ« gjithĂ« konteinerĂ«ve tuaj!
  3. Parametrat e kontrolleve liveness dhe readiness duhet të jenë të ndryshëm:
    • mund tĂ« pĂ«rdoret liveness probe me tĂ« njĂ«jtin health check, por me njĂ« prag mĂ« tĂ« lartĂ« aktivizimi (failureThreshold), pĂ«r shembull, tĂ« caktohet statusi not-ready pas 3 pĂ«rpjekjeve dhe tĂ« konsiderohet se liveness probe ka dĂ«shtuar pas 10 pĂ«rpjekjeve;
  4. Mos përdorni kontrolla exec, pasi ato kanë probleme të njohura, që çojnë në shfaqjen e proceseve zombie:

Curriculum Vitae

  • PĂ«rdorni readiness probes pĂ«r tĂ« pĂ«rcaktuar kur pod-i Ă«shtĂ« i gatshĂ«m tĂ« pranojĂ« trafik.
  • PĂ«rdorni liveness probes vetĂ«m kur janĂ« me tĂ« vĂ«rtetĂ« tĂ« nevojshme.
  • PĂ«rdorimi i gabuar i readiness/liveness probes mund tĂ« çojĂ« nĂ« ulje tĂ« disponueshmĂ«risĂ« dhe dĂ«shtime kaskadĂ«.

Provat e jetëgjatësisë në Kubernetes mund të jenë të rrezikshme

Materiale shtesë për temën

PĂ«rditĂ«simi №1 nga 2019-09-29

Për init-kontainerët për migrimin e DB: është shtuar një shënim.

EJ më kujtoi për PDB: një nga problemet e liveness-probave është mungesa e koordinimit mes pod-eve. Në Kubernetes ka Pod Disruption Budgets (PDB) për të kufizuar numrin e dështimeve paralele që aplikacioni mund të përjetojë, megjithatë Kontrollimet nuk marrin parasysh PDB. Idealisht, mund të urdhërojmë K8s: "Rivado një pod, nëse kontrolli i tij dështoi, por mos e rivado të gjithë, që të mos e bësh edhe më keq."

Bryan e formuloi shkëlqyeshëm: "Përdorni sondimin e gjallërisë kur e dini saktësisht se gjëja më e mirë që mund të bëni është të 'vritni' aplikacionin" (përsëri, mos i jepni shumë).

Provat e jetëgjatësisë në Kubernetes mund të jenë të rrezikshme

Kënaqësi e dytë nga 2019-09-29

Sa i përket leximit të dokumentacionit para përdorimit: krijova një kërkesë përkatëse (kërkesë për karakteristika) për të shtuar dokumentacionin për sondat e gjallërisë.

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster