🥇A liveness probe-ok a Kubernetes-ben veszélyesek lehetnek

Megjegyzés fordítás.: A vezető mérnök a Zalando cégtől, Henning Jacobs, többször is észlelte, hogy a Kubernetes felhasználói nehezen értik a liveness (és readiness) probe-ok célját és helyes alkalmazását. Ezért összegyűjtötte gondolatait ebben az összefoglaló jegyzetben, amely idővel a K8s dokumentáció részévé válik.

Az állapotellenőrzések, amelyeket a Kubernetesben liveness probes ként ismernek (azaz, szó szerint ,,életképességi tesztek” – ford. megj.),meglehetősen veszélyesek lehetnek. Javaslom, hogy ha lehetséges, kerülje el őket: kivételt képeznek azok az esetek, amikor valóban szükség van rájuk, és teljesen tisztában van a használatukkal járó specifikumokkal és következményekkel. Ebben a publikációban a liveness és readiness ellenőrzésekről lesz szó, valamint arról, hogy mikor érdemes és mikor nem érdemes őket alkalmazni.

A kollégám, Sandor nemrégiben megosztotta a Twitteren a leggyakoribb hibákat, amelyekkel találkozik, beleértve a readiness/liveness probe-ok használatával kapcsolatosakat is:

A helytelenül beállított livenessProbe súlyosbíthatja a nagy terheléses helyzeteket (lavina-szerű leállás + potenciálisan hosszú indítás a konténerből/javaslatból), és más negatív következményekhez vezethet, mint például a függőségek összeomlása. (lásd még a közelmúltban írt cikkemet az K3s+ACME összekapcsolásában a kérések számának korlátozása érdekében). Még rosszabb, ha a liveness probe a függőség egészségi állapotának ellenőrzésével (health check) körülbelül külső adatbázis által történik: egyetlen adatbázis hiba újraindítja az összes konténert.!

Az általános üzenet 0, hogy ,,ne használj liveness probe-okat,”, ebben az esetben nem sokat segít, ezért nézzük meg, miért is szükségesek a readiness és liveness ellenőrzések.

Megjegyzés: Az alább bemutatott teszt nagy része eredetileg a Zalando fejlesztői belső dokumentációjában szerepelt.

Readiness és Liveness Ellenőrzések

A Kubernetes két fontos mechanizmust biztosít, amelyeket liveness probes és readiness probes-nak hívnak. Ezek időszakosan végrehajtanak bizonyos műveleteket – például HTTP kérdést küldenek, TCP kapcsolatot nyitnak, vagy parancsot futtatnak a konténerben –, hogy megerősítsék, hogy az alkalmazás megfelelően működik.

A Kubernetes a readiness probes-t használja., hogy megértsük, mikor készen áll a konténer a forgalom fogadására. A pod akkor tekinthető működésre késznek, ha minden egyes konténere kész. E mechanizmus egyik alkalmazása az, hogy ellenőrizzük, mely podok szolgálnak háttérként a Kubernetes szolgáltatásokhoz (és különösen az Ingress-hez).

Élőhely-ellenőrzések segítenek a Kubernetesnek megérteni, mikor van itt az ideje a konténer újraindításának. Például egy ilyen ellenőrzés lehetővé teszi a holtpontok megakadályozását, amikor az alkalmazás „megakadt” egy helyen. A konténer újraindítása ilyen állapotban segít az alkalmazást elmozdítani a holtpontból, a hibák ellenére, azonban kaszkád hibákhoz is vezethet (lásd alább).

Ha megpróbálja telepíteni az alkalmazás frissítését, amely nem teljesíti az élőhely/áttérési ellenőrzést, a telepítése megakad. Kész mivel a Kubernetes várni fog a státuszra

támadásra

minden pod-tól. /health Itt van egy példa egy áttérési ellenőrzésre, amely HTTP-n keresztül ellenőrzi az útvonalatintervallum: 10 másodperc, időkorlát: 1 másodperc, sikerküszöb: 1, hiba 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ások esetén (REST stb.) mindig határozza meg az áttérési ellenőrzést, amely ellenőrzi, hogy az alkalmazás (pod) készen áll-e a forgalom fogadására.
Bizonyosodjon meg arról, hogy az áttérési ellenőrzés kiterjed a tényleges webszerver portjának készenlétére:
- adminisztratív szükségletekhez használt portokat, amelyeket «admin» vagy «management» néven hívnak (például 9090), a átterjedési ellenőrzéshez, győződjön meg róla, hogy a végpont csak akkor ad vissza OK-t, ha a fő HTTP-port (mint például 8080) kész a forgalom fogadására*;
  * Tudok legalább egy esetet a Zalando-nál, amikor ez nem történt meg, azaz átterjedési ellenőrzéshez ellenőrizte a «management» portot, de maga a szerver nem indult el a cache betöltése során fellépő problémák miatt.
