🥇Probe liveness ing Kubernetes bisa mbebayani

Cathetan. nerjemahake.: Lead engineer saka Zalando, Henning Jacobs, wis bola-bali ngeweruhi masalah ing antarane pangguna Kubernetes kanggo mangerteni tujuan liveness (lan kesiapan) probe lan nggunakake bener. Mula, dheweke nglumpukake pikirane ing cathetan sing wiyar iki, sing pungkasane bakal dadi bagean saka dokumentasi K8.

Priksa kesehatan, dikenal ing Kubernetes minangka probe urip (yaiku, kanthi harfiah, "uji kelangsungan hidup" - kira-kira transl.), bisa mbebayani banget. Aku nyaranake ngindhari yen bisa: mung pangecualian nalika pancen perlu lan sampeyan ngerti babagan spesifik lan akibat saka panggunaane. Publikasi iki bakal ngomong babagan liveness lan mriksa kesiapan, lan uga bakal pitutur marang kowe ing kasus apa punika worth lan sampeyan ora kudu nggunakake.

Kolegaku Sandor bubar nuduhake ing Twitter kesalahan sing paling umum sing ditemokake, kalebu sing ana gandhengane karo panggunaan probe kesiapan / liveness:

Dikonfigurasi kanthi salah livenessProbe bisa nambah kahanan sing akeh beban (snowball shutdown + potensial dawa wadhah / wektu wiwitan aplikasi) lan nyebabake akibat negatif liyane kayata ketergantungan mudhun. (deloken sisan artikel anyarku babagan matesi jumlah panjalukan ing kombinasi K3s+ACME). Luwih elek nalika probe liveness digabungake karo pemeriksaan kesehatan, yaiku database eksternal: Gagal DB siji bakal miwiti maneh kabeh kontaner!

Pesen umum "Aja nggunakake probe liveness" ing kasus iki ora mbantu akeh, mula ayo padha ndeleng apa sing dipriksa kesiapan lan liveness.

Cathetan: Umume tes ing ngisor iki asline kalebu ing dokumentasi pangembang internal Zalando.

Siaga lan Liveness mriksa

Kubernetes nyedhiyakake rong mekanisme penting sing diarani probe liveness lan probe kesiapan. Dheweke kanthi periodik nindakake sawetara tumindak-kayata ngirim panjalukan HTTP, mbukak sambungan TCP, utawa nglakokake printah ing wadhah-kanggo konfirmasi manawa aplikasi kasebut bisa digunakake kaya sing dikarepake.

Kubernetes migunakake probe kesiapankanggo mangerteni nalika wadhah siap nampa lalu lintas. Polong dianggep siap digunakake yen kabeh wadhah wis siyap. Salah sawijining panggunaan mekanisme iki yaiku ngontrol polong sing digunakake minangka backend kanggo layanan Kubernetes (lan utamane Ingress).

Liveness probe bantuan Kubernetes ngerti nalika iku wektu kanggo miwiti maneh wadhah. Contone, mriksa kasebut ngidini sampeyan nyegat deadlock nalika aplikasi macet ing sak panggonan. Wiwiti maneh wadhah ing negara iki mbantu njaluk aplikasi saka lemah sanajan ana kesalahan, nanging uga bisa nyebabake gagal cascading (ndeleng ngisor).

Yen sampeyan nyoba masang nganyari aplikasi sing gagal mriksa liveness / kesiapan, peluncuran kasebut bakal mandheg amarga Kubernetes ngenteni status kasebut. Ready saka kabeh polong.

Conto:

Punika conto probe kesiapan mriksa path /health liwat HTTP kanthi setelan gawan (interval: 10 Detik, wektu ne entek: 1 detik, ambang sukses: 1, ambang kegagalan: 3):

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

Rekomendasi

Kanggo microservices karo HTTP endpoint (REST, etc.) tansah nemtokake probe kesiapan, sing mriksa apa aplikasi (pod) siyap nampa lalu lintas.
Priksa manawa probe kesiapan isine kasedhiyan port server web nyata:
- nggunakake port kanggo tujuan administratif, disebut "admin" utawa "manajemen" (contone, 9090), kanggo readinessProbe, priksa manawa titik pungkasan mung ngasilake OK yen port HTTP utami (kaya 8080) siap nampa lalu lintas *;
  * Aku ngerti paling ora siji kasus ing Zalando sing ora kedadeyan, yaiku. readinessProbe Aku mriksa port "manajemen", nanging server dhewe ora bisa digunakake amarga masalah ngemot cache.
- masang probe kesiapan menyang port sing kapisah bisa nyebabake kasunyatan sing kakehan ing port utama ora bakal dibayangke ing pemeriksaan kesehatan (yaiku, blumbang thread ing server kebak, nanging mriksa kesehatan isih nuduhake yen kabeh iku OK. ).
Priksa manawa probe kesiapan mbisakake initialization / migrasi database;
- Cara paling gampang kanggo nggayuh iki yaiku ngubungi server HTTP mung sawise inisialisasi rampung (contone, migrasi database saka Flyway lan sapanunggalane.); sing, tinimbang ngganti status mriksa kesehatan, mung ora miwiti server web nganti migrasi database rampung*.
  * Sampeyan uga bisa mbukak migrasi database saka wadhah init ing njaba pod. Aku isih penggemar aplikasi mandhiri, yaiku, sing wadhah aplikasi ngerti carane nggawa database menyang negara sing dikarepake tanpa koordinasi eksternal.
