🥇 Gall stilwyr bywioldeb yn Kubernetes fod yn beryglus

Nodyn. traws.: Mae peiriannydd arweiniol o Zalando, Henning Jacobs, wedi sylwi dro ar ôl tro ar broblemau ymhlith defnyddwyr Kubernetes wrth ddeall pwrpas chwilwyr bywiogrwydd (a pharodrwydd) a'u defnydd cywir. Felly, casglodd ei feddyliau yn y nodyn galluog hwn, a fydd yn y pen draw yn dod yn rhan o ddogfennaeth K8s.

Gwiriadau iechyd, a elwir yn Kubernetes fel chwilwyr bywiogrwydd (h.y., yn llythrennol, “profion hyfywedd” - tua. cyfieithiad.), yn gallu bod yn eithaf peryglus. Rwy'n argymell eu hosgoi os yn bosibl: yr unig eithriadau yw pan fyddant yn wirioneddol angenrheidiol a'ch bod yn gwbl ymwybodol o fanylion a chanlyniadau eu defnydd. Bydd y cyhoeddiad hwn yn sôn am wiriadau bywiogrwydd a pharodrwydd, a bydd hefyd yn dweud wrthych ym mha achosion yn ac ni ddylech eu defnyddio.

Yn ddiweddar, rhannodd fy nghydweithiwr Sandor ar Twitter y gwallau mwyaf cyffredin y mae’n dod ar eu traws, gan gynnwys y rhai sy’n ymwneud â defnyddio chwilwyr parodrwydd / bywiogrwydd:

Wedi'i ffurfweddu'n anghywir livenessProbe yn gallu gwaethygu sefyllfaoedd llwyth uchel (cau pelen eira + amser cychwyn cynhwysydd / cais hir o bosibl) ac arwain at ganlyniadau negyddol eraill fel diferion dibyniaeth (Gweld hefyd fy erthygl ddiweddar ynghylch cyfyngu ar nifer y ceisiadau yn y cyfuniad K3s+ACME). Mae hyd yn oed yn waeth pan gyfunir y stiliwr bywiogrwydd â gwiriad iechyd, sef cronfa ddata allanol: bydd un methiant DB yn ailgychwyn eich holl gynwysyddion!

Neges gyffredinol "Peidiwch â defnyddio chwilwyr bywiogrwydd" yn yr achos hwn nid yw'n helpu llawer, felly gadewch i ni edrych ar beth yw pwrpas y gwiriadau parodrwydd a bywiogrwydd.

Nodyn: Cafodd y rhan fwyaf o'r prawf isod ei gynnwys yn wreiddiol yn nogfennaeth datblygwr mewnol Zalando.

Gwiriadau Parodrwydd a Bywioldeb

Mae Kubernetes yn darparu dau fecanwaith pwysig o'r enw chwilwyr bywiogrwydd a chwilwyr parodrwydd. Maent yn cyflawni rhai camau o bryd i'w gilydd - megis anfon cais HTTP, agor cysylltiad TCP, neu weithredu gorchymyn yn y cynhwysydd - i gadarnhau bod y cais yn gweithio yn ôl y disgwyl.

Kubernetes yn defnyddio chwilwyr parodrwyddi ddeall pryd mae'r cynhwysydd yn barod i dderbyn traffig. Ystyrir bod pod yn barod i'w ddefnyddio os yw ei holl gynwysyddion yn barod. Un defnydd o'r mecanwaith hwn yw rheoli pa godennau sy'n cael eu defnyddio fel backendes ar gyfer gwasanaethau Kubernetes (ac yn enwedig Ingress).

Ymchwilwyr bywioliaeth helpu Kubernetes i ddeall pryd mae'n amser ailgychwyn y cynhwysydd. Er enghraifft, mae gwiriad o'r fath yn eich galluogi i ryng-gipio terfyn amser pan fydd cais yn mynd yn sownd mewn un lle. Mae ailgychwyn y cynhwysydd yn y cyflwr hwn yn helpu i gael y cais oddi ar y ddaear er gwaethaf gwallau, ond gall hefyd arwain at fethiannau rhaeadru (gweler isod).

Os ceisiwch ddefnyddio diweddariad cais sy'n methu'r gwiriadau bywiogrwydd / parodrwydd, bydd ei gyflwyniad yn cael ei atal wrth i Kubernetes aros am y statws Ready o bob cod.

Enghraifft

Dyma enghraifft o chwiliwr parodrwydd yn gwirio llwybr /health trwy HTTP gyda gosodiadau diofyn (cyfwng: 10 eiliad, Terfyn amser: 1 eiliad, trothwy llwyddiant: 1, trothwy methiant:3):

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

Argymhellion

