Kubernetesin elävyyden mittaukset voivat olla vaarallisia

Huomautus. käännös: Zalandon johtava insinööri Henning Jacobs on toistuvasti havainnut ongelmia Kubernetesin käyttäjien keskuudessa elävyyden (ja valmiuden) antureiden tarkoituksen ja niiden oikean käytön ymmärtämisessä. Siksi hän kokosi ajatuksensa tähän tilavaan muistiinpanoon, josta tulee lopulta osa K8:n dokumentaatiota.

Terveystarkastukset, tunnetaan Kubernetesissa nimellä elävyyden mittareita (eli kirjaimellisesti "elinkelpoisuustestit" - noin käännös.), voi olla aika vaarallista. Suosittelen välttämään niitä, jos mahdollista: ainoat poikkeukset ovat silloin, kun ne ovat todella tarpeellisia ja olet täysin tietoinen niiden käytön erityispiirteistä ja seurauksista. Tässä julkaisussa puhutaan elävyydestä ja valmiustarkastuksista ja kerrotaan myös missä tapauksissa on eikä niitä kannata käyttää.

Kollegani Sandor jakoi äskettäin Twitterissä yleisimmät kohtaamansa virheet, mukaan lukien valmius-/elävyysanturien käyttöön liittyvät virheet:

Virheellisesti määritetty livenessProbe voi pahentaa korkean kuormituksen tilanteita (lumipallon sammutus + mahdollisesti pitkä säiliön/sovelluksen käynnistysaika) ja johtaa muihin kielteisiin seurauksiin, kuten riippuvuuden vähenemiseen (Katso myös tuore artikkelini pyyntöjen määrän rajoittamisesta K3s+ACME-yhdistelmässä). Vielä pahempaa on, kun elävyysanturi yhdistetään terveystarkastukseen, joka on ulkoinen tietokanta: yksi DB-virhe käynnistää kaikki säilösi uudelleen!

Yleinen viesti "Älä käytä eloisuusantureita" tässä tapauksessa se ei paljoa auta, joten katsotaanpa, mitä varten valmius- ja elävyystarkastukset ovat.

Huomautus: Suurin osa alla olevasta testistä sisältyi alun perin Zalandon sisäiseen kehittäjädokumentaatioon.

Valmiuden ja elävyyden tarkastukset

Kubernetes tarjoaa kaksi tärkeää mekanismia nimeltä elävyysluodaimet ja valmiusluodaimet. He suorittavat ajoittain joitain toimintoja – kuten lähettävät HTTP-pyynnön, avaavat TCP-yhteyden tai suorittavat komennon säilössä – varmistaakseen, että sovellus toimii odotetulla tavalla.

Kubernetes käyttää valmiusanturitymmärtääkseen, milloin kontti on valmis vastaanottamaan liikennettä. Pallo katsotaan käyttövalmiiksi, jos kaikki sen säiliöt ovat valmiita. Yksi tämän mekanismin käyttötavoista on hallita, mitä podeja käytetään Kubernetes-palveluiden (ja erityisesti Ingressin) taustaohjelmina.

Elävyyttä mittaavat auttaa Kubernetesia ymmärtämään, milloin on aika käynnistää säilö uudelleen. Tällaisen tarkistuksen avulla voit esimerkiksi siepata lukkiutumisen, kun sovellus juuttuu yhteen paikkaan. Säilön käynnistäminen uudelleen tässä tilassa auttaa saamaan sovelluksen liikkeelle virheistä huolimatta, mutta se voi myös johtaa peräkkäisiin virheisiin (katso alla).

Jos yrität ottaa käyttöön sovelluspäivityksen, joka epäonnistuu elävyys-/valmiustarkistuksissa, sen käyttöönotto pysähtyy, kun Kubernetes odottaa tilaa Ready kaikista paloista.

Esimerkki

Tässä on esimerkki valmiusanturista, joka tarkistaa polun /health HTTP:n kautta oletusasetuksilla (intervalli: 10 sekuntia, aikakatkaisu: 1 sekunti, onnistumisen kynnys: 1, epäonnistumisen kynnys: 3):

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

Suositukset

