🥇Lêkolînên zindîbûnê yên li Kubernetes dikarin xeternak bin

Not. werger.: Endezyarê sereke ji Zalando, Henning Jacobs, çend caran di nav bikarhênerên Kubernetes de di têgihîştina armanca lêkolînên zindî (û amadeyiyê) û karanîna wan a rast de pirsgirêkan dîtiye. Ji ber vê yekê, wî ramanên xwe di vê nota berbiçav de berhev kir, ku dê di dawiyê de bibe beşek ji belgeyên K8s.

Kontrolên tenduristiyê, ku di Kubernetes de tê zanîn sondajên zindîtiyê (ango, bi rastî, "ceribandinên zindîbûnê" - bi qasî werger.), dikare pir xeternak be. Ez pêşniyar dikim ku heke gengaz be ji wan dûr bixin: îstîsna tenê gava ku ew bi rastî hewce ne û hûn bi taybetî û encamên karanîna wan bi tevahî agahdar in. Ev weşan dê li ser kontrolên zindîtî û amadebûnê biaxive, û dê di çi rewşan de jî ji we re vebêje ye û divê hûn wan bikar neynin.

Hevkarê min Sandor di van demên dawî de li ser Twitterê xeletiyên herî gelemperî ku pê re rû bi rû maye parve kir, di nav de yên ku bi karanîna lêkolînên amadehî / zindîtiyê ve girêdayî ne:

Bi xeletî vesaz kirin livenessProbe dikare rewşên bargiraniyê girantir bike (qandina topa berfê + dema destpêkirina konteynerê/serîlêdanê ya potansiyel dirêj) û bibe sedema encamên neyînî yên din ên wekî daketina girêdanê. (binihêre jî gotara min a dawî di derbarê sînorkirina hejmara daxwaznameyên di kombînasyona K3s + ACME de). Dema ku lêpirsîna zindîtiyê bi kontrolek tenduristiyê re, ku databasek derveyî ye, were hev kirin hîn xirabtir e: têkçûnek yek DB dê hemî konteynerên we ji nû ve bide destpêkirin!

Peyama giştî "Lêkolînên zindîtiyê bikar neynin" di vê rewşê de ew pir arîkar nake, ji ber vê yekê em binihêrin ku kontrolên amadehî û zindîtiyê ji bo çi ne.

Nîşe: Piraniya ceribandina jêrîn bi eslê xwe di belgeya pêşdebirê navxweyî ya Zalando de bû.

Kontrolên Amadekarî û Liveness

Kubernetes du mekanîzmayên girîng ên ku jê re têne gotin peyda dike sondajên zindîtiyê û lêkolînên amadehiyê. Ew bi periyodîk hin çalakiyan dikin - wek şandina daxwazek HTTP, vekirina girêdanek TCP, an pêkanîna fermanek di konteynerê de - da ku piştrast bikin ku serîlêdan wekî ku tê hêvî kirin dixebite.

Kubernetes bikar tîne sondajên amadebûnêji bo ku fêm bikin dema ku konteynir amade ye ku seyrûseferê qebûl bike. Ger ku hemî konteynerên wê amade bin, podek ji bo karanîna amade tê hesibandin. Yek karanîna vê mekanîzmayê ev e ku meriv kontrol bike ka kîjan pod ji bo karûbarên Kubernetes (û nemaze Ingress) wekî paşvekêşan têne bikar anîn.

Lêkolînên zindîbûnê ji Kubernetes re bibin alîkar ku fêm bikin kengê dema ji nû ve destpêkirina konteynerê ye. Mînakî, kontrolek wusa dihêle hûn gava ku serîlêdanek li yek cîhek asê dibe, xitimandinek asteng bike. Ji nû ve destpêkirina konteynerê di vê rewşê de dibe alîkar ku serîlêdanê tevî xeletiyan ji erdê derkeve, lê ew di heman demê de dibe sedema têkçûnên kaskadî (li jêr binêre).

Ger hûn hewl bidin ku nûvekirinek serîlêdanê ya ku di kontrolên jîndî/amadebûnê de têk diçe bicîh bikin, gava ku Kubernetes li benda statûyê ye, pêşandana wê raweste. Ready ji hemû daran.

Nimûne:

Li vir mînakek lêkolînek amadebûnê ye ku rêyek kontrol dike /health bi rêya HTTP bi mîhengên xwerû (navber: 10 Çirke, başim: 1 çirk, sînorê serkeftinê: 1, sînorê têkçûnê: 3):

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

pêşnîyarên

