Verspreide stelsels kan moeilik wees om te bestuur omdat hulle baie bewegende, veranderende elemente het wat almal behoorlik moet werk vir die stelsel om te funksioneer. As een van die elemente misluk, moet die stelsel dit opspoor, dit omseil en regmaak, en dit alles moet outomaties gedoen word. In hierdie Kubernetes Beste Praktyke-reeks sal ons leer hoe om gereedheids- en lewendigheidstoetse op te stel om die gesondheid van 'n Kubernetes-groepering te toets.
Health Check is 'n eenvoudige manier om die stelsel te laat weet of jou toepassingsinstansie loop of nie. As jou toepassingsinstansie af is, behoort ander dienste nie toegang daartoe te verkry of versoeke na dit te stuur nie. In plaas daarvan moet die versoek na 'n ander instansie van die toepassing gestuur word wat reeds loop of later geloods sal word. Daarbenewens moet die stelsel die verlore funksionaliteit van jou toepassing herstel.
By verstek sal Kubernetes begin om verkeer na 'n peul te stuur wanneer alle houers binne die peule loop, en houers herlaai wanneer hulle neerstort. Hierdie standaardstelselgedrag is dalk goed genoeg om mee te begin, maar jy kan die betroubaarheid van jou produkontplooiing verbeter deur pasgemaakte gesondeheidskontroles te gebruik.
Gelukkig maak Kubernetes dit redelik maklik om te doen, so daar is geen verskoning om hierdie tjeks te ignoreer nie. Kubernetes verskaf twee tipes gesondheidsondersoeke, en dit is belangrik om die verskille te verstaan ββin hoe elkeen gebruik word.
Die gereedheidstoets is ontwerp om Kubernetes te vertel dat jou toepassing gereed is om verkeer te hanteer. Voordat 'n diens toegelaat word om verkeer na 'n pod te stuur, moet Kubernetes verifieer dat die gereedheidskontrole suksesvol is. As die gereedheidstoets misluk, sal Kubernetes ophou om verkeer na die peul te stuur totdat die toets slaag.
Die Liveness-toets sΓͺ vir Kubernetes of jou aansoek lewendig of dood is. In die eerste geval sal Kubernetes dit alleen laat, in die tweede sal dit die dooie peul uitvee en dit met 'n nuwe een vervang.
Kom ons stel ons 'n scenario voor waar jou toepassing 1 minuut neem om op te warm en te begin. Jou diens sal nie begin werk voordat die toepassing ten volle gelaai en loop nie, alhoewel die werkvloei reeds begin het. Jy sal ook probleme hΓͺ as jy hierdie ontplooiing wil opskaal na veelvuldige kopieΓ«, want daardie kopieΓ« behoort nie verkeer te ontvang voordat hulle heeltemal gereed is nie. Kubernetes sal egter by verstek verkeer begin stuur sodra prosesse binne die houer begin.
Wanneer die gereedheidstoets gebruik word, sal Kubernetes wag totdat die toepassing ten volle loop voordat die diens toegelaat word om verkeer na die nuwe kopie te stuur.
Kom ons stel ons 'n ander scenario voor waarin die toepassing vir 'n lang tyd hang en diensversoeke stop. Terwyl die proses aanhou loop, sal Kubernetes by verstek aanvaar dat alles in orde is en voortgaan om versoeke na die nie-werkende pod te stuur. Maar wanneer Liveness gebruik word, sal Kubernetes bespeur dat die toepassing nie meer versoeke dien nie en sal die dooie peul by verstek herbegin.
Kom ons kyk hoe gereedheid en lewensvatbaarheid getoets word. Daar is drie toetsmetodes - HTTP, Command en TCP. Jy kan enige van hulle gebruik om na te gaan. Die mees algemene manier om 'n gebruiker te toets, is 'n HTTP-ondersoek.
Selfs as jou toepassing nie 'n HTTP-bediener is nie, kan jy steeds 'n liggewig HTTP-bediener binne jou toepassing skep om met die Liveness-toets te kommunikeer. Hierna sal Kubernetes die peul begin ping, en as die HTTP-reaksie in die 200 of 300 ms-reeks is, sal dit aandui dat die peul gesond is. Andersins sal die module as "ongesond" gemerk word.
Vir opdragtoetse voer Kubernetes die opdrag binne jou houer uit. As die opdrag terugkeer met 'n nul-uitgangskode, sal die houer as gesond gemerk word, anders sal die houer as "siek" gemerk word wanneer 'n uitgangstatusnommer van 1 tot 255 ontvang word. Hierdie toetsmetode is nuttig as jy nie 'n HTTP-bediener kan of wil gebruik nie, maar 'n opdrag kan uitvoer wat die gesondheid van jou toepassing sal kontroleer.
Die finale verifikasiemeganisme is die TCP-toets. Kubernetes sal probeer om 'n TCP-verbinding op die gespesifiseerde poort te vestig. As dit gedoen kan word, word die houer as gesond beskou; indien nie, word dit as onlewensvatbaar beskou. Hierdie metode kan nuttig wees as jy 'n scenario gebruik waar toetsing met 'n HTTP-versoek of opdraguitvoering nie baie goed werk nie. Byvoorbeeld, die hoofdienste vir verifikasie met behulp van TCP sal gRPC of FTP wees.
Toetse kan op verskeie maniere met verskillende parameters gekonfigureer word. Jy kan spesifiseer hoe gereeld dit uitgevoer moet word, wat die sukses- en mislukkingsdrempels is en hoe lank om vir antwoorde te wag. Vir meer inligting, sien die dokumentasie vir die gereedheids- en lewendigheidstoetse. Daar is egter een baie belangrike punt in die opstel van die Liveness-toets - die aanvanklike instelling van die toetsvertraging initialDelaySeconds. Soos ek genoem het, sal die mislukking van hierdie toets daartoe lei dat die module herbegin word. So jy moet seker maak dat toetsing nie begin voordat die toepassing gereed is om te gaan nie, anders sal dit deur herbegins begin fietsry. Ek beveel aan dat u die P99-opstarttyd of die gemiddelde aanvangtyd van die toepassing vanaf die buffer gebruik. Onthou om hierdie waarde aan te pas aangesien jou toepassing se opstarttyd vinniger of stadiger word.
Die meeste kenners sal bevestig dat Gesondheidsondersoeke 'n verpligte kontrole vir enige verspreide stelsel is, en Kubernetes is geen uitsondering nie. Die gebruik van diensgesondheidsondersoeke verseker betroubare, probleemvrye werking van Kubernetes en is moeiteloos vir gebruikers.
Word binnekort vervolg...
Sommige advertensies π
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com