Distribuitaj sistemoj povas esti malfacile administreblaj ĉar ili havas multajn moviĝantajn, ŝanĝantajn elementojn, kiuj ĉiuj bezonas funkcii ĝuste por ke la sistemo funkciu. Se unu el la elementoj malsukcesas, la sistemo devas detekti ĝin, preteriri ĝin kaj ripari ĝin, kaj ĉio ĉi devas esti farita aŭtomate. En ĉi tiu serio de Kubernetes Best Practices, ni lernos kiel agordi testojn de Preteco kaj Vivo por testi la sanon de Kubernetes-areto.
Sankontrolo estas simpla maniero sciigi la sistemon ĉu via aplikaĵo funkcias aŭ ne. Se via aplikaĵo estas malfunkcia, tiam aliaj servoj ne devus aliri ĝin aŭ sendi petojn al ĝi. Anstataŭe, la peto devas esti sendita al alia petskribo de la aplikaĵo, kiu jam funkcias aŭ estos lanĉita poste. Krome, la sistemo devus restarigi la perditan funkciecon de via aplikaĵo.
Defaŭlte, Kubernetes komencos sendi trafikon al pod kiam ĉiuj ujoj en la podoj funkcias, kaj rekomencos ujojn kiam ili kraŝas. Ĉi tiu defaŭlta sistema konduto povas esti sufiĉe bona por komenci, sed vi povas plibonigi la fidindecon de via produkta deplojo uzante kutimajn prudentajn kontrolojn.
Feliĉe, Kubernetes faras ĉi tion sufiĉe facila por fari, do ne ekzistas preteksto por ignori ĉi tiujn kontrolojn. Kubernetes disponigas du specojn de Sankontroloj, kaj estas grave kompreni la diferencojn en kiel ĉiu estas uzata.
La Testo de Preteco estas desegnita por diri al Kubernetes, ke via aplikaĵo pretas trakti trafikon. Antaŭ ol permesi al servo sendi trafikon al pod, Kubernetes devas kontroli, ke la preteca kontrolo estas sukcesa. Se la Testo de Preteco malsukcesos, Kubernetes ĉesos sendi trafikon al la pod ĝis la testo pasos.
La Liveness-testo diras al Kubernetes ĉu via aplikaĵo estas viva aŭ morta. En la unua kazo, Kubernetes lasos ĝin sola, en la dua ĝi forigos la mortintan pod kaj anstataŭigos ĝin per nova.
Ni imagu scenaron kie via aplikaĵo daŭras 1 minuton por varmiĝi kaj lanĉi. Via servo ne komencos funkcii ĝis la aplikaĵo estos plene ŝargita kaj funkcianta, kvankam la laborfluo jam komenciĝis. Vi ankaŭ havos problemojn se vi volas pligrandigi ĉi tiun deplojon al pluraj kopioj, ĉar tiuj kopioj ne devus ricevi trafikon ĝis ili estas plene pretaj. Tamen, defaŭlte, Kubernetes komencos sendi trafikon tuj kiam procezoj en la ujo komenciĝos.
Kiam vi uzas la Teston de Preteco, Kubernetes atendos ĝis la aplikaĵo plene funkcias antaŭ ol permesi al la servo sendi trafikon al la nova kopio.
Ni imagu alian scenaron, en kiu la aplikaĵo pendas dum longa tempo, ĉesigante servi petojn. Dum la procezo daŭre funkcias, defaŭlte Kubernetes supozos, ke ĉio estas en ordo kaj daŭre sendos petojn al la nefunkcianta pod. Sed kiam vi uzas Liveness, Kubernetes detektos, ke la aplikaĵo ne plu servas petojn kaj rekomencos la malvivan podon defaŭlte.
Ni rigardu kiel preteco kaj vivebleco estas provitaj. Estas tri testaj metodoj - HTTP, Command kaj TCP. Vi povas uzi iun ajn el ili por kontroli. La plej ofta maniero testi uzanton estas HTTP-enketo.
Eĉ se via aplikaĵo ne estas HTTP-servilo, vi ankoraŭ povas krei malpezan HTTP-servilon ene de via aplikaĵo por interagi kun la Liveness-testo. Post ĉi tio, Kubernetes komencos pingi la podon, kaj se la HTTP-respondo estas en la intervalo de 200 aŭ 300 ms, ĝi indikos, ke la pod estas sana. Alie, la modulo estos markita kiel "malsana".
Por Komando-testoj, Kubernetes rulas la komandon ene de via ujo. Se la komando revenas kun nula elira kodo, tiam la ujo estos markita kiel sana, alie, ricevinte elirstatusan numeron de 1 ĝis 255, la ujo estos markita kiel "malsana". Ĉi tiu testa metodo estas utila se vi ne povas aŭ ne volas ruli HTTP-servilon, sed kapablas ruli komandon, kiu kontrolos la sanon de via aplikaĵo.
La fina konfirmmekanismo estas la TCP-testo. Kubernetes provos establi TCP-konekton sur la specifita haveno. Se tio povas esti farita, la ujo estas konsiderita sana; se ne, ĝi estas konsiderita nerealigebla. Ĉi tiu metodo povas esti utila se vi uzas scenaron kie testado kun HTTP-peto aŭ komanda ekzekuto ne funkcias tre bone. Ekzemple, la ĉefaj servoj por konfirmo uzante TCP estus gRPC aŭ FTP.
Testoj povas esti agorditaj en pluraj manieroj kun malsamaj parametroj. Vi povas specifi kiom ofte ili devas esti ekzekutitaj, kiaj estas la sojloj de sukceso kaj malsukceso, kaj kiom longe atendi respondojn. Por pliaj informoj, vidu la dokumentaron por la testoj de Preteco kaj Vivo. Tamen, estas unu tre grava punkto en starigo de la Liveness-testo - la komenca fikso de la testa prokrasto initialDelaySeconds. Kiel mi menciis, malsukceso de ĉi tiu testo rezultigos la rekomencon de la modulo. Do vi devas certigi, ke testado ne komenciĝas ĝis la aplikaĵo estas preta, alie ĝi komencos bicikli tra rekomencoj. Mi rekomendas uzi la P99-komenctempon aŭ la averaĝan aplikaĵan lanĉtempon de la bufro. Memoru ĝustigi ĉi tiun valoron ĉar la ektempo de via aplikaĵo plirapidiĝas aŭ malrapidiĝas.
Plej multaj spertuloj konfirmos, ke Sankontroloj estas deviga kontrolo por iu ajn distribuita sistemo, kaj Kubernetes ne estas escepto. Uzado de servaj sankontroloj certigas fidindan, senpagan funkciadon de Kubernetes kaj estas senpene por uzantoj.
Daŭrigota tre baldaŭ...
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com