🥇Panyilidikan liveness di Kubernetes tiasa bahaya

Catetan. narjamahkeun.: Insinyur kalungguhan ti Zalando, Henning Jacobs, geus sababaraha kali noticed masalah diantara pamaké Kubernetes dina pamahaman tujuan liveness (jeung kesiapan) panyilidikan jeung pamakéan bener maranéhanana. Ku alatan éta, anjeunna ngumpulkeun pikiran-Na dina catetan capacious ieu, nu antukna bakal jadi bagian tina dokuméntasi K8s.

Cék kaséhatan, dipikawanoh dina Kubernetes salaku usik liveness (nyaéta, sacara harfiah, "tés viability" - kira-kira transl.), tiasa rada bahaya. Abdi nyarankeun ngahindarkeun aranjeunna upami mungkin: hiji-hijina pangecualian nyaéta nalika aranjeunna leres-leres diperyogikeun sareng anjeun sadar pinuh ku spésifik sareng akibat tina panggunaanana. Publikasi ieu bakal ngobrol ngeunaan liveness jeung kesiapan cék, sarta ogé bakal ngabejaan Anjeun dina naon kasus waragad sareng anjeun henteu kedah nganggo aranjeunna.

Babaturan kuring Sandor nembé ngabagi dina Twitter kasalahan anu paling umum anu anjeunna tepang, kalebet anu aya hubunganana sareng panggunaan panyilidikan kesiapan / liveness:

salah ngonpigurasi livenessProbe tiasa nganyenyerikeun kaayaan beban tinggi (snowball shutdown + wadahna anu berpotensi panjang / waktos ngamimitian aplikasi) sareng ngakibatkeun konsékuansi négatif sanés sapertos gumantungna turun. (tingali ogé artikel panganyarna kuring ngeunaan ngawatesan jumlah pamundut dina kombinasi K3s + ACME). Éta langkung parah nalika usik liveness digabungkeun sareng pamariksaan kaséhatan, anu mangrupikeun pangkalan data éksternal: gagalna DB tunggal bakal balikan deui sadayana wadahna anjeun!

Talatah umum "Entong nganggo usik liveness" dina hal ieu teu mantuan loba, jadi hayu urang nempo naon nu cék kesiapan jeung liveness.

Catetan: Kaseueuran tés di handap asalna kalebet dina dokuméntasi pamekar internal Zalando.

Kesiapan jeung Liveness cék

Kubernetes nyadiakeun dua mékanisme penting disebut usik liveness jeung usik kesiapan. Aranjeunna périodik ngalakukeun sababaraha tindakan-sapertos ngirim pamundut HTTP, muka sambungan TCP, atanapi ngalaksanakeun paréntah dina wadahna-pikeun ngonfirmasi yén aplikasina jalan sakumaha anu diharapkeun.

Kubernetes ngagunakeun usik kesiapanngartos lamun wadahna geus siap pikeun nampa lalulintas. Polong dianggap siap dianggo upami sadaya wadahna parantos siap. Hiji pamakéan mékanisme ieu pikeun ngadalikeun pods nu dipaké salaku backends pikeun layanan Kubernetes (sarta utamana Ingress).

usik liveness mantuan Kubernetes ngartos iraha waktuna pikeun balikan deui wadahna. Salaku conto, cek sapertos kitu ngamungkinkeun anjeun ngahalangan jalan buntu nalika aplikasi macét dina hiji tempat. Balikan deui wadahna dina kaayaan ieu ngabantosan aplikasi tina taneuh sanaos aya kasalahan, tapi éta ogé tiasa nyababkeun kagagalan cascading (tingali di handap).

Upami anjeun nyobian nyebarkeun apdet aplikasi anu gagal dina cek liveness / kesiapan, peluncuranna bakal macet nalika Kubernetes ngantosan statusna. Ready ti sakabéh pods.

conto

Ieu conto usik kesiapan mariksa jalur /health via HTTP kalayan setélan standar (interval: 10 Detik, séép waktos: 1 detik, bangbarung kasuksésan: 1, bangbarung gagalna: 3):

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

