🥇Kubernetes näpunäited ja nipid: graceful shutdown'i teostamise eripärad NGINX'is ja PHP-FPM'is

Tüüpiline tingimus CI/CD rakendamisel Kubernetesis: rakendus peab suutma enne täielikku seiskamist mitte vastu võtta uusi kliendi päringuid, ja mis kõige tähtsam – edukalt lõpetama juba olemasolevad.

Selle tingimuse täitmine võimaldab saavutada nullist seisakut juurutamise ajal. Siiski, isegi populaarsete kombinatsioonide (nagu NGINX ja PHP-FPM) kasutamisel võib esineda raskusi, mis viivad igas juurutamises vigade suurenemiseni...

Teooria. Kuidas pod elab

Pod'i elutsükli kohta oleme juba avaldanud selle artikli. Arutletud teema kontekstis huvitab meid järgmine: hetkel, kui pod liigub seisu Terminating, lakkavad sellele uued päringud (pod eemaldatakse teenuse lõpp-punktide loendist). Seega, et vältida seiskumist juurutamise ajal, piisab meie poolt rakenduse korrektse sulgemise probleemi lahendamisest.

Samuti tuleb meeles pidada, et grace period vaikimisi on 30 sekundit: pärast seda pod lõpetatakse ja rakendus peab olema suutnud töödelda kõik päringud enne seda aega. Märkus: kuigi iga päring, mis kestab rohkem kui 5–10 sekundit, on juba probleemne ja graceful shutdown ei aita enam…

Kuna paremini aru saada, mis juhtub, kui pod lõpetab oma töö, piisab järgnevate skeemide uurimisest:

A1, B1 — Teabe saamine pod’i seisundi kohta
A2 — SIGTERM’i saatmine
B2 — Pod’i eemaldamine endpoint’idest
B3 — Muudatuste saamine (endpoint’ide nimekiri muutus)
B4 — iptables reeglite värskendamine

Pange tähele: endpoint’i pod’i eemaldamine ja SIGTERM’i saatmine ei toimu järjestikku, vaid paralleelselt. Ja kuna Ingress ei saa koheselt uuendatud endpoint’ide nimekirja, saadetakse pod’ile uusi päringuid klientidelt, mis põhjustab 500 vigu pod’i lõpetamise ajal. (üksikasjalikum materjal selle küsimuse kohta me) tõlkisime). Selle probleemi lahendamiseks tuleb kasutada järgmisi viise:

Saata vastuse päistes Connection: close (kui see puudutab HTTP-rakendust).
Kui hõlpsat muutmist koodis ei ole, siis allpool artiklis on kirjeldatud lahendust, mis võimaldab päringud lõpuni töödelda graceful period’i jooksul.

Teooria. Kuidas NGINX ja PHP-FPM lõpetavad oma protsessid

NGINX

Alustame NGINX-ist, kuna see on enam-vähem arusaadav. Teooriasse süvenedes saame teada, et NGINX-il on üks peaprotsess ja mitu 'töötajat' - need on alamprotsessid, mis töötlevad kliendipäringuid. On olemas mugav võimalus: käsu abil nginx -s võib protsesse lõpetada kas kiire sulgemise või sujuva sulgemise režiimis. Ilmselgelt huvitab meid just viimane valik.

Edasi on kõik lihtne: tuleb lisada preStop-hüüb käsk, mis saadab signaali sujuvaks sulgemiseks. Seda saab teha Deployment'is konteineri plokis:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

Nüüd pod'i sulgemise hetkel näeme NGINX konteineri logides järgmist:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

Ja see tähendaks just seda, mida vajame: NGINX ootab päringute lõpetamist, pärast mida tapab protsessi. Siiski käsitletakse allpool ka levinud probleemi, mille tõttu isegi käsku nginx -s quit protsess lõpetatakse vääralt.

Ja on sel etapil NGINX lõpetatud: vähemalt logide põhjal on näha, et kõik töötab nagu peab.

Kuidas on lood PHP-FPM-iga? Kuidas see teostab graceful shutdown? Uurime lähemalt.

PHP-FPM

PHP-FPM-i puhul on teavet veidi vähem. Kui orienteeruda ametlikule manuaalile PHP-FPM-i kohta, siis seal räägitakse, et aktsepteeritakse järgmisi POSIX-signaale:

SIGINT, SIGTERM — kiire sulgemine;
SIGQUIT — graceful shutdown (just see, mida vajame).

Teised signaalid ei ole antud ülesande jaoks vajalikud, seetõttu jätame nende analüüsi vahele. Protsessi korrektselt lõpetamiseks on vaja kirjutada järgmine preStop-hook:

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

Esmapilgul on see kõik, mis on vajalik graceful shutdowni teostamiseks mõlemas konteineris. Siiski on ülesanne keerulisem, kui tundub. Allpool on käsitletud kahte juhtumit, kus graceful shutdown ei toiminud ja põhjustas projekti lühiajalise kättesaamatuse deploy ajal.

