Kubernetes parimad praktikad. Õige katkestamine Terminate

Parimad Kubernetes'i praktikad. Väikeste konteinerite loomine
Kubernetes'i parimad tavad. Kubernetes'i korraldamine nimede ruumi abil
Kubernetes'i parimad praktikad. Kubernetes'i elujõu kontrollimine Readiness ja Liveness testide abil
Parimad praktikad Kuberneteses. Ressursside päringute ja piirangute seadistamine

Oluline aspekt jaotatud süsteemide töös on tõrgete käsitlemine. Kubernetes aitab selle kaudu, kasutades kontrollereid, mis jälgivad teie süsteemi olekut ja taaskäivitavad mittefunksioneerivad teenused. Siiski võib Kubernetes sundida teie rakenduste töö lõpetamist, et tagada kogu süsteemi elujõud. Selles seerias uurime, kuidas aidata Kubernetesel oma tööd tõhusamalt teha ja rakenduste seisakuaega vähendada.

Enne konteinerite kasutuselevõttu töötasid enamik rakendusi virtuaalsetel või füüsilistel masinatel. Kui rakendus andis tõrke või hangus, kulus palju aega jooksva ülesande peatamiseks ja programmi uuesti laadimiseks. Halvimal juhul pidi keegi selle probleemi käsitlema käsitsi öösel, kõige ebamugavamal ajal. Kui olulist ülesannet täitsid vaid 1-2 töömachiini, oli selline tõrge täiesti vastuvõetamatu.
Seetõttu hakati käsitsi taaskäivitamise asemel kasutama protsessitasandi jälgimist, et automaatselt taaskäivitada rakendust selle ebaõnnestumise korral. Kui programm ebaõnnestus, haarab jälgimisprotsess väljumiskoodi ja taaskäivitab serveri. Selliste süsteemide, nagu Kubernetes, saabumisega integreeriti see tõrke reageerimise viis lihtsalt infrastruktuuri.

Kubernetes kasutab sündmuste silmuste „jälgimine – erinevuste fikseerimine – tegevuse tegemine”, et veenduda, et ressursid säilitavad töökorras oleku konteineritest sõlmedeni.

See tähendab, et te ei pea enam käsitsi protsesside jälgimist käivitama. Kui resurss ei läbinud tervisekontrolli Health Check, annab Kubernetes sellele lihtsalt automaatselt asenduse. Samuti teeb Kubernetes palju rohkem, kui lihtsalt jälgib teie rakenduste tõrkeid. Ta võib luua rakenduse rohkem koopiaid, et need töötaksid erinevates masinates, uuendada rakendust või samaaegselt käivitada mitu versiooni teie rakendusest.
Seetõttu on palju põhjuseid, miks Kubernetes võib katkestada täiesti terve konteineri töö. Näiteks kui uuendate oma juurutust, peatab Kubernetes aeglaselt vanad podid, samal ajal kui uued käivituvad. Kui lülitate välja sõlm, lõpetab Kubernetes selle sõlme kõikide podide töö. Lõpuks, kui sõlmel saavad ressursid otsa, peatab Kubernetes kõik podid, et neid ressursse vabastada.

Seetõttu on väga oluline, et teie rakendus lõpetaks töö minimaalsete mõjude ja minimaalse taastumisaega lõppkasutajale. See tähendab, et enne väljalülitamist peab see salvestama kõik vajalikud andmed, sulgema kõik võrguühendused, lõpetama ülejäänud tööd ja jõudma teha muid hädavajalikke ülesandeid.

Praktikas tähendab see, et teie rakendus peab suutma töödelda SIGTERM sõnumit – protsesside lõpetamise signaali, mis on vaikimisi signaal Unix-põhistes operatsioonisüsteemides kill utiliidile. Saades seda sõnumit, peab rakendus enda töö lõpetama.

Pärast seda, kui Kubernetes otsustab podi lõpetada, toimub mitmeid sündmusi. Vaatame üle iga sammu, mida Kubernetes teeb konteineri või podi sulgemisel.

Oletame, et soovime lõpetada ühe podi. Sel hetkel lõpetab ta uue liikluse vastuvõtmise – podis töötavad konteinerid ei ole mõjutatud, kuid kogu uus liiklus blokeeritakse.

Vaatame preStop konksu – see on spetsiaalne käsk või HTTP-päring, mis saadetakse podi konteineritele. Kui teie rakendus ei sulgu õigesti SIGTERM saamisel, saate kasutada preStop konksu, et lõpetada töö õigesti.

Enamik programme lõpetab oma töö õigesti SIGTERM signaali saamisel, kuid kui kasutate kolmanda osapoole koodi või mingit süsteemi, mida ei saa täielikult kontrollida, on preStop konks suurepärane viis elegantse sulgemise kutsumiseks ilma rakendust muutmata.

Pärast selle hooki täitmist saadab Kubernetes konteineritele podi sees SIGTERM signaali, mis annab neile teada, et nad peavad varsti sulgema. Kui nad selle signaali saavad, läheb teie kood sulgemisprotsessi. See protsess võib hõlmata pikaajaliste ühenduste, näiteks andmebaasiühenduste või WebSocketi voogude sulgemist, praeguse oleku salvestamist jne.

Isegi kui kasutate preStop hooki, on äärmiselt oluline kontrollida, mis täpselt teie rakendusega juhtub, kui saadate sellele SIGTERM signaali, kuidas see käitub, et sündmused või muud süsteemi töö muutused, mis on põhjustatud podi sulgemisest, teid üllatuseks ei tooks.

Sel hetkel, enne edasiste meetmete võtmist, ootab Kubernetes kindlaksmääratud aja, mida nimetatakse terminationGracePeriodSeconds, või aeg, mis on ette nähtud korrektseks sulgemiseks pärast SIGTERM signaali saamist.

Vaikimisi on see periood 30 sekundit. On oluline märkida, et see kestab samal ajal koos preStop hooki ja SIGTERM signaaliga. Kubernetes ei oota, kuni preStop hook ja SIGTERM on lõpetatud — kui teie rakendus lõpetab töö enne terminationGracePeriodi lõppu, läheb Kubernetes kohe järgmise sammu juurde. Seega veenduge, et selle perioodi väärtus sekundites poleks väiksem kui aeg, mis on vajalik podi korrektseks sulgemiseks, ja kui see ületab 30s, suurendage perioodi vajalikule väärtusele YAML-is. Antud näites on see 60s.

Ja lõpuks, viimane samm — kui konteinerid jätkavad töö tegemist pärast terminationGracePeriodi lõppu, saadavad nad SIGKILL signaali ja eemaldatakse sundkorras. Sel hetkel puhastab Kubernetes ka kõik muud podi objektid.

Kubernetes lõpetab podide töö mitmel põhjusel, seetõttu veenduge, et teie rakendus suletakse igal juhul õigesti, et tagada teenuse stabiilne toimimine.

Parimad Kubernetes`e praktikad. Väliste teenuste kaardistamine

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com