Ar gyfer microwasanaethau gyda phwynt terfyn HTTP (REST, ac ati) diffiniwch chwiliedydd parodrwydd bob amser, sy'n gwirio a yw'r cais (pod) yn barod i dderbyn traffig.
Sicrhewch fod y chwiliwr parodrwydd yn cwmpasu argaeledd y porth gweinydd gwe gwirioneddol:
- defnyddio porthladdoedd at ddibenion gweinyddol, o'r enw "gweinyddol" neu "reoli" (er enghraifft, 9090), ar gyfer readinessProbe, gwnewch yn siŵr bod y pwynt terfyn ond yn dychwelyd yn iawn os yw'r prif borthladd HTTP (fel 8080) yn barod i dderbyn traffig *;
  *Rwy’n ymwybodol o o leiaf un achos yn Zalando lle na ddigwyddodd hyn, h.y. readinessProbe Gwiriais y porthladd “rheoli”, ond ni ddechreuodd y gweinydd ei hun weithio oherwydd problemau wrth lwytho'r storfa.
- gall gosod stiliwr parodrwydd i borthladd ar wahân arwain at y ffaith na fydd gorlwytho ar y prif borthladd yn cael ei adlewyrchu yn y gwiriad iechyd (hynny yw, mae'r pwll edau ar y gweinydd yn llawn, ond mae'r gwiriad iechyd yn dal i ddangos bod popeth yn iawn ).
Sicrhewch hynny chwiliwr parodrwydd yn galluogi cychwyn/mudo cronfa ddata;
- Y ffordd hawsaf o gyflawni hyn yw cysylltu â'r gweinydd HTTP dim ond ar ôl cwblhau'r cychwyniad (er enghraifft, mudo cronfa ddata o Hedfan ac yn y blaen.); hynny yw, yn lle newid statws y gwiriad iechyd, peidiwch â chychwyn y gweinydd gwe nes bod mudo'r gronfa ddata wedi'i gwblhau*.
  * Gallwch hefyd redeg mudo cronfa ddata o gynwysyddion init y tu allan i'r pod. Rwy'n dal i fod yn gefnogwr o gymwysiadau hunangynhwysol, hynny yw, y rhai y mae cynhwysydd y cais yn gwybod sut i ddod â'r gronfa ddata i'r cyflwr dymunol heb gydgysylltu allanol.