Praktika. Võimalikud probleemid graceful shutdowniga

NGINX

Esiteks on kasulik meeles pidada: lisaks käsu täitmisele nginx -s quit on veel üks etapp, millele tuleks tähelepanu pöörata. Oleme kohanud probleemi, kus NGINX saatis SIGTERM signaali asemel SIGQUIT, mistõttu päringud ei lõpetatud õigesti. Sarnaseid juhtumeid võib leida näiteks siit. Kahjuks ei suudnud me selle käitumise täpset põhjust tuvastada: kahtlustati NGINX versioone, kuid see ei leidnud kinnitust. Sümtomid näitasid, et NGINX konteineri logides esines sõnumeid «open socket #10 left in connection 5», pärast mida pod peatati.

Sellist probleemi võime täheldada näiteks vajadusel Ingress’i vastustes:

Staatuskoodide näitajad juurutamise hetkel.

Sellisel juhul saame just 503 veakoodi ise Ingress’ilt: ta ei saa pöörduda NGINX konteineri poole, kuna see on juba kättesaamatu. Kui vaatame NGINX konteineri logisid, siis neis on järgmine:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

Pärast stopp-signaali muutmist hakkab konteiner õigesti peatuma: seda kinnitab fakt, et 503 viga enam ei esine.

Kui olete sarnase probleemiga kokku puutunud, on mõistlik uurida, millist stop-signaali konteiner kasutab ja kuidas täpselt preStop-hook välja näeb. On täielikult võimalik, et põhjus peitub just selles.

PHP-FPM... ja mitte ainult

PHP-FPM probleem on triviaalne: see ei oota alamprotsesside lõpetamist, lõpetab need, mis põhjustab 502 vigu juurutamise ja teiste operatsioonide ajal. bugs.php.net lehtedel on alates 2005. aastast mitu veateadet (näiteks, siit ja siit), kus see probleem on kirjeldatud. Logides te tõenäoliselt midagi ei näe: PHP-FPM teatab oma protsessi lõpetamisest ilma vigadeta või teiste teadeteta.

On vaja täpsustada, et probleem võib vähemal või rohkemal määral sõltuda rakendusest ise ja ei pruugi näiteks monitooringus ilmnena. Kui te ikkagi selle probleemiga kokku puutute, siis tuleb esimesena mõttesse lihtne lahendus: lisage preStop-hook, mis sisaldab sleep(30). See võimaldab lõpetada kõik varasemad päringud (ja uusi me ei aktsepteeri, kuna pod juba on olekus Terminating), ja pärast 30 sekundi möödumist lõpetab pod endise signaaliga SIGTERM.

Selgub, et lifecycle konteineri vaatab välja järgmiselt:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

Kuid 30-sekundilise määrangu tõttu uni meie tuleb kasutada täiendavat aega juurutamiseks, kuna iga pod lõpetatakse vähemalt 30 sekundi jooksul, mis on probleem. Mida sellega teha saab?

Vaatame, kuidas see rakenduse täitmise poolest toimib. Meie puhul on see PHP-FPM, mis ei jälgi oma child-protsesside täitmise tähtaegu: emaprosess lõpetatakse kohe. Selle käitumise muutmiseks saab kasutada direktiivi process_control_timeout, mis määrab ajapiirangud emaprosessi signaalide ootamiseks tütardelt. Kui väärtus seada 20 sekundiks, katab see enamik konteineris täidetavaid päringuid, ja nende lõppedes lõpetatakse emaprosess.

Nüüd, kui me teame seda, pöördume tagasi viimase mure juurde. Nagu juba mainitud, ei ole Kubernetes monoliitne platvorm: erinevate komponentide vahelise suhtluse jaoks on vajalik teatud aeg. See on eriti oluline, kui vaatame Ingresside ja teiste seotud komponentide tööd, kuna sellise viivituse tõttu on juurutamise hetkel lihtne saada 500-koodiga vigu. Näiteks võib viga tekkida upstream'i päringu saatmise etapis, kuid «ajalaagri» komponentide vahel on üsna lühike — vähem kui sekund.

Seetõttu, koos juba mainitud direktiiviga saab kasutada järgmist struktuuri process_control_timeout võid kasutada järgmist konstruktsiooni lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

Sel juhul kompenseerime viivituse käsuga uni ja ei suurenda juurutamise aega oluliselt: kas vahe 30 sekundi ja ühe sekundi vahel ei ole märgatav? Üksik "põhitoiming" on see, mis tegelikult töötab, process_control_timeout, ja lifecycle kasutatakse ainult kui «tagavarameetmena» viivituse korral.

Üldiselt peab kirjeldatud käitumine ja vastav lahendus ei puuduta ainult PHP-FPM. Sarnane olukord võib teistes programmeerimiskeeltes/raamistikutes ette tulla. Kui ei õnnestu muude meetoditega graceful shutdown'i parandada — näiteks kirjutades koodi ümber, et rakendus töötaks korrektselt lõpetamissignaale töötlejana, — siis saab rakendada kirjeldatud meetodit. Kuigi see ei ole kõige esteetilisem, toimib see.

