Grava punkto en la funkciado de distribuitaj sistemoj estas misfunkciado. Kubernetes helpas pri tio uzante regilojn, kiuj kontrolas la sanon de via sistemo kaj rekomencas servojn, kiuj ĉesis funkcii. Tamen, Kubernetes povas forte haltigi viajn aplikojn por certigi ĝeneralan sisteman sanon. En ĉi tiu serio, ni rigardos kiel vi povas helpi Kubernetes fari sian laboron pli efike kaj redukti la malfunkcion de la aplikaĵo.
Antaŭ ujoj, plej multaj aplikoj funkciis per virtualaj aŭ fizikaj maŝinoj. Se la aplikaĵo kraŝis aŭ frostiĝis, daŭris longan tempon por nuligi la taskon en progreso kaj reŝargi la programon. En la plej malbona kazo, iu devis solvi ĉi tiun problemon permane nokte, en la plej malkonvenaj horoj. Se nur 1-2 labormaŝinoj plenumus gravan taskon, tia interrompo estis tute neakceptebla.
Tial, anstataŭ manaj rekomencoj, ili komencis uzi proceznivelan monitoradon por aŭtomate rekomenci la aplikaĵon okaze de nenormala fino. Se la programo malsukcesas, la monitora procezo kaptas la elirkodon kaj rekomencas la servilon. Kun la apero de sistemoj kiel Kubernetes, ĉi tiu tipo de respondo al sistemaj misfunkciadoj estis simple integrita en la infrastrukturon.
Kubernetes uzas okazaĵbuklon de observo-diferenco-agado por certigi, ke resursoj restas sanaj dum ili vojaĝas de ujoj al la nodoj mem.
Ĉi tio signifas, ke vi ne plu bezonas mane ruli procezan monitoradon. Se rimedo malsukcesas la Sankontrolon, Kubernetes simple aŭtomate provizos ĝin per anstataŭaĵo. Tamen, Kubernetes faras multe pli ol nur monitori vian aplikon por misfunkciadoj. Ĝi povas krei pli da kopioj de la aplikaĵo por funkcii sur pluraj maŝinoj, ĝisdatigi la aplikaĵon aŭ ruli plurajn versiojn de via aplikaĵo samtempe.
Tial estas multaj kialoj, kial Kubernetes povas ĉesigi tute sanan ujon. Ekzemple, se vi ĝisdatigas vian deplojon, Kubernetes malrapide ĉesos malnovajn podojn dum komenco de novaj. Se vi malŝaltas nodon, Kubernetes ĉesos ruli ĉiujn podojn sur tiu nodo. Fine, se nodo elĉerpigas rimedojn, Kubernetes fermos ĉiujn podojn por liberigi tiujn rimedojn.
Tial, estas kritike, ke via aplikaĵo finiĝas kun minimuma efiko al la finuzanto kaj minimuma reakiro. Ĉi tio signifas, ke antaŭ ol malŝalti, ĝi devas konservi ĉiujn datumojn, kiuj devas esti konservitaj, fermi ĉiujn retajn konektojn, plenumi restantan laboron kaj administri aliajn urĝajn taskojn.
Praktike, tio signifas, ke via aplikaĵo devas povi pritrakti la SIGTERM-mesaĝon, la procezan finsignalon, kiu estas la defaŭlta signalo por la kill-utilo en Uniksaj operaciumoj. Ricevinte ĉi tiun mesaĝon, la aplikaĵo devus fermiĝi.
Post kiam Kubernetes decidas ĉesigi balgon, okazas kelkaj okazaĵoj. Ni rigardu ĉiun paŝon, kiun Kubernetes faras kiam malŝaltas ujon aŭ pod.
Ni diru, ke ni volas ĉesigi unu el la balgoj. Je ĉi tiu punkto, ĝi ĉesos ricevi novan trafikon - ujoj kurantaj en la podo ne estos tuŝitaj, sed ĉio nova trafiko estos blokita.
Ni rigardu la preStop-hokon, kiu estas speciala komando aŭ HTTP-peto, kiu estas sendita al ujoj en pod. Se via aplikaĵo ne malŝaltas ĝuste kiam vi ricevas SIGTERM, vi povas uzi preStop por malŝalti ĝuste.
Plej multaj programoj eliros gracie kiam ili ricevas SIGTERM-signalon, sed se vi uzas triapartan kodon aŭ iun sistemon, kiun vi ne plene regas, la preStop-hoko estas bonega maniero devigi gracian ĉesigon sen ŝanĝi la aplikaĵon.
Post ekzekuto de ĉi tiu hoko, Kubernetes sendos SIGTERM-signalon al la ujoj en la pod, sciigante ilin, ke ili baldaŭ estos malkonektitaj. Ricevinte ĉi tiun signalon, via kodo procedos al la haltiga procezo. Ĉi tiu procezo povas inkluzivi ĉesigi iujn longedaŭrajn konektojn kiel datumbazan konekton aŭ WebSocket-rivereton, konservi la nunan staton kaj similajn.
Eĉ se vi uzas preStop-hokon, estas tre grave kontroli kio precize okazas al via aplikaĵo kiam vi sendas al ĝi SIGTERM-signalon, kaj kiel ĝi kondutas, por ke eventoj aŭ ŝanĝoj en la funkciado de la sistemo kaŭzitaj de pod-halto ne okazu tiel. surprizo por vi.
Je ĉi tiu punkto, Kubernetes atendos specifitan kvanton da tempo, nomita terminationGracePeriodSecond, aŭ la periodon por gracie malŝalti kiam ĝi ricevas SIGTERM-signalon, antaŭ ol preni plian agon.
Defaŭlte ĉi tiu periodo estas 30 sekundoj. Gravas noti, ke ĝi funkcias paralele kun la preStop-hoko kaj la SIGTERM-signalo. Kubernetes ne atendos la finiĝon de la preStop-hoko kaj SIGTERM—se via aplikaĵo eliras antaŭ ol finiĝos la TerminationGracePeriod, Kubernetes tuj transiros al la sekva paŝo. Sekve, kontrolu, ke la valoro de ĉi tiu periodo en sekundoj ne estas malpli ol la tempo bezonata por ĝuste fermi la podon, kaj se ĝi superas 30s, pliigu la periodon al la dezirata valoro en YAML. En la ekzemplo donita, ĝi estas 60-aj jaroj.
Kaj finfine, la lasta paŝo estas se ujoj ankoraŭ funkcias post finiĝoGracePeriod, ili sendos SIGKILL-signalon kaj estos perforte forigitaj. Je ĉi tiu punkto, Kubernetes ankaŭ purigos ĉiujn aliajn podobjektojn.
Kubernetes finas podojn pro multaj kialoj, do certigu, ke via aplikaĵo finiĝas gracie ĉiukaze por certigi stabilan servon.
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