Defnyddiwch httpGet ar gyfer gwiriadau parodrwydd trwy bwyntiau terfyn archwiliad iechyd nodweddiadol (er enghraifft, /health).
Deall y paramedrau gwirio rhagosodedig (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- mae'r opsiynau rhagosodedig yn golygu y bydd y pod yn dod ddim yn barod ar ôl tua 30 eiliad (methodd 3 gwiriad pwyll).
Defnyddiwch borthladd ar wahân ar gyfer "admin" neu "reoli" os yw'r pentwr technoleg (e.e. Java/Spring) yn caniatáu hynny, i wahanu rheolaeth iechyd a metrigau oddi wrth draffig rheolaidd:
- ond peidiwch ag anghofio am bwynt 2.
Os oes angen, gellir defnyddio'r stiliwr parodrwydd i gynhesu / llwytho'r storfa a dychwelyd cod statws 503 nes bod y cynhwysydd yn cynhesu:
- Rwyf hefyd yn argymell eich bod yn darllen y siec newydd startupProbe, ymddangosodd yn fersiwn 1.16 (Ysgrifennon ni amdano yn Rwsieg yma - tua. cyfieithu.).

Caveats

Peidiwch â dibynnu ar ddibyniaethau allanol (fel warysau data) wrth gynnal profion parodrwydd/bywder - gall hyn arwain at fethiannau rhaeadru:
- Er enghraifft, gadewch i ni gymryd gwasanaeth REST urddasol gyda 10 cod yn dibynnu ar un gronfa ddata Postgres: pan fydd y siec yn dibynnu ar gysylltiad gweithredol â'r DB, gall pob un o'r 10 pod fethu os oes oedi ar yr ochr rhwydwaith / DB - fel arfer y cwbl yn terfynu yn waeth nag y gallai ;
- Sylwch fod Spring Data yn gwirio cysylltiad y gronfa ddata yn ddiofyn*;
  * Dyma ymddygiad rhagosodedig Spring Data Redis (o leiaf dyma'r tro diwethaf i mi wirio), a arweiniodd at fethiant "trychinebus": pan nad oedd Redis ar gael am gyfnod byr, fe chwalodd pob codennau.
- Gall “allanol” yn yr ystyr hwn hefyd olygu codennau eraill o'r un cais, hynny yw, yn ddelfrydol ni ddylai'r gwiriad ddibynnu ar gyflwr codennau eraill o'r un clwstwr i atal damweiniau rhaeadru:
  - gall y canlyniadau amrywio ar gyfer ceisiadau â chyflwr gwasgaredig (er enghraifft, celcio mewn cof mewn codennau).
Peidiwch â defnyddio stiliwr bywiogrwydd ar gyfer codennau (eithriadau yw achosion pan fyddant yn wirioneddol angenrheidiol a'ch bod yn gwbl ymwybodol o fanylion a chanlyniadau eu defnyddio):
- Gall stiliwr bywiogrwydd helpu i adennill cynwysyddion wedi'u hongian, ond gan fod gennych reolaeth lawn dros eich cais, yn ddelfrydol ni ddylai pethau fel prosesau hongian a chloeon di-baid ddigwydd: y dewis arall gorau yw chwalu'r cymhwysiad yn fwriadol a dod ag ef yn ôl i gyflwr sefydlog blaenorol;
- bydd stiliwr bywiogrwydd a fethwyd yn achosi i'r cynhwysydd ailgychwyn, a thrwy hynny o bosibl waethygu canlyniadau gwallau sy'n gysylltiedig â llwytho: bydd ailgychwyn y cynhwysydd yn arwain at amser segur (o leiaf am gyfnod cychwyn y cais, dyweder 30 eiliad od), gan achosi gwallau newydd , cynyddu'r llwyth ar gynwysyddion eraill a chynyddu'r tebygolrwydd y byddant yn methu, ac ati;
- gwiriadau bywiogrwydd ynghyd â dibyniaeth allanol yw'r cyfuniad gwaethaf posibl, gan fygwth methiannau rhaeadru: bydd ychydig o oedi ar ochr y gronfa ddata yn arwain at ailgychwyn eich holl gynwysyddion!
Paramedrau o wiriadau bywiogrwydd a pharodrwydd rhaid bod yn wahanol:
- gallwch ddefnyddio stiliwr bywiogrwydd gyda'r un gwiriad iechyd, ond trothwy ymateb uwch (failureThreshold), er enghraifft, aseinio'r statws ddim yn barod ar ôl 3 ymgais ac yn ystyried bod y chwiliwr bywiogrwydd wedi methu ar ôl 10 ymgais;
Peidiwch â defnyddio gwiriadau exec, gan eu bod yn gysylltiedig â phroblemau hysbys sy'n arwain at ymddangosiad prosesau zombie:
- manylion: gw cyflwyniad gan arbenigwyr Datadog.

Crynodeb

Defnyddiwch chwiliedyddion parodrwydd i benderfynu pryd mae pod yn barod i dderbyn traffig.
Defnyddiwch chwiliedyddion bywiogrwydd dim ond pan fydd eu gwir angen.
Gall defnydd amhriodol o chwiliedyddion parodrwydd/bywrwydd arwain at lai o argaeledd a methiannau rhaeadru.

Deunyddiau ychwanegol ar y pwnc

Dogfennau Kubernetes: Ffurfweddu Profion Bywiogrwydd a Pharodrwydd;
Adolygwyd Ymchwilwyr Bywioldeb a Pharodrwydd Kubernetes: Sut i Osgoi Saethu Eich Hun ar y Traed Arall;
Post-mortem Gwahanu Labordai NRE (mae hefyd yn sôn am livenessProbe).

Diweddariad Rhif 1 o 2019-09-29

Ynglŷn â chynwysyddion init ar gyfer mudo cronfa ddata: Ychwanegwyd troednodyn.

Atgoffodd EJ fi am PDB: un o'r problemau gyda gwiriadau bywiogrwydd yw'r diffyg cydgysylltu rhwng codennau. Kubernetes wedi Cyllidebau Amhariad Pod (PDB) i gyfyngu ar nifer y methiannau cydamserol y gall cais eu profi, fodd bynnag nid yw'r gwiriadau yn ystyried y PDB. Yn ddelfrydol, gallem ddweud wrth K8s i "Ailgychwyn un pod os bydd ei brawf yn methu, ond peidiwch â'u hailddechrau i gyd er mwyn osgoi gwneud pethau'n waeth."

Rhoddodd Bryan y peth yn berffaith: “Defnyddiwch stilio bywiogrwydd pan fyddwch chi'n gwybod yn union beth y peth gorau i'w wneud yw lladd y cais"(eto, peidiwch â mynd dros ben llestri).

Diweddariad Rhif 2 o 2019-09-29

Ynglŷn â darllen y ddogfennaeth cyn ei defnyddio: creais y cais cyfatebol (cais nodwedd) ychwanegu dogfennaeth am chwilwyr bywiogrwydd.

PS gan y cyfieithydd

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Gall stilwyr bywiogrwydd yn Kubernetes fod yn beryglus