Praktika. Koormustestimine pod'i töö kontrollimiseks

Koormustestimine on üks meetod, kuidas kontrollida konteineri toimimist, kuna see protseduur läheneb reaalsele lahingule, kui külastajad sisenevad saidile. Ülaltoodud soovituste testimiseks võib kasutada Yandex.Tanki: see katab suurepäraselt kõik meie vajadused. Allpool on toodud soovitused ja soovitused testimise läbiviimiseks koos visuaalse — tänu Grafana graafikutele ja Yandex.Tanki enda näitete järgi — kogemusega.

Kõige olulisem on siin — kontrollida muudatusi samm-sammult. Pärast uue paranduse lisamist käivitage testimine ja vaadake, kas tulemused on võrreldes eelmise käivitusega muutunud. Vastasel juhul on raske tuvastada ebaefektiivseid lahendusi ning pikemas perspektiivis võib see isegi kahjustada (näiteks suurendada juurutamise aega).

Teine nüanss on jälgida konteineri logisid selle sulgemise ajal. Kas seal on teadet graceful shutdown'i kohta? Kas logides on vigu teistele ressurssidele pöördumisel (näiteks naaberkonteinerile PHP-FPM)? Kas rakendusel endal on vigu (nagu eespool mainitud NGINX-i näites)? Loodan, et selle artikli sissejuhatav teave aitab paremini aru saada, mis toimub konteineri sulgemise ajal.

Nii et testimise esimene käivitus toimus ilma lifecycle ja ilma täiendavate juhistega rakenduste serverile (process_control_timeout PHP-FPM-is). Selle testi eesmärk oli tuvastada ligikaudne vigade arv (ja kas need on üldse olemas). Samuti tuleks teada, et iga pod'i keskmine juurutusaeg oli umbes 5-10 sekundit täieliku valmiduse saavutamiseks. Tulemused on järgmised:

Yandex.Tank'i infopaneelil on näha 502 vigade tõus, mis toimus juurutamise ajal ja kestis keskmiselt kuni 5 sekundit. Kahtlustatakse, et katkestati olemasolevad päringud vana pod'i poole, kui see lõpetati. Pärast seda ilmusid 503 vead, mis olid seotud NGINX'i peatatud konteineriga, mis katkestas ka ühendused tõttu backend'i (mille tõttu ei suutnud Ingress sellele juurde pääseda).

Vaadakem, kuidas process_control_timeout PHP-FPM aitab meil oodata child-protsesside lõppu, t. e. selliste vigade parandamine. Uuesti juurutamine, kasutades seda käsku:

Juurutamise ajal 500 vigu enam ei ole! Juurutamine läheb sujuvalt, graceful shutdown töötab.

Kuid tasub meeles pidada Ingress-konteinerite momenti, millest me saame väikese protsendi vigu, mida võime saada ajutise viivituse tõttu. Nende vältimiseks jääb lisada konstruktsioon koos uni ja korduda juurutamist. Siiski, meie konkreetses olukorras ei olnud muudatusi märgata (vigu ei ole jälle).

Kokkuvõte

Protsessi korrektseks lõpetamiseks ootame rakenduselt järgmist käitumist:

Oodata paar sekundit, pärast mida lõpetada uute ühenduste vastuvõtmine.
Oodata kõigi päringute lõpetamist ja sulgeda kõik keepalive-ühendused, mis päringute täitmisega ei tegele.
Lõpetage oma protsess.

Kuid mitte kõik rakendused ei oska sellisel moel töötada. Üks lahendus probleemile Kubernetes'e kontekstis on:

eel-peatamise hook'i lisamine, mis ootab paar sekundit;
Meie taustsüsteemi konfiguratsioonifaili uurimine vastavate parameetrite osas.

NGINX'i näide aitab mõista, et isegi rakendus, mis peaks algselt õigesti lõpetamissignaale töötlema, võib seda mitte teha, seetõttu on kriitiliselt oluline jälgida 500 vigu rakenduse juurutamisel. See võimaldab vaadata probleemi laiemalt ning mitte keskenduda vaid ühele pod'ile või konteinerile, vaid vaadelda kogu infrastruktuuri tervikuna.

Testimise tööriistana võib kasutada Yandex.Tanki koos mis tahes jälgimissüsteemiga (meie juhul võeti testiks andmed Grafanast, kus taust oli Prometheus). Probleemid õigeaegse sulgemisega paistavad hästi silma suurte koormuste korral, mida benchmark võib genereerida, ja jälgimine aitab olukorda üksikasjalikumalt analüüsida katse ajal või pärast seda.

Vastates tagasisidele artikli kohta: tuleb märkida, et probleemid ja nende lahendused on siin kirjeldatud NGINX Ingress'i kontekstis. Teiste juhtumite jaoks on olemas erinevad lahendused, mida võime arutada järgmistes materjalides.