Ji bo mîkroxizmetên bi xala dawiya HTTP (REST, hwd.) her tim lêpirsînek amadebûnê diyar dike, ku kontrol dike ka serîlêdan (pod) amade ye ku seyrûseferê qebûl bike.
Piştrast bikin ku lêkolîna amadebûnê hebûna porta servera webê ya rastîn vedigire:
- bikaranîna portan ji bo mebestên îdarî, ku jê re "admin" an "rêveberî" tê gotin (mînak, 9090), ji bo readinessProbe, pê ewle bin ku xala dawî tenê baş vedigere ger porta HTTP ya bingehîn (wek 8080) amade ye ku seyrûseferê qebûl bike*;
  *Li Zalandoyê herî kêm haya min ji bûyerek heye ku ev yek çênebûye, yanî. readinessProbe Min porta "rêveberiyê" kontrol kir, lê server bixwe ji ber pirsgirêkên barkirina cache dest bi xebatê nekir.
- girêdana lêkolînek amadehiyê bi portek cihêreng dikare bibe sedema vê rastiyê ku zêdebarkirina porta sereke dê di kontrolkirina tenduristiyê de neyê xuyang kirin (ango, hewza tîrêjê ya li ser serverê tije ye, lê kontrolkirina tenduristiyê hîn jî destnîşan dike ku her tişt baş e ).
Bawer bikin ku lêkolîna amadebûnê destpêkirina/koçberkirina databasê çalak dike;
- Awayê herî hêsan ji bo bidestxistina vê ev e ku meriv bi servera HTTP re têkilî dayne tenê piştî ku destipêkirin qediya (mînak, koçkirina databasek ji Flyway wate ya vê çîye.); ango, li şûna ku hûn statûya kontrolkirina tenduristiyê biguhezînin, heya ku koça databasê neqede, bi tenê servera malperê dest pê nekin*.
  * Her weha hûn dikarin koçên databasê ji konteynerên destpêkê yên li derveyî podê bimeşînin. Ez hîn jî heyranê serîlêdanên xweser im, ango yên ku tê de konteynera serîlêdanê dizane ku çawa databasê bêyî hevrêziya derveyî bîne rewşa xwestî.
