🥇Kubernetesen bizitasun zundak arriskutsuak izan daitezke

Ohar. itzul.: Henning Jacobs Zalandoko ingeniari nagusiak behin eta berriz nabaritu ditu arazoak Kubernetesen erabiltzaileen artean bizitasun (eta prest) zunden helburua eta haien erabilera zuzena ulertzeko. Hori dela eta, ohar zabal honetan bildu zituen bere pentsamenduak, azkenean K8s dokumentazioaren parte bihurtuko dena.

Osasun egiaztapenak, Kubernetes-en izenez ezagutzen direnak bizitasun zundak (hau da, literalki, "bideragarritasun-probak" - gutxi gorabehera itzul.), nahiko arriskutsua izan daiteke. Ahal izanez gero, horiek saihestea gomendatzen dut: salbuespen bakarrak dira benetan beharrezkoak direnean eta erabileraren berezitasunak eta ondorioak guztiz jakitun zarenean. Argitalpen honek bizitasun eta presttasun egiaztapenei buruz hitz egingo du, eta zein kasutan ere esango dizu da eta ez dituzu erabili behar.

Nire lankideak Sandor-ek duela gutxi partekatu ditu Twitter-en aurkitzen dituen akats ohikoenak, besteak beste, presttasuna/bizitasun zundak erabiltzearekin lotutakoak:

Gaizki konfiguratuta livenessProbe Karga handiko egoerak areagotu ditzake (elur-bola itzaltzea + edukiontzia/aplikazioa abiarazteko denbora luzea izan daiteke) eta beste ondorio negatibo batzuk ekar ditzake, hala nola menpekotasun-jaitsteak. (ikusi ere nire azken artikulua K3s+ACME konbinazioan eskaera kopurua mugatzeari buruz). Are okerragoa da bizitasun-zunda osasun-kontrol batekin konbinatzen denean, hau da, kanpoko datu-base bat: DB hutsegite bakarrak zure edukiontzi guztiak berrabiaraziko ditu!

Mezu orokorra "Ez erabili bizitasun zundak" kasu honetan ez du asko laguntzen, beraz, ikus dezagun zertarako dauden presttasun eta bizitasun egiaztapenak.

Oharra: beheko proba gehiena jatorriz Zalando-ren garatzaileen barneko dokumentazioan sartu zen.

Presttasuna eta bizitasuna egiaztatzeak

Kubernetes izeneko bi mekanismo garrantzitsu eskaintzen ditu bizitasun-zundak eta prestutasun-zundak. Aldian-aldian ekintzaren bat egiten dute (adibidez, HTTP eskaera bat bidaltzea, TCP konexioa irekitzea edo edukiontzian komando bat exekutatzen) aplikazioak espero bezala funtzionatzen duela baieztatzeko.

Kubernetes-en erabilerak prest zundakedukiontzia trafikoa onartzeko prest dagoen ulertzeko. Leka bat erabiltzeko prest jotzen da bere ontzi guztiak prest badaude. Mekanismo honen erabilera bat Kubernetes zerbitzuetarako (eta batez ere Ingress) backend gisa erabiltzen diren lekak kontrolatzea da.

Bizitasun-zundaketak lagundu Kubernetesi edukiontzia berrabiarazteko garaia noiz den ulertzen. Adibidez, egiaztapen horrek blokeo bat atzematea ahalbidetzen du aplikazio bat leku batean gelditzen denean. Egoera honetan edukiontzia berrabiarazteak aplikazioa martxan jartzen laguntzen du akatsak izan arren, baina kaskadako hutsegiteak ere ekar ditzake (ikus behean).

Bizigarritasun/presttasun egiaztapenak huts egiten dituen aplikazioen eguneraketa bat zabaltzen saiatzen bazara, haren inplementazioa geldiaraziko da Kubernetes egoeraren zain dagoen bitartean. Ready leka guztietatik.

Adibidea

Hona hemen bide bat egiaztatzen duen presttasun zunda baten adibide bat /health HTTP bidez ezarpen lehenetsiekin (tarte: 10 segundo, timeout: 1 segundo, arrakastaren atalasea: 1, hutsegite atalasea: 3):

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

Gomendioak