Gunakake httpGet kanggo mriksa kesiapan liwat titik pungkasan pemeriksaan kesehatan (contone, /health).
Ngerti paramèter mriksa standar (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- opsi gawan tegese pod bakal dadi ora-siap sawise udakara 30 detik (3 gagal mriksa kewarasan).
Gunakake port kapisah kanggo "admin" utawa "manajemen" yen tumpukan teknologi (eg Java/Spring) ngidini, kanggo misahake manajemen kesehatan lan metrik saka lalu lintas biasa:
- nanging aja lali babagan poin 2.
Yen perlu, probe kesiapan bisa digunakake kanggo anget / mbukak cache lan ngasilake kode status 503 nganti wadhah dadi panas:
- Aku uga menehi rekomendasi sing maca mriksa anyar startupProbe, muncul ing versi 1.16 (kita nulis babagan iki ing basa Rusia kene - kira-kira. transl.).

Caveats

Aja ngandelake dependensi eksternal (kayata gudang data) nalika nglakokake tes kesiapan / liveness - iki bisa nyebabake kegagalan runtun:
- Minangka conto, ayo njupuk layanan REST stateful karo 10 pods gumantung ing siji database Postgres: nalika mriksa gumantung ing sambungan apa kanggo DB, kabeh 10 pods bisa gagal yen ana wektu tundha ing sisih jaringan / DB - biasane iku kabeh ends Samsaya Awon saka iku bisa;
- Wigati dimangerteni manawa Spring Data mriksa sambungan database kanthi gawan*;
  * Iki minangka prilaku standar saka Spring Data Redis (paling ora pungkasan aku mriksa), sing nyebabake kegagalan "catastrophic": nalika Redis ora kasedhiya kanggo wektu sing cendhak, kabeh pods "crash".
- "Eksternal" ing pangertèn iki bisa uga ateges pods liyane saka aplikasi sing padha, sing, saenipun mriksa ngirim ora gumantung ing negara pods liyane kluster padha kanggo nyegah kacilakan cascading:
  - asil bisa beda-beda kanggo aplikasi karo negara mbagekke (contone, ing-memori caching ing pods).
Aja nggunakake probe liveness kanggo pods (pangecualian minangka kasus nalika pancen perlu lan sampeyan ngerti babagan spesifik lan akibat saka panggunaane):
- A probe liveness bisa bantuan waras Hung kontaner, nanging wiwit sampeyan duwe kontrol lengkap liwat aplikasi, iku kaya hung pangolahan lan deadlocks saenipun ora kelakon: alternatif sing paling apik kanggo sengaja nabrak aplikasi lan nggawa bali menyang kahanan anteng sadurunge;
- probe liveness gagal bakal nimbulaké wadhah kanggo miwiti maneh, mangkono duweni potensi exacerbating jalaran saka kesalahan-related loading: miwiti maneh wadhah bakal nyebabake downtime (paling ora kanggo wektu wiwitan aplikasi, ngandika 30-aneh detik), nyebabake kesalahan anyar , nambah beban ing wadhah liyane lan nambah kemungkinan gagal, lsp;
- mriksa liveness digabungake karo katergantungan external minangka kombinasi paling awon, ngancam gagal cascading: wektu tundha tipis ing sisih database bakal mimpin kanggo miwiti maneh kabeh kontaner!
Parameter saka liveness lan mriksa kesiapan kudu beda:
- sampeyan bisa nggunakake probe liveness kanthi mriksa kesehatan sing padha, nanging ambang respon sing luwih dhuwur (failureThreshold), contone, nemtokake status ora-siap sawise 3 usaha lan nimbang sing probe liveness wis gagal sawise 10 usaha;
Aja nggunakake pamriksa exec, amarga ana gandhengane karo masalah sing dikenal sing nyebabake proses zombie:
- rincian: ndeleng presentation dening spesialis Datadog.

Ringkesan

Gunakake probe kesiapan kanggo nemtokake yen pod siap nampa lalu lintas.
Gunakake probe liveness mung yen perlu.
Panggunaan probe kesiapan / liveness sing ora bener bisa nyebabake nyuda kasedhiyan lan gagal cascade.

Materi tambahan babagan topik kasebut

Kubernetes docs: Konfigurasi Liveness lan Siaga Probe;
Kubernetes Liveness and Readiness Probes Revisited: Cara Nyegah Njupuk Dhewe ing Kaki Liyane;
NRE Labs Outage Post-Mortem (dheweke uga ngomong babagan livenessProbe).

Nganyari nomer 1 saka 2019-09-29

Babagan wadhah init kanggo migrasi database: Cathetan kaki ditambahake.

EJ ngingetin aku bab PDB: salah siji masalah karo mriksa liveness punika lack of koordinasi antarane pods. Kubernetes wis Anggaran Gangguan Pod (PDB) kanggo matesi jumlah gagal bebarengan aplikasi bisa nemu, Nanging mriksa ora njupuk menyang akun PDB. Saenipun, kita bisa ngandhani K8s kanggo "Wiwiti maneh siji pod yen tes gagal, nanging aja miwiti maneh kabeh supaya ora dadi luwih elek."

Bryan sijine iku sampurna: "Gunakake liveness probing yen sampeyan ngerti persis apa sing paling apik yaiku mateni aplikasi kasebut"(maneh, aja kesusu).

Nganyari nomer 2 saka 2019-09-29

Babagan maca dokumentasi sadurunge digunakake: Aku nggawe panjaluk sing cocog (panjaluk fitur) kanggo nambah dokumentasi babagan probe liveness.

PS saka penerjemah

Waca uga ing blog kita:

Source: www.habr.com

Penyelidikan liveness ing Kubernetes bisa mbebayani