Kubernetes parimad praktikad. Korralik lõpetamine Terminate

Kubernetesi parimad praktikad. Väikeste konteinerite loomine
Kubernetesi parimad praktikad. Kubernetesi korraldamine nimespetsiifiliste ruumide abil
Kubernetesi parimad praktikad. Kubernetesi elujõudluse kontrollimine Readiness ja Liveness testide abil
Kubernetesi parimad praktikad. Ressursside päringute ja piirangute seadistamine

Oluline aspekt hajutatud süsteemide töös on tõrke käsitlemine. Kubernetes aitab sellega, kasutades kontrollereid, mis jälgivad teie süsteemi seisundit ja taaskäivitavad mittetöötavaid teenuseid. Siiski võib Kubernetes sundida teie rakenduste töötamise lõpetamist, et tagada süsteemi üldine elujõud. Selles seerias vaatleme, kuidas aidata Kubernetesel oma tööd tõhusamalt teha ja rakenduste seisakuaega vähendada.

Enne konteinerite kasutuselevõttu töötasid enamik rakendusi virtuaal- või füüsilistel masinatel. Kui rakendus krahhis või hangus, kulus täitmise peatamiseks ja programmi uuesti laadimiseks palju aega. Halvimal juhul pidi keegi selle probleemi käsitlema käsitsi öösel, kõige ebasobivamal ajal. Kui olulist ülesannet täideti vaid 1-2 töömasina poolt, oli tõrge täiesti talumatu.
Seetõttu hakkasime manuaalse taaskäivitamise asemel kasutama protsesside tasandi jälgimist, et automaatselt rakendust uuesti käivitada, kui see ebaõnnestub. Kui programm viga annab, salvestab jälgimisprotsess exit-koodi ja taaskäivitab serveri. Selliste süsteemide nagu Kubernetes tekkimisega on see süsteemide tõrgete reageerimise viis lihtsalt infrastruktuuri integreeritud.

Kubernetes kasutab sündmuste silmust "jälgimine – erinevuste fikseerimine – tegevuse tegemine", et veenduda, et ressursid säilitavad töövõime konteineritest otse sõlmedeni.

See tähendab, et te ei pea enam käsitsi protsesside jälgimist käivitama. Kui ressurss ei läbinud Health Check'i tervisekontrolli, pakub Kubernetes sellele automaatselt asendust. Samal ajal teeb Kubernetes palju rohkem, kui lihtsalt jälgib teie rakenduste tõrkeid. See suudab luua rohkem rakenduse koopiaid töötamiseks mitmel masinal, uuendada rakendust või käivitada samaaegselt mitu versiooni teie rakendusest.
Seetõttu on palju põhjuseid, miks Kubernetes võib täiesti terve konteineri töö katkestada. Näiteks kui värskendate oma juurutust, lõpetab Kubernetes aeglaselt vanade podide töö, samal ajal kui uued käivituvad. Kui keelate sõlme, lõpetab Kubernetes selle sõlme kõikide podide töö. Lõpuks, kui sõlmel jääb ressursse puudu, katkestab Kubernetes kõik podid, et neid ressursse vabastada.

Seega on väga oluline, et teie rakendus katkestaks töö minimaalsete mõjudega lõppkasutajale ja võimalikult lühikese taastumisaajaga. See tähendab, et enne katkestamist peab see salvestama kõik vajalikud andmed, sulgema kõik võrguühendused, lõpetama järelejäänud tööd ja tegema kõik muud hädavajalikud toimingud.

Praktikas tähendab see, et teie rakendus peab suutma töödelda SIGTERM sõnumit - protsessi lõpetamise signaali, mis on UNIX-i perekonna operatsioonisüsteemi kill utiliidi vaike signaal. Saades selle teate, peaks rakendus katkestama.

Kui Kubernetes otsustab pod'i lõpetada, toimub mitmeid sündmusi. Vaatame iga sammu, mida Kubernetes astub konteineri või pod'i sulgemisel.

Oletame, et soovime lõpetada ühe pod'i. Sel hetkel lõpetab see uue liikluse vastuvõtmise – pod'is töötavad konteinerid jäävad puutumatuks, kuid kogu uus liiklus blokeeritakse.

Vaatame preStop hook'i – see on eriline käsk või HTTP-päring, mis saadetakse pod'i konteineritele. Kui teie rakendus ei tsipa korrektset lahkumiskäsku SIGTERM saadud, võite kasutada preStop'i korrektseks lõpetamiseks.

Enamik programme lõpetab oma töö korrektseks, kui nad saavad SIGTERM signaali, kuid kui kasutate kolmanda osapoole koodi või mingit süsteemi, mida te täielikult ei kontrolli, on preStop hook suurepärane võimalus elegantseks väljalülitamiseks ilma rakendust muutmata.

Pärast selle Kubernetes'i hook'i täitmist saadab Kubernetes konteineritele pod'is SIGTERM signaali, mis annab neile teada, et nad varsti välja lülitatakse. Saades selle signaali, läheb teie kood välja lülitamise protsessi. See protsess võib hõlmata pikaajaliste ühenduste, nagu andmebaasiühenduse või WebSocketi voogude, peatamist, praeguse oleku salvestamist jne.

Isegi kui kasutate preStop hook'i, on väga oluline kontrollida, mis teie rakenduses juhtub, kui saadate sellele SIGTERM signaali, ja kuidas see end sel ajal käitub, et sündmused või muudatused süsteemis, mis on põhjustatud pod'i välja lülitamisest, teid üllataksid.

Selles etapis, enne edasiste tegevuste astumist, ootab Kubernetes määratud aja, mida nimetatakse terminationGracePeriodSecond-iks, või SIGTERM signaali saamisel korrektseks väljalülitamiseks ette nähtud ajaks.

Vaikimisi on see periood 30 sekundit. Oluline on märkida, et see kestab samaaegselt preStop hook'i ja SIGTERM signaaliga. Kubernetes ei oota, kuni preStop hook ja SIGTERM on lõpule viidud — kui teie rakendus lõpetab enne TerminationGracePeriod'i lõppu, liigub Kubernetes kohe järgmise sammu juurde. Seetõttu veenduge, et perioodi väärtus sekundites oleks vähemalt sama pikk, kui on vajalik pod'i korrektsel väljalülitamiseks, ja kui see ületab 30 sekundit, suurendage perioodi soovitud väärtuseni YAML-is. Antud näites on see 60 sekundit.

Ja lõpuks, viimane samm — kui konteinerid jätkavad töötamist pärast terminationGracePeriod'i möödumist, saadavad nad SIGKILL signaali ja eemaldatakse sundlikult. Sel hetkel puhastab Kubernetes ka kõik ülejäänud pod'i objektid.

Kubernetes lõpetab podide töö mitmel põhjusel, seega veenduge, et teie rakendus lõpetatakse igal juhul korrektselt, et tagada teenuse stabiilne toimimine.

Parimad praktikud Kuberneteses. Välisteenuste kaardistamine

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme 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 õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com