HTTP amaierako puntua duten mikrozerbitzuetarako (REST, etab.) definitu beti presttasun-zunda bat, aplikazioa (pod) trafikoa onartzeko prest dagoen egiaztatzen duena.
Ziurtatu prest dagoen zunda benetako web zerbitzariaren atakaren erabilgarritasuna estaltzen du:
- administrazio-helburuetarako portuak erabiltzea, "admin" edo "kudeaketa" izenekoa (adibidez, 9090), readinessProbe, ziurtatu amaiera-puntuak OK itzultzen duela HTTP ataka nagusia (8080 adibidez) trafikoa onartzeko* prest badago;
  *Badakit Zalandon behintzat kasu bat gertatu ez zena, hau da. readinessProbe "Kudeaketa" ataka egiaztatu nuen, baina zerbitzaria bera ez zen lanean hasi cachea kargatzeko arazoengatik.
- Prestakuntza-zunda bat aparteko ataka batean erantsiz gero, ataka nagusian gainkarga ez dela islatuko osasun egiaztapenean (hau da, zerbitzariko hari multzoa beteta dago, baina osasun-egiaztapenak dena ondo dagoela erakusten du oraindik. ).
Ziurtatu hori Readiness probek datu-basearen hasierako/migrazioa ahalbidetzen du;
- Hori lortzeko modurik errazena HTTP zerbitzariarekin harremanetan jartzea da hasieratzea amaitu ondoren soilik (adibidez, datu-base bat migratzea. Flyway eta abar.); hau da, osasun-egiaztapenaren egoera aldatu beharrean, ez abiarazi web zerbitzaria datu-basearen migrazioa amaitu arte*.
  * Init edukiontzietatik datu-baseen migrazioak ere exekutatu ditzakezu podetik kanpo. Oraindik aplikazio autonomoen zalea naiz, hau da, aplikazioen edukiontziak datu-basea kanpoko koordinaziorik gabe nahi den egoerara eramaten dakiena.
