🥇Veszélyesek lehetnek a Kubernetesben végzett élőképesség-szondák

Jegyzet. ford.: A zalandói vezető mérnök, Henning Jacobs többször is problémákat észlelt a Kubernetes felhasználók körében az élőképesség (és készenléti) szondák céljának és helyes használatának megértésében. Ezért gondolatait ebben a tágas jegyzetben gyűjtötte össze, amely végül a K8s dokumentációjának részévé válik.

Egészségügyi ellenőrzések, Kubernetes néven ismert elevenség szondák (azaz szó szerint „életképességi tesztek” – kb. fordítás), elég veszélyes lehet. Azt javaslom, hogy lehetőség szerint kerülje el őket: az egyetlen kivétel az, amikor valóban szükség van rájuk, és Ön teljesen tisztában van használatuk sajátosságaival és következményeivel. Ez a kiadvány az életerő- és készenléti ellenőrzésekről lesz szó, és azt is, hogy milyen esetekben a és nem szabad használni őket.

Sándor kollégám a közelmúltban megosztotta a Twitteren a leggyakoribb hibákat, amelyekkel találkozik, beleértve azokat is, amelyek a készenléti/életképességi szondák használatával kapcsolatosak:

Helytelenül konfigurálva livenessProbe súlyosbíthatja a nagy terhelésű helyzeteket (hógolyó leállás + potenciálisan hosszú konténer/alkalmazás indítási idő), és egyéb negatív következményekhez vezethet, például a függőség csökkenéséhez (Lásd még legutóbbi cikkem a kérelmek számának korlátozásáról a K3s+ACME kombinációban). Még rosszabb, ha az élőképesség szondát egy állapotfelméréssel kombinálják, ami egy külső adatbázis: egyetlen DB hiba újraindítja az összes tárolót!

Általános üzenet "Ne használj élénkítő szondákat" ebben az esetben nem sokat segít, szóval nézzük meg, mire valók a készenléti és életképességi ellenőrzések.

Megjegyzés: Az alábbi tesztek többsége eredetileg a Zalando belső fejlesztői dokumentációjában szerepelt.

Készenléti és élességi ellenőrzések

A Kubernetes két fontos mechanizmust biztosít, ún élénkítő szondák és készenléti szondák. Időnként végrehajtanak bizonyos műveleteket – például HTTP-kérést küldenek, TCP-kapcsolatot nyitnak meg, vagy parancsot hajtanak végre a tárolóban – annak ellenőrzésére, hogy az alkalmazás megfelelően működik-e.

Kubernetes használ készenléti szondákhogy megértse, mikor áll készen a konténer a forgalom fogadására. A hüvely akkor tekinthető használatra késznek, ha minden tartálya készen áll. Ennek a mechanizmusnak az egyik felhasználási módja annak szabályozása, hogy mely podok legyenek a Kubernetes-szolgáltatások (és különösen az Ingress) háttérprogramjai.

Életesség szondák segít a Kubernetesnek megérteni, mikor kell újraindítani a tárolót. Például egy ilyen ellenőrzés lehetővé teszi, hogy elkapja a holtpontot, amikor egy alkalmazás elakad egy helyen. A tároló újraindítása ebben az állapotban elősegíti az alkalmazás elindítását a hibák ellenére, de lépcsőzetes hibákhoz is vezethet (lásd alább).

Ha olyan alkalmazásfrissítést próbál telepíteni, amely nem felel meg az életerő-/készenlét-ellenőrzéseknek, a közzététel leáll, mivel a Kubernetes az állapotra vár. Ready minden hüvelyből.

Példa

Íme egy példa a készenléti szondára, amely egy útvonalat ellenőrzi /health HTTP-n keresztül alapértelmezett beállításokkal (intervallum: 10 másodperc, timeout: 1 másodperc, sikerküszöb: 1, meghibásodási küszöb: 3):

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

Ajánlások