saran

Pikeun microservices kalawan HTTP endpoint (REST, jsb) salawasna nangtukeun hiji usik kesiapan, nu mariksa naha aplikasi (pod) geus siap pikeun nampa lalulintas.
Pastikeun usik kesiapan ngawengku kasadiaan port web server sabenerna:
- ngagunakeun palabuhan pikeun kaperluan administrasi, disebut "admin" atawa "manajemén" (contona, 9090), pikeun readinessProbe, Pastikeun yén titik tungtung ngan balik OK lamun port HTTP primér (kawas 8080) geus siap nampa lalulintas *;
  * Kuring sadar sahanteuna hiji kasus di Zalando dimana ieu teu lumangsung, i.e. readinessProbe Kuring pariksa port "manajemén", tapi server sorangan teu ngamimitian digawé alatan masalah loading cache nu.
- ngalampirkeun usik kesiapan ka port misah bisa ngakibatkeun kanyataan yén overload dina port utama moal reflected dina dipariksa kaséhatan (nyaéta, thread pool on server pinuh, tapi cek kaséhatan masih nembongkeun yen sagalana geus OK. ).
Pastikeun éta usik kesiapan ngamungkinkeun database initialization / migrasi;
- Cara panggampangna pikeun ngahontal ieu nyaéta ngahubungan server HTTP ngan sanggeus initialization réngsé (contona, migrasi database ti Jalan layangan teras salajengna.); nyaeta, tinimbang ngarobah status dipariksa kaséhatan, ngan ulah ngamimitian web server dugi migrasi database geus réngsé *.
  * Anjeun ogé tiasa ngajalankeun migrasi database tina wadah init di luar pod. Abdi masih kipas tina aplikasi mandiri, nyaéta, anu wadahna aplikasi terang kumaha carana mawa database kana kaayaan anu dipikahoyong tanpa koordinasi éksternal.