erabilera httpGet osasun-kontrolen amaierako puntuen bidez prestasuna egiaztatzeko (adibidez, /health).
Ulertu egiaztapen-parametro lehenetsiak (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- aukera lehenetsiek poda bihurtuko dela esan nahi dute ez-prest 30 segundo inguru igaro ondoren (3 huts egin zuten osasun-kontrolak).
Erabili aparteko ataka bat "administraziorako" edo "kudeaketa"rako, teknologia-pilak (adibidez, Java/Spring) aukera ematen badu, osasuna eta estatistiken kudeaketa ohiko trafikotik bereizteko:
- baina ez ahaztu 2. puntuaz.
Beharrezkoa bada, prest dagoen zunda erabil daiteke cachea berotzeko/kargatzeko eta 503 egoera-kode bat itzultzeko edukiontzia berotu arte:
- Txeke berria irakurtzea ere gomendatzen dizut startupProbe, 1.16 bertsioan agertu zen (errusieraz idatzi genuen horri buruz Hemen - gutxi gorabehera. itzul.).

kargu

Ez fidatu kanpoko menpekotasunetan (adibidez, datu biltegiak) presttasun/bizitasun probak exekutatzen direnean - honek kaskadako hutsegiteak ekar ditzake:
- Adibide gisa, har dezagun REST zerbitzu egoera bat, Postgres datu-base baten araberako 10 podekin: egiaztapena DBrako funtzionatzen duen konexio baten araberakoa denean, 10 pod guztiek huts egin dezakete sare/DB aldean atzerapen bat baldin badago - normalean. litekeena baino okerrago amaitzen da guztia;
- Kontuan izan Spring Data-k datu-basearen konexioa lehenespenez egiaztatzen duela*;
  * Hau da Spring Data Redis-en portaera lehenetsia (gutxienez egiaztatu nuen azken aldia izan zen), eta horrek hutsegite "hondamendia" ekarri zuen: Redis denbora laburrean erabilgarri egon ez zenean, pods guztiak "hondatu ziren".
- Zentzu honetan "kanpokoa" aplikazio bereko beste pods batzuk ere esan ditzake, hau da, hobekien egiaztapena ez luke kluster bereko beste pod batzuen egoeraren araberakoa izan behar kaskadako hutsegiterik ez izateko:
  - emaitzak aldatu egin daitezke egoera banatua duten aplikazioetarako (adibidez, memorian katxeatzea podetan).
Ez erabili bizitasun-zundarik leketarako (salbuespenak benetan beharrezkoak diren kasuak dira eta erabileraren berezitasunak eta ondorioak guztiz ezagutzen dituzunean):
- Bizigarritasun-zunda batek zintzilik dauden edukiontziak berreskuratzen lagun dezake, baina zure aplikazioaren kontrol osoa duzunez, zintzilik dauden prozesuak eta blokeoak bezalako gauzak ez lirateke gertatu behar: alternatibarik onena aplikazioa nahita huts egitea eta aurreko egoera egonkorrera itzultzea da;
- huts egin duen bizitasun-zunda batek edukiontzia berrabiaraziko du, eta, hortaz, kargarekin lotutako akatsen ondorioak areagotu ditzake: edukiontzia berrabiaraziz gero, geldialdi-denbora eragingo du (gutxienez aplikazioa abiarazteko irauten duen bitartean, demagun 30 segundo bakoitiak), errore berriak eragingo ditu. , beste ontzi batzuen karga areagotzea eta hauen huts egiteko probabilitatea areagotzea, etab.;
- Kanpoko menpekotasun batekin konbinatutako bizitasun-egiaztapenak ahalik eta konbinaziorik txarrena dira, kaskadako hutsegiteak mehatxatuz: datu-basearen aldean atzerapen txiki batek zure edukiontzi guztiak berrabiaraziko ditu!
Bizigarritasunaren eta presttasunaren egiaztapenen parametroak ezberdina izan behar du:
- bizitasun-zunda bat erabil dezakezu osasun-kontrol berarekin, baina erantzun-atalase altuagoa (failureThreshold), adibidez, egoera esleitu ez-prest 3 saiakeraren ondoren eta kontuan hartu bizitasun zundak huts egin duela 10 saiakeraren ondoren;
Ez erabili exec egiaztapenak, zonbi prozesuen agerpena eragiten duten arazo ezagunekin lotuta baitaude:
- xehetasunak: ikus Datadog-eko espezialisten aurkezpena.

Laburpena

Erabili prestasun-zundaketak pod bat trafikoa jasotzeko prest dagoen jakiteko.
Erabili bizitasun-zundak benetan beharrezkoak direnean soilik.
Presttasun/bizitasun zunden erabilera desegokiak erabilgarritasuna murriztea eta kaskadako hutsegiteak ekar ditzake.

Gaiari buruzko material osagarriak

Kubernetes dokumentuak: konfiguratu bizitasun eta presttasun zundaketak;
Kubernetes-en bizitasuna eta presttasunaren zundaketak berrikusi dira: nola saihestu zeure buruari beste oinean tiro egitea;
NRE Labs Outage Post-Mortem (livenessProbe-ri buruz ere hitz egiten du).

1-2019-09ko 29. zenbakia

Datu-baseen migraziorako init edukiontziei buruz: Oin-oharra gehitu da.

EJk gogorarazi dit PDBri buruz: bizitasun-kontrolen arazoetako bat leken arteko koordinazio falta da. Kubernetesek dauka Pod eten aurrekontuak (PDB) aplikazio batek izan ditzakeen aldibereko hutsegite kopurua mugatzeko, hala ere kontrolek ez dute PDBa kontuan hartzen. Egokiena, K8-ri esan genioke "Berrabiarazi pod bat bere probak huts egiten badu, baina ez berrabiarazi guztiak gauzak okerrago ez daitezen".

Bryanek primeran esan zuen: “Erabili bizitasuna probatzea zehazki zer dakizunean onena aplikazioa hiltzea da"(berriz ere, ez utzi eraman).

2-2019-09ko 29. zenbakia

Erabili aurretik dokumentazioa irakurtzeari dagokionez: Dagokion eskaera sortu dut (eginbide eskaera) bizitasun-zundei buruzko dokumentazioa gehitzeko.

PS itzultzailetik

Irakurri ere gure blogean:

Iturria: www.habr.com

Kubernetesen bizitasun-zundaketak arriskutsuak izan daitezke