Banatutako sistemak kudeatzea zaila izan daiteke, elementu mugikor eta aldakor asko dituztelako, sistemak funtziona dezan behar bezala funtzionatu behar dutenak. Elementuren batek huts egiten badu, sistemak detektatu, saihestu eta konpondu beharko du, eta hori guztia automatikoki egin behar da. Kubernetes Praktika Onen serie honetan, Kubernetes kluster baten osasuna probatzeko Prestakuntza eta Bizigarritasun probak nola konfiguratu ikasiko dugu.
Osasun-egiaztapena sistemari zure aplikazioaren instantzia exekutatzen ari den ala ez jakinarazteko modu erraz bat da. Zure aplikazioaren instantzia hutsik badago, beste zerbitzu batzuek ez lukete bertara sartu edo hari eskaerarik bidali beharko. Horren ordez, eskaera dagoeneko martxan dagoen edo geroago abiaraziko den aplikazioaren beste instantzia batera bidali behar da. Gainera, sistemak zure aplikazioaren galdutako funtzionaltasuna berreskuratu beharko luke.
Lehenespenez, Kubernetes ontzi batera trafikoa bidaltzen hasiko da ontzietako edukiontzi guztiak martxan daudenean, eta edukiontziak berrabiaraziko ditu huts egiten dutenean. Baliteke sistemaren portaera lehenetsi hau hasiera batean nahikoa ona izatea, baina zure produktuaren hedapenaren fidagarritasuna hobe dezakezu zentzuzko egiaztapen pertsonalizatuak erabiliz.
Zorionez, Kubernetes-ek hau nahiko erraza egiten du, beraz, ez dago aitzakiarik egiaztapen hauek alde batera uzteko. Kubernetes-ek bi osasun egiaztapen mota eskaintzen ditu, eta garrantzitsua da bakoitza nola erabiltzen den desberdintasunak ulertzea.
Prest-proba Kubernetesi zure aplikazioa trafikoa kudeatzeko prest dagoela esateko diseinatuta dago. Zerbitzu bati trafikoa pod batera bidaltzeko baimena eman aurretik, Kubernetes-ek egiaztatu behar du prest dagoen egiaztapena arrakastatsua dela. Prestakuntza probak huts egiten badu, Kubernetes-ek trafikoa ontzira bidaltzeari utziko dio proba gainditu arte.
Liveness probak zure aplikazioa bizirik ala hilik dagoen esaten dio Kubernetesi. Lehenengo kasuan, Kubernetes-ek bakarrik utziko du, bigarrenean hildako leka ezabatu eta berri batekin ordezkatuko du.
Imajina dezagun agertoki bat non zure aplikazioa minutu bat berotzeko eta abiarazteko. Zure zerbitzua ez da lanean hasiko aplikazioa guztiz kargatu eta exekutatzen den arte, nahiz eta lan-fluxua dagoeneko hasi den. Arazoak ere izango dituzu inplementazio hau kopia anitzetara handitu nahi baduzu, kopia horiek ez dutelako trafikorik jaso behar guztiz prest egon arte. Hala ere, lehenespenez, Kubernetes trafikoa bidaltzen hasiko da edukiontzi barruko prozesuak hasi bezain laster.
Prestakuntza proba erabiltzean, Kubernetes-ek aplikazioa guztiz abiarazi arte itxarongo du zerbitzuak kopia berrira trafikoa bidaltzeko baimena eman aurretik.
Imajina dezagun aplikazioa denbora luzez zintzilik dagoen beste eszenatoki bat, zerbitzu-eskaerak geldituz. Prozesuak martxan jarraitzen duen heinean, modu lehenetsian Kubernetes-ek dena ondo dagoela suposatuko du eta funtzionatzen ez duen podra eskaerak bidaltzen jarraituko du. Baina Liveness erabiltzean, Kubernetes-ek detektatuko du aplikazioak ez dituela eskaerak betetzen eta lehenespenez berrabiaraziko du hildako poda.
Ikus dezagun nola probatzen diren presttasuna eta bideragarritasuna. Hiru proba metodo daude: HTTP, Command eta TCP. Horietako edozein erabil dezakezu egiaztatzeko. Erabiltzaile bat probatzeko modurik ohikoena HTTP zunda bat da.
Zure aplikazioa HTTP zerbitzaria ez bada ere, hala ere HTTP zerbitzari arin bat sor dezakezu zure aplikazioaren barruan Liveness testarekin elkarreragiteko. Honen ostean, Kubernetes-ek gailuaren ping-a egiten hasiko da, eta HTTP erantzuna 200 edo 300 ms-ko tartean badago, poda osasuntsu dagoela adieraziko du. Bestela, modulua "osasungaitza" gisa markatuko da.
Komando-probetarako, Kubernetes-ek komandoa exekutatzen du zure edukiontzi barruan. Komandoa zero irteera-kode batekin itzultzen bada, edukiontzia osasuntsu gisa markatuko da, bestela, 1etik 255era arteko irteera-egoera zenbakia jasotzean, edukiontzia "gaixo" gisa markatuko da. Proba metodo hau erabilgarria da HTTP zerbitzari bat exekutatu ezin baduzu edo nahi ez baduzu, baina zure aplikazioaren osasuna egiaztatuko duen komando bat exekutatzeko gai bazara.
Azken egiaztapen-mekanismoa TCP proba da. Kubernetes TCP konexio bat ezartzen saiatuko da zehaztutako atakan. Hori egin badaiteke, edukiontzia osasuntsutzat jotzen da; hala ez bada, bideraezina da. Metodo hau erabilgarria izan daiteke HTTP eskaera edo komandoen exekuzio batekin probak oso ondo funtzionatzen ez duen eszenatoki bat erabiltzen ari bazara. Adibidez, TCP erabiliz egiaztatzeko zerbitzu nagusiak gRPC edo FTP izango lirateke.
Probak hainbat modutan konfigura daitezke parametro ezberdinekin. Zenbat aldiz exekutatu behar diren zehaztu dezakezu, zeintzuk diren arrakasta eta porrot atalaseak eta zenbat denbora itxaron erantzunen. Informazio gehiago nahi izanez gero, ikusi Prestasun eta Bizitasun proben dokumentazioa. Hala ere, Liveness proba konfiguratzeko puntu oso garrantzitsu bat dago: hasierako DelaySeconds probaren atzerapenaren hasierako ezarpena. Aipatu dudan bezala, proba honen huts egiteak modulua berrabiaraziko du. Beraz, ziurtatu behar duzu probak ez direla hasten aplikazioa hasteko prest dagoen arte, bestela berrabiarazi bidez bizikletaz hasiko da. Bufferetik P99 abiarazteko denbora edo batez besteko aplikazioa abiarazteko denbora erabiltzea gomendatzen dut. Gogoratu balio hau doitzen duzula aplikazioaren abiarazte-denbora azkarrago edo motelagoa denez.
Aditu gehienek baieztatuko dute Osasun Kontrolak derrigorrezko egiaztapena direla banatutako edozein sistemarentzat, eta Kubernetes ez da salbuespena. Zerbitzuaren osasun-egiaztapenak erabiltzeak Kubernetesen funtzionamendu fidagarria eta arazorik gabekoa bermatzen du eta erabiltzaileentzat ahaleginik gabe.
Oso laster jarraitzeko...
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com