Bikar bînin httpGet ji bo kontrolên amadehiyê bi riya xalên dawîn ên kontrolê yên tenduristiyê yên tîpîk (mînak, /health).
Parametreyên kontrolê yên xwerû fam bikin (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- vebijarkên xwerû tê vê wateyê ku dê pod bibe ne amade ne piştî nêzîkê 30 çirke (3 kontrolên aqilê têkçûyî).
Ji bo "rêveber" an "rêveberî" portek cihêreng bikar bînin heke stoka teknolojiyê (mînak Java/Spring) destûrê dide wê, ku rêveberiya tenduristî û metrîkê ji seyrûsefera birêkûpêk veqetîne:
- lê xala 2 ji bîr neke.
Ger hewce be, sondaya amadebûnê dikare were bikar anîn da ku kaşê germ bike/bar bike û kodek statûya 503 vegerîne heya ku konteynir germ bibe:
- Ez jî pêşniyar dikim ku hûn kontrolê nû bixwînin startupProbe, di guhertoya 1.16 de xuya bû (me li ser wê bi rûsî nivîsî vir - nêzîkî. werger.).

Caveats

Pişta xwe nedin girêdanên derve (wek embarên daneyê) dema ku ceribandinên amadehiyê / zindîtiyê dimeşînin - ev dikare bibe sedema têkçûnên kaskadî:
- Mînakî, em karûbarek REST-ya dewletdar bi 10 pods ve girêdayî li ser databasek Postgres-ê bigirin: gava ku kontrol bi girêdanek xebitandinê ya bi DB-ê ve girêdayî ye, heke li ser torê / DB dereng dereng hebe dibe ku hemî 10 pod têk biçin - bi gelemperî ew hemû dawî ji wê xerabtir;
- Ji kerema xwe not bikin ku Daneyên Biharê pêwendiya databasê ji hêla xwerû ve kontrol dike*;
  * Ev tevgera xwerû ya Spring Data Redis e (bi kêmanî ew cara paşîn bû ku min kontrol kir), ku bû sedema têkçûnek "felaketî": dema ku Redis ji bo demek kin nehat peyda kirin, hemî pod "qelibandin".
- Di vê wateyê de "derveyî" di heman demê de dikare were wateya pelên din ên heman serîlêdanê jî, ango, bi îdeal divê kontrol bi rewşa polên din ên heman komê ve girêdayî nemîne da ku pêşî li têkçûna kavilan bigire:
  - dibe ku encam ji bo serîlêdanên bi rewşa belavbûyî biguhere (mînakî, cachkirina nav-bîrê li pods).
Lêpirsîna zindîtiyê bikar neynin ji bo pods (îstîsna rewşên ku ew bi rastî hewce ne û hûn ji taybetî û encamên karanîna wan bi tevahî agahdar in):
- Lêpirsînek jîngehê dikare ji nûvekirina konteynerên daliqandî re bibe alîkar, lê ji ber ku we kontrola tam li ser serîlêdana xwe heye, tiştên mîna pêvajoyên daliqandinê û xitimandin divê bi îdeal çênebin: alternatîfa çêtirîn ev e ku hûn bi qestî serîlêdanê hilweşînin û wê vegerînin rewşa domdar a berê;
- lêpirsînek zindî ya têkçûyî dê bibe sedem ku konteynir ji nû ve dest pê bike, bi vî rengî encamên xeletiyên girêdayî barkirinê girantir bike: ji nû ve destpêkirina konteynerê dê bibe sedema demajoyê (qet nebe ji bo dema destpêkirina serîlêdanê, bêje 30-saniyeyên din), bibe sedema xeletiyên nû. , zêdekirina barkirina li ser konteynerên din û zêdekirina îhtîmala têkçûna wan, hwd.;
- Kontrolên zindîtiyê yên ku bi pêwendiyek derveyî ve têne hevber kirin, tevliheviya herî xirab a gengaz e, xetereya têkçûnên kaskadê dixwe: derengiyek piçûk li ser bingeha databasê dê bibe sedema ji nû ve destpêkirina hemî konteynerên we!
Parametreyên kontrolên zindîbûn û amadebûnê divê cuda be:
- hûn dikarin bi heman kontrolkirina tenduristiyê, lê bendek bersivê ya bilindtir lêkolînek zindîtiyê bikar bînin (failureThreshold), ji bo nimûne, statuyê destnîşan bikin ne amade ne piştî 3 hewldanan û bihesibînin ku lêpirsîna zindîtiyê piştî 10 hewldanan têk çûye;
Kontrolên exec bikar neynin, ji ber ku ew bi pirsgirêkên naskirî yên ku dibin sedema xuyabûna pêvajoyên zombî ve girêdayî ne:
- hûragahiyan: bibînin pêşkêşkirina pisporên Datadog.

Nîqaş

Lêkolînên amadebûnê bikar bînin da ku diyar bikin ka kengê pod amade ye ku seyrûseferê werbigire.
Vekolînên zindîtiyê tenê gava ku ew bi rastî hewce ne bikar bînin.
Bikaranîna nerast a lêkolînên amadehî/jîyanê dikare bibe sedema kêmbûna hebûna û têkçûnên kaskadî.

Materyalên din ên li ser mijarê

Belgeyên Kubernetes: Vekolînên Liveness û Amadekariyê mîheng bikin;
Kubernetes Liveness and Readiness Proses Revisited: Meriv Meriv Çawa Xwe Di Piyê Din de Teqele Bike;
NRE Labs Outage Post-Mortem (ew jî li ser livenessProbe diaxive).

Nûvekirina Hejmar 1 ji 2019-09-29

Der barê konteynerên init de ji bo koçkirina databasê: Pênotê zêde kirin.

EJ hat bîra min di derbarê PDB de: yek ji pirsgirêkên bi kontrolên zindîtiyê nebûna hevrêziya di navbera pods de ye. Kubernetes heye Budçeyên Astengkirina Pod (PDB) ji bo sînorkirina hejmara têkçûnên hevdemî ku serîlêdanek dikare biceribîne, di heman demê de kontrol PDB-ê li ber çavan nagire. Bi îdeal, em dikarin ji K8s re bibêjin "Heke ceribandina wê têk çû yek pod ji nû ve bidin destpêkirin, lê wan hemîyan ji nû ve nekin da ku tiştan xirabtir nekin."

Bryan ew bi tevahî destnîşan kir: “Dema ku hûn tam zanin çi zanibin, vekolîna zindîtiyê bikar bînin ya herî baş ew e ku meriv serîlêdanê bikuje"(Dîsa, xwe negirin).

Nûvekirina Hejmar 2 ji 2019-09-29

Di derbarê xwendina belgeyê de berî karanîna: Min daxwaza peywendîdar çêkir (daxwaza taybetmendiyê) ji bo lêzêdekirina belgeyên li ser lêkolînên zindîtiyê.

PS ji wergêr

Li ser bloga me jî bixwînin:

Source: www.habr.com

Lêpirsînên zindîbûnê yên li Kubernetes dikarin xeternak bin