pamakean httpGet pikeun pamariksaan kasiapan ngaliwatan titik tungtung pamariksaan kaséhatan (contona, /health).
Ngartos parameter dipariksa standar (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- pilihan standar hartina pod bakal jadi teu-siap saatos ngeunaan 30 detik (3 gagal cék sanity).
Anggo port anu misah pikeun "admin" atanapi "manajemén" upami tumpukan téknologi (misalna Java/Spring) ngamungkinkeun, pikeun misahkeun manajemén kaséhatan sareng métrik tina lalu lintas biasa:
- tapi ulah poho ngeunaan titik 2.
Upami diperlukeun, usik kesiapan bisa dipaké pikeun haneut nepi / muka cache sarta balik kode status 503 dugi wadahna warms up:
- Kuring ogé nyarankeun yén anjeun baca cek anyar startupProbe, mucunghul dina versi 1.16 (Kami nyerat ngeunaan éta dina basa Rusia di dieu - kira-kira. tarjamah.).

Cautions

Ulah ngandelkeun kagumantungan éksternal (sapertos gudang data) nalika ngajalankeun tés kesiapan/liveness - ieu tiasa ngakibatkeun gagalna cascading:
- Salaku conto, hayu urang nyandak layanan REST stateful sareng 10 pods gumantung kana hiji database Postgres: nalika cek gumantung kana sambungan anu tiasa dianggo ka DB, sadaya 10 pods tiasa gagal upami aya reureuh dina jaringan / sisi DB - biasana éta kabéh ends leuwih goreng ti eta bisa;
- Punten dicatet yén Spring Data mariksa sambungan pangkalan data sacara standar*;
  * Ieu mangrupikeun paripolah standar tina Spring Data Redis (sahenteuna éta terakhir waktos kuring dipariksa), anu nyababkeun kagagalan "catastrophic": nalika Redis sakedap henteu sayogi, sadaya pods "nabrak".
- "Éksternal" dina hal ieu ogé tiasa hartosna pods sanés tina aplikasi anu sami, nyaéta, saencana cek henteu kedah gumantung kana kaayaan pods séjén tina klaster anu sami pikeun nyegah kacilakaan cascading:
  - hasilna bisa rupa-rupa pikeun aplikasi kalawan kaayaan disebarkeun (contona, cache dina-memori dina pods).
Ulah make usik liveness pikeun pods (pangecualian mangrupikeun kasus nalika aranjeunna leres-leres diperyogikeun sareng anjeun sadar kana spésifik sareng akibat tina panggunaanana):
- A usik liveness bisa mantuan cageur wadahna ngagantung, Tapi saprak anjeun boga kadali pinuh kana aplikasi Anjeun, hal kawas prosés ngagantung na deadlocks kedah ideally teu lumangsung: alternatif pangalusna nyaéta ngahaja ngadat aplikasi tur mawa deui ka kaayaan ajeg saméméhna;
- panyilidikan liveness gagal bakal ngabalukarkeun wadahna balikan deui, kukituna berpotensi exacerbating épék kasalahan nu patali boot: restarting wadahna bakal ngakibatkeun downtime (sahenteuna pikeun lilana ngamimitian aplikasi, sebutkeun 30+ detik), ngabalukarkeun kasalahan anyar, ningkatkeun beban dina wadah anu sanés sareng ningkatkeun kamungkinan gagalna, jsb.;
- cék liveness digabungkeun jeung hiji kagumantungan éksternal mangrupakeun kombinasi awon mungkin, ngancam gagal cascading: reureuh slight di sisi database bakal ngakibatkeun balikan deui sadaya wadahna anjeun!
Parameter tina liveness jeung cék kesiapan kudu béda:
- Anjeun tiasa nganggo usik liveness sareng pamariksaan kaséhatan anu sami, tapi ambang réspon anu langkung luhur (failureThreshold), contona, napelkeun status teu-siap saatos 3 usaha sarta mertimbangkeun yén usik liveness geus gagal sanggeus 10 usaha ;
Ulah make cék exec, sabab aya hubunganana sareng masalah anu dipikanyaho anu nyababkeun penampilan prosés zombie:
- rinci: tingali presentasi ku spesialis Datadog.

singgetan

Anggo panyilidikan kesiapan pikeun nangtukeun iraha pod siap nampi lalu lintas.
Anggo panyilidikan liveness ngan nalika aranjeunna leres-leres diperyogikeun.
Pamakéan usik kesiapan / liveness anu teu leres tiasa nyababkeun kasadiaan sareng kagagalan cascading.

Bahan tambahan dina topik

Kubernetes docs: Konpigurasikeun Liveness jeung Siaga Siaga;
Kubernetes Liveness and Readyness Probes Revisited: Kumaha Ngahindarkeun némbak Diri anjeun dina Kaki Lain;
NRE Labs Outage Post-Mortem (anjeunna ogé ngobrol ngeunaan livenessProbe).

Update No.. 1 ti 2019-09-29

Ngeunaan wadah init pikeun migrasi database: Footnote ditambahkeun.

EJ ngingetkeun kuring ngeunaan PDB: salah sahiji masalah sareng cék liveness nyaéta kurangna koordinasi antara pods. Kubernetes boga Anggaran Gangguan Pod (PDB) pikeun ngawatesan jumlah gagal sakaligus aplikasi bisa ngalaman, tapi cék teu tumut kana akun PDB. Ideally, urang bisa ngabejaan K8s ka "Balikan deui hiji pod lamun test na gagal, tapi ulah balikan deui kabeh ulah nyieun hal goréng."

Bryan nempatkeun éta sampurna: "Paké liveness probing mun anjeun nyaho persis naon Hal anu pangsaéna nyaéta maéhan aplikasina"(Sakali deui, ulah kabawa kabawa).

Update No.. 2 ti 2019-09-29

Ngeunaan maca dokuméntasi sateuacan dianggo: Kuring nyiptakeun pamundut anu saluyu (pamundut fitur) pikeun nambahkeun dokuméntasi ngeunaan usik liveness.

PS ti penerjemah

Baca ogé dina blog urang:

sumber: www.habr.com

Panyilidikan liveness di Kubernetes tiasa bahaya