1. Mikropalveluille, joissa on HTTP-päätepiste (REST jne.) määritä aina valmiusanturi, joka tarkistaa, onko sovellus (pod) valmis vastaanottamaan liikennettä.
2. Varmista valmiusanturi kattaa todellisen verkkopalvelinportin saatavuuden:
   • porttien käyttäminen hallinnollisiin tarkoituksiin, nimeltään "admin" tai "management" (esimerkiksi 9090), readinessProbe, varmista, että päätepiste palauttaa OK vain, jos ensisijainen HTTP-portti (kuten 8080) on valmis vastaanottamaan liikennettä*;

     *Olen tietoinen Zalandossa ainakin yhdestä tapauksesta, jossa näin ei tapahtunut, ts. readinessProbe Tarkistin "hallinta"-portin, mutta itse palvelin ei alkanut toimia välimuistin latausongelmien vuoksi.

   • valmiusanturin liittäminen erilliseen porttiin voi johtaa siihen, että pääportin ylikuormitus ei näy kuntotarkastuksessa (eli palvelimen lankavarasto on täynnä, mutta kuntotarkastus näyttää silti, että kaikki on kunnossa ).
3. Varmista että Readiness Probe mahdollistaa tietokannan alustuksen/siirtämisen;
   • Helpoin tapa saavuttaa tämä on ottaa yhteyttä HTTP-palvelimeen vasta, kun alustus on valmis (esimerkiksi tietokannan siirtäminen lentotie ja niin edelleen.); eli sen sijaan, että muuttaisit kuntotarkastuksen tilaa, älä yksinkertaisesti käynnistä verkkopalvelinta ennen kuin tietokannan siirto on valmis*.

     * Voit myös suorittaa tietokantojen siirtoja alustan ulkopuolelta olevista aloitussäiliöistä. Olen edelleen itsenäisten sovellusten fani, eli sellaisia, joissa sovelluskontti osaa viedä tietokannan haluttuun tilaan ilman ulkoista koordinointia.