- egy külön porton történő áttérési ellenőrzés hozzájárulhat ahhoz, hogy a fő port terhelése ne tükröződjön az egészségellenőrzésben (azaz a szerveren a szálak medencéje tele van, azonban az egészségellenőrzés továbbra is azt mutatja, hogy minden rendben van).
Bizonyosodjon meg arról, hogy az áttérési ellenőrzés tartalmazza az adatbázis inicializálását/migrálását.;
- A legegyszerűbb módja ennek elérésére, ha az HTTP-szerverhez csak az inicializálás befejezése után fordulunk (például az adatbázis migrációját a Flyway stb.); azaz ahelyett, hogy megváltoztatná az egészségellenőrzés állapotát, egyszerűen ne indítsa el a webszervert a DB-migráció befejezése előtt*.
  * Az adatbázis migrációkat az init konténerekből is lehet futtatni a pod-on kívül. Továbbra is híve vagyok az önálló (self-contained) alkalmazásoknak, amelyekben az alkalmazás konténere külső koordináció nélkül tudja, hogyan hozza az adatbázist a megfelelő állapotba.
Használja httpGet az alapértelmezett health check endpoint-ok típikus elérhetőségi ellenőrzéséhez (például, /health).
Járj utána az alapértelmezett ellenőrzési paramétereknek (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- az alapértelmezett paraméterek azt jelentik, hogy a pod not-ready körülbelül 30 másodperc múlva (3 sikertelen élhetőségi ellenőrzés után).
Használj külön portot az „admin” vagy „management” funkciókhoz, ha a technológiai stack (például Java/Spring) ezt lehetővé teszi, hogy elválaszd az „egészség” kezelést és a metrikákat a szokásos forgalomtól:
- de ne feledd a 2. pontot sem.
Ha szükséges, a readiness probe-ot használhatod a cache előmelegítésére/öltöztetésére, és 503-as állapotkódot adhatsz vissza, amíg a konténer fel nem melegszik:
- ajánlom, hogy ismerkedj meg az új ellenőrzéssel startupProbe, amely a 1.16-os verzióban jelent meg (erről írtunk oroszul itt — a fordító megjegyzése).

Figyelmeztetések

Ne támaszkodj külső függőségekre (például adattárolók) readiness/liveness tesztek végrehajtásakor - ez láncreakciós leállásokhoz vezethet:
- például vegyünk egy stateful REST szolgáltatást 10 pod-dal, amely egy PostgreSQL adatbázistól függ: amikor az ellenőrzés a működő adatbázis-kapcsolattól függ, mind a 10 pod leállhat, ha hamisítvány késlekedés lép fel a hálózaton/adatbázis oldalán - általában ez rosszabbul végződik, mint ahogy azt el lehet képzelni;
- figyelmeztess, hogy a Spring Data alapértelmezés szerint ellenőrzi az adatbázis kapcsolódást*;
  * Ez a Spring Data Redis alapértelmezett viselkedése (legalábbis amikor utoljára ellenőriztem), ami „katasztrofális” hibához vezetett: amikor a Redis egy rövid időre elérhetetlenné vált, az összes pod „leállt”.
- A „külső” ebben az értelemben más pod-okat is jelenthet ugyanazon alkalmazás keretein belül, vagyis ideálisan az ellenőrzés nem lenne szabad, hogy függjön más pod-ok állapotától ugyanabban a klaszterben, hogy elkerüljük a láncreakciós leállásokat:
  - az eredmények változhatnak a megosztott állapotú alkalmazások esetén (például, in-memory cache-elés pod-okon belül).
Ne használd a liveness probe-ot pod-okhoz (kivéve azokat az eseteket, amikor valóban szükségesek, és teljes mértékben tudod a sajátos jellegüket és következményeiket):
- A liveness probe can help recover "stuck" containers, but since you have full control over your application, issues like "stuck" processes and deadlocks should ideally not occur: the better alternative is to intentionally crash the application and revert it to a previous stable state;
- A failed liveness probe will result in the container being restarted, potentially exacerbating issues related to loading: restarting the container leads to downtime (at least during the application startup, let's say for more than 30 seconds), causing new errors, increasing the load on other containers, and raising the likelihood of their failure, etc.;
- Liveness checks combined with external dependencies are the worst possible combination, threatening cascade failures: a minor delay on the DB side will restart all your containers!
Liveness and readiness check parameters must be different:
- You can use a liveness probe with the same health check but with a higher triggering threshold (failureThreshold), for example, assign a status not-ready after 3 attempts and consider the liveness probe failed after 10 attempts;
Do not use exec checks, as they are associated with known issues that can lead to zombie processes:
- for details, see the presentation by Datadog specialists.

Összefoglaló

Use readiness probes to determine when the pod is ready to accept traffic.
Use liveness probes only when they are truly necessary.
Incorrect use of readiness/liveness probes can lead to reduced availability and cascade failures.

Additional materials on the topic

Kubernetes docs: Configure Liveness and Readiness Probes;
Kubernetes Liveness and Readiness Probes Revisited: How to Avoid Shooting Yourself in the Other Foot;
NRE Labs Outage Post-Mortem (also discusses livenessProbe).

Update #1 from 2019-09-29

About init containers for DB migration: footnote added.

EJ reminded me of PDB: one of the woes of liveness checks is the lack of coordination between pods. In Kubernetes, there are Pod Disruption Budgets (PDB) to limit the number of concurrent failures an application can experience, however, checks do not take PDB into account. Ideally, we could instruct K8s: "Restart one pod if its check fails, but do not restart them all to avoid making it worse."

Bryan articulated it well.: „Használj élő tesztelést, amikor pontosan tudod, hogy a legjobb, amit tehetsz, az a „leállítani” az alkalmazást„(még egyszer, ne ess túlzásba).