HTTP-végponttal rendelkező mikroszolgáltatásokhoz (REST stb.) mindig határozzon meg egy készenléti szondát, amely ellenőrzi, hogy az alkalmazás (pod) készen áll-e a forgalom fogadására.
Ellenőrizze a készenléti szondát lefedi a tényleges webszerver port elérhetőségét:
- portok használata adminisztratív célokra, úgynevezett "admin" vagy "management" (például 9090), readinessProbe, győződjön meg arról, hogy a végpont csak akkor ad vissza OK-t, ha az elsődleges HTTP-port (például a 8080) készen áll a forgalom fogadására*;
  *Legalább egy olyan esetről tudok Zalandóban, amikor ez nem történt meg, pl. readinessProbe Ellenőriztem a „management” portot, de maga a szerver nem indult el a gyorsítótár betöltésének problémái miatt.
- ha egy készenléti szondát külön porthoz csatlakoztatunk, az azt eredményezheti, hogy a fő port túlterhelése nem fog megjelenni az állapotellenőrzésben (vagyis a szálkészlet megtelt a szerveren, de az állapotellenőrzés továbbra is azt mutatja, hogy minden rendben van ).
Győződjön meg arról, hogy Readiness Probe lehetővé teszi az adatbázis inicializálását/áttelepítését;
- Ennek legegyszerűbb módja, ha csak az inicializálás befejezése után lép kapcsolatba a HTTP szerverrel (például egy adatbázis áttelepítése Flyway stb.); vagyis az állapotellenőrzési állapot megváltoztatása helyett egyszerűen ne indítsa el a webszervert, amíg az adatbázis-áttelepítés be nem fejeződik*.
  * A pod-on kívüli init-tárolókból is futtathat adatbázis-migrációkat. Továbbra is rajongok az önálló alkalmazásokért, vagyis olyanokért, amelyekben az alkalmazáskonténer külső koordináció nélkül tudja a kívánt állapotba hozni az adatbázist.