4. käyttö httpGet valmiustarkistuksia varten tyypillisten terveystarkastusten päätepisteiden kautta (esim. /health).
5. Ymmärrä oletustarkistusparametrit (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • oletusasetukset tarkoittavat, että pod tulee ei ole valmis noin 30 sekunnin kuluttua (3 epäonnistunutta mielenterveystarkastusta).
6. Käytä erillistä porttia "admin" tai "management", jos teknologiapino (esim. Java/Spring) sallii sen, erottaaksesi terveydentilan ja mittareiden hallinnan tavallisesta liikenteestä:
   • mutta älä unohda kohtaa 2.
7. Tarvittaessa valmiusanturia voidaan käyttää välimuistin lämmittämiseen/lataamiseen ja 503-tilakoodin palauttamiseen, kunnes säiliö lämpenee:
   • Suosittelen myös uuden sekin lukemista startupProbe, ilmestyi versiossa 1.16 (kirjoitimme siitä venäjäksi täällä - noin käännös.).

varoitukset

1. Älä luota ulkoisiin riippuvuuksiin (kuten tietovarastot) suoritettaessa valmius-/elinvoimatestejä – tämä voi johtaa peräkkäisiin virheisiin:
   • Otetaan esimerkkinä tilallinen REST-palvelu, jossa on 10 podia yhdestä Postgres-tietokannasta riippuen: kun tarkistus riippuu toimivasta yhteydestä DB:hen, kaikki 10 podia voivat epäonnistua, jos verkko/DB-puolella on viive - yleensä se kaikki päättyy huonommin kuin se voisi;
   • Huomaa, että Spring Data tarkistaa tietokantayhteyden oletuksena*;

     * Tämä on Spring Data Rediksen oletuskäyttäytyminen (ainakin se oli viimeinen kerta kun tarkistin), mikä johti "katastrofiseen" virheeseen: kun Redis ei ollut käytettävissä hetken, kaikki podit "kaatuivat".

   • "ulkoinen" tässä mielessä voi tarkoittaa myös muita saman sovelluksen podeja, eli ihannetapauksessa tarkistus ei saisi riippua saman klusterin muiden podien tilasta, jotta vältytään peräkkäisiltä kaatumisilta:
     • tulokset voivat vaihdella sovelluksissa, joissa on hajautettu tila (esimerkiksi välimuistin välimuisti podeissa).
2. Älä käytä elävyysanturia paloille (poikkeuksia ovat tapaukset, joissa ne ovat todella tarpeellisia ja olet täysin tietoinen niiden käytön erityispiirteistä ja seurauksista):
   • Elävyyden anturi voi auttaa palauttamaan ripustetut säiliöt, mutta koska sinulla on täysi hallinta sovelluksestasi, asioiden, kuten ripustettujen prosessien ja lukkiutumien, ei pitäisi ihannetapauksessa tapahtua: paras vaihtoehto on kaataa sovellus tarkoituksella ja palauttaa se edelliseen vakaaseen tilaan;
   • epäonnistunut elävyysanturi saa säiliön käynnistymään uudelleen, mikä saattaa pahentaa lataukseen liittyvien virheiden seurauksia: säiliön uudelleenkäynnistäminen johtaa seisokkiin (vähintään sovelluksen käynnistyksen ajaksi, esimerkiksi 30 sekuntia), mikä aiheuttaa uusia virheitä. , lisäämällä muiden säiliöiden kuormitusta ja lisäämällä niiden epäonnistumisen todennäköisyyttä jne.;
   • elävyyden tarkistukset yhdistettynä ulkoiseen riippuvuuteen ovat pahin mahdollinen yhdistelmä, joka uhkaa peräkkäisiä epäonnistumisia: pieni viive tietokantapuolella johtaa kaikkien konttisi uudelleenkäynnistykseen!
3. Elävyys- ja valmiustarkastusten parametrit täytyy olla erilainen:
   • voit käyttää elävyysanturia, jolla on sama terveystarkastus, mutta korkeampi vastekynnys (failureThreshold), esimerkiksi määritä tila ei ole valmis 3 yrityksen jälkeen ja katso, että elävyysanturi on epäonnistunut 10 yrityksen jälkeen;
4. Älä käytä exec-tarkistuksia, koska ne liittyvät tunnettuihin ongelmiin, jotka johtavat zombie-prosessien ilmestymiseen:
   • yksityiskohdat: katso Datadog-asiantuntijoiden esittely.

Yhteenveto

• Käytä valmiusantureita määrittääksesi, milloin pod on valmis vastaanottamaan liikennettä.
• Käytä elävyysantureita vain silloin, kun niitä todella tarvitaan.
• Valmius-/elävyysantureiden väärä käyttö voi johtaa käytettävyyden heikkenemiseen ja peräkkäisiin häiriöihin.

Lisämateriaalia aiheesta

• Kubernetes-dokumentit: Määritä elävyys- ja valmiusanturit;
• Kubernetesin elävyys- ja valmiusanturit tarkistettu: kuinka vältät ampumasta itseäsi toiseen jalkaan;
• NRE Labs -seisokki kuoleman jälkeen (hän puhuu myös livenessProbesta).

Päivitys nro 1 2019

Tietoja tietokannan siirron init-säiliöistä: Alaviite lisätty.

EJ muistutti minua ATE: yksi elävyystarkastuksiin liittyvistä ongelmista on palojen välisen koordinoinnin puute. Kubernetes on Pod Disruption -budjetit (ATE) rajoittaa sovelluksen samanaikaisten virheiden määrää, mutta tarkistuksissa ei oteta huomioon alustavaa talousarvioesitystä. Ihannetapauksessa voisimme käskeä K8s:lle "Käynnistä yksi pod uudelleen, jos sen testi epäonnistuu, mutta älä käynnistä niitä kaikkia uudelleen, jotta asiat eivät pahenisi."

Bryan sanoi sen täydellisesti: "Käytä elävyyden mittaamista, kun tiedät tarkalleen mitä paras tapa on lopettaa sovellus"(jälleen, älä hurahdu).

Päivitys nro 2 2019

Mitä tulee asiakirjojen lukemiseen ennen käyttöä: loin vastaavan pyynnön (ominaisuuspyyntö) lisätäksesi asiakirjoja elävyyden mittauksista.

PS kääntäjältä

Lue myös blogistamme:

• «Kubernetes: Pod Life";
• «Googlen 7 konttien parasta käytäntöä";
• «7 Konttipohjaisten sovellusten suunnittelun periaatteet'.

Lähde: will.com