'n Belangrike punt in die werking van verspreide stelsels is fouthantering. Kubernetes help hiermee deur beheerders te gebruik wat die gesondheid van jou stelsel monitor en dienste herbegin wat opgehou werk het. Kubernetes kan egter jou toepassings met geweld stop om algehele stelselgesondheid te verseker. In hierdie reeks sal ons kyk hoe jy Kubernetes kan help om sy werk meer doeltreffend te doen en die stilstand van toepassings te verminder.
Voor houers het die meeste toepassings op virtuele of fisiese masjiene gehardloop. As die toepassing neergestort of gevries het, het dit lank geneem om die taak wat aan die gang is te kanselleer en die program te herlaai. In die ergste geval moes iemand hierdie probleem snags handmatig oplos, op die mees ongeleë ure. As slegs 1-2 werkende masjiene 'n belangrike taak verrig, was so 'n ontwrigting heeltemal onaanvaarbaar.
Daarom, in plaas van handmatige herlaai, het hulle prosesvlakmonitering begin gebruik om die toepassing outomaties te herbegin in die geval van 'n abnormale beëindiging. As die program misluk, vang die moniteringsproses die uitgangkode vas en herlaai die bediener. Met die koms van stelsels soos Kubernetes, is hierdie tipe reaksie op stelselfoute eenvoudig in die infrastruktuur geïntegreer.
Kubernetes gebruik 'n waarneem-verskil-neem-aksie-gebeurtenislus om te verseker dat hulpbronne gesond bly op pad van die houers na die nodusse self.
Dit beteken dat u nie meer prosesmonitering met die hand hoef uit te voer nie. As 'n hulpbron die Gesondheidsondersoek misluk, sal Kubernetes dit eenvoudig outomaties voorsien van 'n plaasvervanger. Kubernetes doen egter veel meer as om net jou aansoek vir mislukkings te monitor. Dit kan meer kopieë van die toepassing skep om op verskeie masjiene te loop, die toepassing op te dateer of verskeie weergawes van u toepassing gelyktydig te laat loop.
Daarom is daar baie redes waarom Kubernetes 'n heeltemal gesonde houer kan beëindig. Byvoorbeeld, as jy jou ontplooiing opgradeer, sal Kubernetes ou peule stadig stop terwyl nuwes begin. As jy 'n nodus afskakel, sal Kubernetes ophou om alle peule op daardie node te laat loop. Ten slotte, as 'n nodus sonder hulpbronne opraak, sal Kubernetes alle peule afskakel om daardie hulpbronne vry te maak.
Daarom is dit van kritieke belang dat u toepassing beëindig word met minimale impak op die eindgebruiker en minimale hersteltyd. Dit beteken dat voordat dit afgesluit word, dit alle data moet stoor wat gestoor moet word, alle netwerkverbindings moet sluit, oorblywende werk moet voltooi en ander dringende take moet bestuur.
In die praktyk beteken dit dat jou toepassing die SIGTERM-boodskap moet kan hanteer, die prosesbeëindigingsein wat die versteksein is vir die doodmaakprogram op Unix-bedryfstelsels. By ontvangs van hierdie boodskap, behoort die toepassing af te sluit.
Sodra Kubernetes besluit om 'n peul te beëindig, vind 'n aantal gebeurtenisse plaas. Kom ons kyk na elke stap wat Kubernetes neem wanneer 'n houer of peul afgesluit word.
Kom ons sê ons wil een van die peule beëindig. Op hierdie stadium sal dit ophou om nuwe verkeer te ontvang - houers wat in die peul loop, sal nie geraak word nie, maar alle nuwe verkeer sal geblokkeer word.
Kom ons kyk na die preStop-haak, wat 'n spesiale opdrag of HTTP-versoek is wat na houers in 'n peul gestuur word. As jou toepassing nie korrek afskakel wanneer SIGTERM ontvang word nie, kan jy preStop gebruik om korrek af te sluit.
Die meeste programme sal grasieus verlaat wanneer hulle 'n SIGTERM-sein ontvang, maar as jy derdeparty-kode of een of ander stelsel gebruik wat jy nie ten volle beheer nie, is die preStop-haak 'n goeie manier om 'n grasieuse afsluiting af te dwing sonder om die toepassing te verander.
Nadat hierdie haak uitgevoer is, sal Kubernetes 'n SIGTERM-sein na die houers in die peul stuur, wat hulle laat weet dat hulle binnekort ontkoppel sal word. By die ontvangs van hierdie sein, sal jou kode voortgaan na die afsluitproses. Hierdie proses kan insluit die stop van enige langlewende verbindings soos 'n databasisverbinding of WebSocket-stroom, stoor van die huidige toestand, en dies meer.
Selfs as jy 'n preStop-haak gebruik, is dit baie belangrik om te kyk wat presies met jou toepassing gebeur wanneer jy 'n SIGTERM-sein aan hom stuur, en hoe dit optree, sodat gebeure of veranderinge in stelselwerking wat veroorsaak word deur 'n pod-afskakeling nie plaasvind nie. 'n verrassing vir jou.
Op hierdie stadium sal Kubernetes wag vir 'n bepaalde hoeveelheid tyd, genaamd terminationGracePeriodSecond, of die tydperk om grasieus af te sluit wanneer dit 'n SIGTERM-sein ontvang, voordat verdere aksie geneem word.
By verstek is hierdie tydperk 30 sekondes. Dit is belangrik om daarop te let dat dit parallel met die preStop-haak en die SIGTERM-sein loop. Kubernetes sal nie wag vir die preStop-haak en SIGTERM om te eindig nie—as jou toepassing uitgaan voordat die TerminationGracePeriod eindig, sal Kubernetes onmiddellik aanbeweeg na die volgende stap. Kontroleer dus dat die waarde van hierdie tydperk in sekondes nie minder is as die tyd wat nodig is om die peul korrek af te skakel nie, en as dit 30s oorskry, verhoog die tydperk na die verlangde waarde in YAML. In die voorbeeld wat gegee word, is dit 60's.
En laastens, die laaste stap is as houers steeds loop na beëindigingGracePeriod, sal hulle 'n SIGKILL-sein stuur en met geweld uitgevee word. Op hierdie stadium sal Kubernetes ook alle ander peulvoorwerpe skoonmaak.
Kubernetes beëindig peule om baie redes, so maak seker dat jou toepassing in elk geval grasieus beëindig word om 'n stabiele diens te verseker.
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