Maaaring mahirap pangasiwaan ang mga distributed system dahil marami silang gumagalaw, nagbabagong elemento na lahat ay kailangang gumana nang maayos para gumana ang system. Kung nabigo ang isa sa mga elemento, dapat itong makita ng system, laktawan ito at ayusin ito, at ang lahat ng ito ay dapat na awtomatikong gawin. Sa seryeng ito ng Kubernetes Best Practices, malalaman natin kung paano mag-set up ng Readiness and Liveness tests para subukan ang kalusugan ng isang Kubernetes cluster.
Ang Health Check ay isang simpleng paraan upang ipaalam sa system kung gumagana ang iyong application instance o hindi. Kung ang iyong application instance ay hindi gumagana, ang ibang mga serbisyo ay hindi dapat ma-access ito o magpadala ng mga kahilingan dito. Sa halip, ang kahilingan ay dapat ipadala sa isa pang instance ng application na tumatakbo na o ilulunsad sa ibang pagkakataon. Bilang karagdagan, dapat ibalik ng system ang nawalang functionality ng iyong application.
Bilang default, magsisimula ang Kubernetes na magpadala ng trapiko sa isang pod kapag tumatakbo na ang lahat ng container sa loob ng pods, at i-reboot ang mga container kapag nag-crash ang mga ito. Ang default na gawi ng system na ito ay maaaring sapat na mabuti sa simula, ngunit maaari mong pagbutihin ang pagiging maaasahan ng iyong pag-deploy ng produkto sa pamamagitan ng paggamit ng mga custom na pagsusuri sa katinuan.
Sa kabutihang palad, ginagawa itong medyo madaling gawin ng Kubernetes, kaya walang dahilan para balewalain ang mga pagsusuring ito. Nagbibigay ang Kubernetes ng dalawang uri ng Health Checks, at mahalagang maunawaan ang mga pagkakaiba sa kung paano ginagamit ang bawat isa.
Ang Readiness test ay idinisenyo upang sabihin sa Kubernetes na ang iyong aplikasyon ay handa nang pangasiwaan ang trapiko. Bago payagan ang isang serbisyo na magpadala ng trapiko sa isang pod, dapat i-verify ng Kubernetes na matagumpay ang pagsusuri sa kahandaan. Kung mabigo ang Readiness test, hihinto ang Kubernetes sa pagpapadala ng trapiko sa pod hanggang sa pumasa ang pagsubok.
Ang Liveness test ay nagsasabi sa Kubernetes kung ang iyong aplikasyon ay buhay o patay. Sa unang kaso, hahayaan ito ng Kubernetes, sa pangalawa ay tatanggalin nito ang patay na pod at papalitan ito ng bago.
Isipin natin ang isang senaryo kung saan ang iyong application ay tumatagal ng 1 minuto upang magpainit at mailunsad. Hindi magsisimulang gumana ang iyong serbisyo hanggang sa ganap na na-load at tumatakbo ang application, bagama't nagsimula na ang daloy ng trabaho. Magkakaroon ka rin ng mga problema kung gusto mong palakihin ang deployment na ito sa maraming kopya, dahil hindi dapat makatanggap ng trapiko ang mga kopyang iyon hangga't hindi sila ganap na handa. Gayunpaman, bilang default, magsisimulang magpadala ang Kubernetes ng trapiko sa sandaling magsimula ang mga proseso sa loob ng container.
Kapag ginagamit ang Readiness test, maghihintay ang Kubernetes hanggang sa ganap na gumana ang application bago payagan ang serbisyo na magpadala ng trapiko sa bagong kopya.
Isipin natin ang isa pang senaryo kung saan ang application ay nakabitin nang mahabang panahon, na huminto sa mga kahilingan sa serbisyo. Habang patuloy na tumatakbo ang proseso, bilang default ay ipapalagay ng Kubernetes na maayos ang lahat at magpapatuloy sa pagpapadala ng mga kahilingan sa hindi gumaganang pod. Ngunit kapag gumagamit ng Liveness, matutukoy ng Kubernetes na hindi na naghahatid ng mga kahilingan ang application at ire-restart ang patay na pod bilang default.
Tingnan natin kung paano nasusubok ang pagiging handa at kakayahang mabuhay. Mayroong tatlong mga paraan ng pagsubok - HTTP, Command at TCP. Maaari mong gamitin ang alinman sa mga ito upang suriin. Ang pinakakaraniwang paraan upang subukan ang isang user ay isang HTTP probe.
Kahit na ang iyong application ay hindi isang HTTP server, maaari ka pa ring lumikha ng isang magaan na HTTP server sa loob ng iyong application upang makipag-ugnayan sa Liveness test. Pagkatapos nito, sisimulan ng Kubernetes ang pag-ping sa pod, at kung ang tugon ng HTTP ay nasa 200 o 300 ms range, ipahiwatig nito na malusog ang pod. Kung hindi, mamarkahan ang module bilang "hindi malusog".
Para sa mga pagsubok sa Command, pinapatakbo ng Kubernetes ang command sa loob ng iyong container. Kung babalik ang command na may zero exit code, mamarkahan ang container bilang malusog, kung hindi, kapag nakatanggap ng exit status number mula 1 hanggang 255, mamarkahan ang container bilang "may sakit". Kapaki-pakinabang ang paraan ng pagsubok na ito kung hindi mo kaya o ayaw mong magpatakbo ng HTTP server, ngunit nakakapagpatakbo ng command na susuri sa kalusugan ng iyong application.
Ang panghuling mekanismo ng pag-verify ay ang TCP test. Susubukan ng Kubernetes na magtatag ng koneksyon sa TCP sa tinukoy na port. Kung magagawa ito, ang lalagyan ay itinuturing na malusog; kung hindi, ito ay itinuturing na hindi mabubuhay. Ang pamamaraang ito ay maaaring maging kapaki-pakinabang kung gumagamit ka ng isang sitwasyon kung saan ang pagsubok sa isang kahilingan sa HTTP o pagpapatupad ng command ay hindi gumagana nang maayos. Halimbawa, ang mga pangunahing serbisyo para sa pag-verify gamit ang TCP ay gRPC o FTP.
Maaaring i-configure ang mga pagsubok sa maraming paraan na may iba't ibang mga parameter. Maaari mong tukuyin kung gaano kadalas dapat isagawa ang mga ito, kung ano ang mga threshold ng tagumpay at pagkabigo, at gaano katagal maghintay para sa mga tugon. Para sa higit pang impormasyon, tingnan ang dokumentasyon para sa mga pagsusulit sa Kahandaan at Pagkabuhay. Gayunpaman, mayroong isang napakahalagang punto sa pagse-set up ng Liveness test - ang paunang setting ng pagkaantala ng pagsubok initialDelaySeconds. Tulad ng nabanggit ko, ang pagkabigo ng pagsubok na ito ay magreresulta sa pag-restart ng module. Kaya kailangan mong tiyakin na ang pagsubok ay hindi magsisimula hanggang sa ang application ay handa nang gamitin, kung hindi, ito ay magsisimulang umikot sa pamamagitan ng mga pag-restart. Inirerekomenda ko ang paggamit ng P99 na oras ng pagsisimula o ang karaniwang oras ng pagsisimula ng aplikasyon mula sa buffer. Tandaang isaayos ang halagang ito habang ang oras ng pagsisimula ng iyong application ay nagiging mas mabilis o mas mabagal.
Kukumpirmahin ng karamihan sa mga eksperto na ang mga Health Check ay isang mandatoryong pagsusuri para sa anumang distributed system, at ang Kubernetes ay walang exception. Tinitiyak ng paggamit ng mga pagsusuri sa kalusugan ng serbisyo ang maaasahan, walang problemang pagpapatakbo ng Kubernetes at walang hirap para sa mga user.
Itutuloy sa lalong madaling panahon...
Ilang ad π
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com