használat httpGet tipikus állapotellenőrzési végpontokon keresztül végzett készenléti ellenőrzésekhez (például /health).
Ismerje meg az alapértelmezett ellenőrzési paramétereket (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- az alapértelmezett beállítások azt jelentik, hogy a pod lesz nem áll készen körülbelül 30 másodperc múlva (3 sikertelen józansági ellenőrzés).
Ha a technológiai verem (pl. Java/Spring) lehetővé teszi, használjon külön portot az "admin" vagy a "management" számára, hogy elkülönítse az állapot- és mérőszámkezelést a normál forgalomtól:
- de ne feledkezz meg a 2. pontról.
Ha szükséges, a készenléti szonda felhasználható a gyorsítótár felmelegítésére/betöltésére, és 503-as állapotkód visszaküldésére, amíg a tároló fel nem melegszik:
- Azt is javaslom, hogy olvassa el az új csekket startupProbe, az 1.16-os verzióban jelent meg (Oroszul írtunk róla itt - kb. fordítás.).

Vigyázat

Ne hagyatkozzon külső függőségekre (például adattárházak) készenléti/életképességi tesztek futtatásakor – ez lépcsőzetes hibákhoz vezethet:
- Példaként vegyünk egy állapottartó REST szolgáltatást 10 poddal, egy Postgres adatbázistól függően: amikor az ellenőrzés a DB működő kapcsolatától függ, előfordulhat, hogy mind a 10 pod meghiúsul, ha késik a hálózat/DB oldalon – általában ez minden rosszabbul végződik, mint lehetne;
- Felhívjuk figyelmét, hogy a Spring Data alapértelmezés szerint ellenőrzi az adatbázis-kapcsolatot*;
  * Ez a Spring Data Redis alapértelmezett viselkedése (legalábbis utoljára ellenőriztem), ami „katasztrofális” meghibásodáshoz vezetett: amikor a Redis rövid ideig nem volt elérhető, az összes pod „összeomlott”.
- A „külső” ebben az értelemben jelentheti ugyanannak az alkalmazásnak a többi podját is, vagyis ideális esetben az ellenőrzés nem függhet ugyanazon klaszter többi podjának állapotától, hogy elkerülje a lépcsőzetes összeomlásokat:
  - az eredmények eltérőek lehetnek az elosztott állapotú alkalmazásoknál (például a memórián belüli gyorsítótárazás a podokban).
Ne használjon élénkítő szondát hüvelyekhez (kivételek azok az esetek, amikor valóban szükség van rájuk, és Ön teljesen tisztában van használatuk sajátosságaival és következményeivel):
- Az élénkítő szonda segíthet a leakasztott tárolók visszaállításában, de mivel Ön teljes mértékben uralja az alkalmazást, ideális esetben nem fordulhat elő olyan dolgok, mint a lefagyott folyamatok és a holtpontok: a legjobb alternatíva az alkalmazás szándékos összeomlása és visszaállítása a korábbi állandó állapotba;
- a meghibásodott élőképesség-próba a tároló újraindítását eredményezi, ami potenciálisan súlyosbíthatja a betöltéssel kapcsolatos hibák következményeit: a tároló újraindítása leállást eredményez (legalább az alkalmazás indítási idejére, mondjuk 30 másodpercig), ami új hibákat okoz. , növeli a többi konténer terhelését és növeli azok meghibásodásának valószínűségét stb.;
- A külső függőséggel kombinált élőképesség-ellenőrzés a lehető legrosszabb kombináció, amely lépcsőzetes meghibásodásokkal fenyeget: egy kis késés az adatbázis oldalon az összes konténer újraindításához vezet!
Életképesség- és készenléti ellenőrzések paraméterei másnak kell lennie:
- használhat egy élénkítő szondát ugyanazzal az állapotfelméréssel, de magasabb válaszküszöbértékkel (failureThreshold), például hozzárendelheti az állapotot nem áll készen 3 próbálkozás után, és úgy kell tekinteni, hogy az élénkítő szonda 10 kísérlet után meghiúsult;
Ne használjon végrehajtási ellenőrzéseket, mivel ismert problémákhoz kapcsolódnak, amelyek zombi folyamatok megjelenéséhez vezetnek:
- részletek: lásd a Datadog szakembereinek előadása.

Összegzés

Használjon készenléti szondákat annak meghatározására, hogy a pod készen áll a forgalom fogadására.
Csak akkor használja az élénkítő szondákat, amikor valóban szükség van rájuk.
A készenléti/élettartam-szondák nem megfelelő használata csökkent rendelkezésre álláshoz és lépcsőzetes meghibásodásokhoz vezethet.

További anyagok a témában

Kubernetes dokumentumok: Élesség- és készenléti szondák konfigurálása;
A Kubernetes Élet- és készenléti szondák újralátogatása: Hogyan kerülje el, hogy a másik lábába lője magát;
NRE Labs leállás után (a livenessProbe-ról is beszél).

1. számú frissítés 2019-09-29-től

Az adatbázis-áttelepítés init-tárolóiról: Lábjegyzet hozzáadva.

EJ jutott eszembe az EKT-vel kapcsolatban: az élőképesség ellenőrzésével kapcsolatos egyik probléma a hüvelyek közötti koordináció hiánya. Kubernetes rendelkezik Pod Disruption költségvetések (EKT) az alkalmazások által tapasztalható egyidejű hibák számának korlátozása, de az ellenőrzések nem veszik figyelembe az EKT-t. Ideális esetben azt mondhatjuk a K8-nak, hogy "indítsa újra az egyik podat, ha a tesztje sikertelen, de ne indítsa újra mindegyiket, hogy ne rontsa a helyzetet."

Bryan tökéletesen megfogalmazta: „Ha pontosan tudod, mit használj az élességvizsgálatot a legjobb dolog az alkalmazás leállítása"(megint, ne ragadj el magadtól).

2. számú frissítés 2019-09-29-től

Ami a dokumentáció használat előtti elolvasását illeti: létrehoztam a megfelelő kérést (funkciókérés).

PS a fordítótól

Olvassa el blogunkon is:

Forrás: will.com

A kubernetesi élőképesség-szondák veszélyesek lehetnek