Kubernetesi nipid ja trikid: graceful shutdown'i teostamine NGINX-is ja PHP-FPM-is

Standard requirement when implementing CI/CD in Kubernetes: the application must be able to stop accepting new client requests before full shutdown, and, importantly, successfully complete any existing requests.

Compliance with this condition allows for zero downtime during deployment. However, even when using very popular stacks (like NGINX and PHP-FPM), one can encounter difficulties that lead to a spike in errors during each deployment…

Theory. How a pod lives

We have already published details about the lifecycle of a pod seda artiklit. In the context of the topic at hand, we are interested in the following: at the moment when the pod transitions to a state Termineeritud, it stops receiving new requests (the pod – see kasutatakse ainult korra käsu käivitamiseks ja siis kaob! Infoturbe töötaja, kes jälgib ohvrimasinat, ei suuda tuvastada is removed from the endpoint list for the service). Thus, to avoid downtime during deployment, it is sufficient for us to resolve the issue of correctly shutting down the application.

It is also important to remember that the grace period by default is 30 seconds: after this, the pod will be terminated and the application must complete all requests within this period. Märkus: however, any request that takes longer than 5-10 seconds is already problematic, and graceful shutdown won't help it…

To better understand what happens when a pod shuts down, one can study the following diagram:

A1, B1 — Receiving changes about the pod's state
A2 — Sending SIGTERM
B2 — Removing the pod from the endpoints
B3 — Receiving changes (the list of endpoints has changed)
B4 — Updating iptables rules

Note: the removal of the pod's endpoint and sending SIGTERM do not occur sequentially, but in parallel. Because the Ingress does not immediately receive the updated list of Endpoints, new requests from clients will be sent to the pod, resulting in 500 errors during the pod's termination. (we have translated more detailed material on this issue) . This problem needs to be addressed in the following ways:)Sending Connection: close in response headers (if it is related to an HTTP application).

• If it is not possible to make changes to the code, then the article describes a solution that will allow requests to be fully processed until the end of the graceful period.
• Theory. How NGINX and PHP-FPM terminate their processes

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

NGINX

Alustame NGINXiga, kuna selle kasutamine on enam-vähem selge. Vaatame teooriat, et teada saada, et NGINX-il on üks meistrikäsk ja mitu „töötajat“ — need on alamprotsessid, mis töötlevad kliendi päringuid. On olemas mugav võimalus: käsu abil nginx -s protsesside lõpetamiseks, kas kiire lõppemise režiimis või sujuvas lõpetamises. Ilmselgelt huvitab meid viimane variant.

Edasi on kõik lihtne: tuleb lisada preStop-hüppamine käsk, mis saadab signaali sujuvaks lõpetamiseks. Seda saab teha paigutuses, konteineri plokis:

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

Nüüd, kui pod lõpetab töö, 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, et kõik on nagu peab: NGINX ootab päringute täitmist, mille järel lõpetab protsessi. Siiski, allpool käsitletakse tavalist probleemi, mille tõttu isegi käsu nginx -s quit protsess ei lõpe õigesti.

Nüüd oleme NGINX-iga ärajäänud; logidest on vähemalt selge, et kõik töötab nagu peab.

Kuidas on asjad PHP-FPM-iga? Kuidas see teostab sujuvat lõpetamist? Uurime lähemalt.

PHP-FPM

PHP-FPM-i puhul on teave veidi vähem. Kui toetuda ametlikule käsiraamatule PHP-FPM-i kohta, siis seal räägitakse, et aktsepteeritakse järgmisi POSIX-signaale:

1. SIGINT, SIGTERM — kiire lõpetamine;
2. SIGQUIT — sujuv lõpetamine (see, mis meid huvitab).

Ülejäänud signaale ei ole siin vaja, seega jätame need käsitlemata. Protsessi korrektseks lõpetamiseks on vajalik kirjutada järgmine preStop-hüppamine:

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

Esmapilgul näib, et see on kõik, mis vajalik sujuva lõpetamise teostamiseks mõlemas konteineris. Siiski, ülesanne on keerulisem, kui tundub. Edasi vaatame kahte juhtumit, kus sujuv lõpetamine ei toiminud ja põhjustas projekti ajutise kättesaamatuse juurutamise ajal.

Praktika. Võimalikud probleemid sujuva lõpetamisega

NGINX

Esiteks on kasulik meeles pidada: lisaks käsu täitmisele nginx -s quit on veel üks etapp, millele tasub tähelepanu pöörata. Oleme kokku puutunud probleemiga, kus NGINX saatis SIGTERM signaali hoopis SIGQUIT'i asemel, mistõttu päringud ei lõpetatud õigesti. Selliseid juhtumeid võib leida, näiteks, siin. Kahjuks ei õnnestunud meil selle käitumise konkreetset põhjust tuvastada: kahtlustati NGINX'i versioonides, kuid see ei leidnud kinnitust. Sümptomaatika seisnes selles, et NGINX-i konteineri logides ilmusid järgmised teated «open socket #10 left in connection 5», pärast mida pod peatati.

Sellist probleemi võime jälgida näiteks meie vajaliku Ingress'i vastustes:

Oleku koodide näitajad juurutamise hetkel

Antud juhul saame 503 veakoodi Ingress'ilt: see ei saa pöörduda NGINX-i konteineri poole, kuna see on juba mittesaadav. Kui vaadata NGINX-i konteineri logisid, on seal 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 tõendab, et 503 viga ei kordu enam.

Kui olete sarnase probleemiga silmitsi seisnud, on mõttekas välja selgitada, milline stopp-signaal kasutatakse konteineris ja kuidas täpselt preStop-hüük välja näeb. Tõenäoliselt peitub probleem just selles.

PHP-FPM… ja mitte ainult

PHP-FPM-i probleem on kirjeldatud triviaalsetena: see ei oota lasteprotsesside lõpetamist, terminiseerib need, mistõttu tekivad juurutamise ja muude toimingute käigus 502 vead. bugs.php.net lehelt on alates 2005. aastast mitmeid veateateid (näiteks, siin ja siin), mis kirjeldavad seda probleemi. Logides, tõenäoliselt, midagi ei näe: PHP-FPM teatab oma protsessi lõpetamisest ilma igasuguste vigadeta või külgnevate teavitusteta.

Tuleb täpsustada, et probleem ise võib sõltuda vähemal või suuremal määral rakendusest ning ei pruugi näiteks jälgimises välja paista. Kui te siiski kokku puutute, siis tuleb kõigepealt meelde lihtne lahendus: lisada preStop-hüük koos sleep(30). See võimaldab lõpetada kõik eelnevad päringud (ja me ei aktseptee uusi, kuna pod juba on seisundis Termineeritud), ja 30 sekundi möödudes lõpetab pod end signaaliga SIGTERM.

Selgub, et lifecycle konteineri jaoks näeb välja järgmiselt:

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

Kuid 30-sekundilise aja määramine sleep meie suuresti pikendab juurutamise aega, kuna iga pod lõpetatakse minimaalselt 30 sekundi pärast, mis on halb. Mida sellega teha?

Suundume poole, kes vastutab rakenduse otsese täitmise eest. Meie puhul on see PHP-FPM, mis vaikimisi ei jälgi oma child-protsesse: peaprotsess lõpetatakse kohe. Seda käitumist saab muuta juhisega process_control_timeout, mis määrab ajapiirangud signaalide ootamiseks peast alaealistele protsessidele. Kui seada väärtus 20 sekundile, katab see enamiku kaasasolevatest päringutest konteineris, ja pärast nende lõpetamist lõpetatakse peaprotsess.

Selle teadmisega pöördume tagasi meie viimase probleemi juurde. Nagu juba mainitud, ei ole Kubernetes monoliitne platvorm: erinevate komponentide vahelise suhtlemise jaoks kulub aega. See kehtib eriti siis, kui vaatame Ingresside ja teiste seotud komponentide tööd, kuna juurutamise ajal võib isegi tekkida 500-ndate vigu. Näiteks võib viga tekkida päringu saatmisel upstream'i, kuid tegelik 'ajalugu' komponentide vahelise suhtlemise vahel on üsna lühike — vähem kui sekund.

Seega, kokkuvõttes koos juba mainitud juhisega process_control_timeout võib kasutada järgmist konstruktsiooni lifecycle:

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

Sellisel juhul kompenseerime viivituse käsklusega sleep ja ei pikenda juurutamise aega: kas pole vahe 30 sekundi ja ühe vahel märgatav? Põhimõtteliselt on "peamine töö" just see, process_control_timeout, vaid lifecycle on lihtsalt kasutatud "kindlustuseks" viivituse korral.

Üldiselt käitumine ja vastav lahendus ei puuduta ainult PHP-FPM. Sarnane olukord võib tekkida ka teiste programmikeelte/raamistikudega. Kui teised meetodid ei aita graceful shutdown'i parandada — näiteks, kui kood on ümber kirjutatud nii, et rakendus töötleb lõpetamis signaale õigesti — võib rakendada kirjeldatud viisi. Olgu see mitte kõige ilusam, kuid see töötab.

Praktika. Koormustestimine podi töö kontrollimiseks

Koormustestimine on üks meetod, millega kontrollitakse, kuidas konteiner töötab, kuna see protseduur simuleerib reaalseid lahingutingimusi, kui saidile pääsevad juurde kasutajad. Ülaltoodud soovituste testimiseks saab kasutada Yandex.Tank: see katab suurepäraselt kõik meie vajadused. Edasi antakse näpunäiteid ja soovitusi testimise läbiviimiseks koos selge — tänu Grafana diagrammidele ja Yandex.Tanki näidenditele — näitega meie kogemusest.

Peamine siin on kontrollida muutusi etappidena. Pärast uue paranduse lisamist käivitage testimine ja vaadake, kas tulemused on võrreldes eelmise käivitamisega muutunud. Vastasel juhul on raske tuvastada ebaefektiivseid lahendusi ja tulevikus võivad need isegi kahju tekitada (nt suurendades juurutamise aega).

Teine nüanss on vaadata konteineri logisid selle lõpetamise ajal. Kas seal fikseeritakse teavet graceful shutdowni kohta? Kas logides on vigu, kui pöörduda teistele ressurssidele (nt naaberkonteiner PHP-FPM)? Kas rakenduse enda vead (nagu ülalpool kirjeldatud NGINX-i puhul)? Loodan, et selle artikli sissejuhatav teave aitab paremini mõista, mis siis juhtub konteineriga selle lõpetamise ajal.

Nii et esimene testimine toimus ilma lifecycle ja ilma täiendavate direktiivide jaoks rakendusserveris (process_control_timeout PHP-FPM-is). Selle testi eesmärk oli tuvastada ligikaudne vigade arv (ja kas neid üldse on). Samuti tuleb täiendavast teabest teada, et iga podi juurutamise keskmine aeg oli umbes 5-10 sekundit kuni täieliku valmiduseni. Tulemused on järgmised:

Yandex.Tanki teabepaneelil on näha 502 vigade tõus, mis toimus juurutamise hetkel ja kesta keskmiselt kuni 5 sekundit. Eeldatakse, et see katkestas olemasolevad päringud vanale pod’ile, kui see lõpetati. Pärast seda ilmnesid 503 vead, mis tulenesid peatatud NGINX-konteinerist, mis samuti katkestas ühendused põhiteenusega (mille tõttu ei saanud Ingress sellele ühenduda).

Vaadakem, kuidas process_control_timeout PHP-FPM aitab meil oodata child-protsesside lõpetamist, s.t. sellised vead parandada. Kordusjuurutamine juba selle direktiivi kasutamisega:

500-nd vigu ajal vigu enam ei ole! Deployimine läheb edukalt ja graceful shutdown toimib.

Siiski tasub meenutada hetke Ingress-konteineritega, kus me võime saada väikese protsendi vigu ajutise viivituse tõttu. Nende vältimiseks jääb alles struktuuri lisamine, sleep ja deployimine kordamine. Kuid meie konkreetses olukorras ei olnud muutusi näha (vigu ei ole jälle).

Kokkuvõte

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

1. Oodata paar sekundi, pärast mida lõpetada uute ühenduste vastuvõtmine.
2. Oodata, kuni kõik päringud on lõpetatud ning sulgeda kõik keepalive-ühendused, mis ei täida päringuid.
3. Lõpetada oma protsess.

Kuid mitte kõik rakendused ei oska nii töötada. Ühe lahendusena Kuberneteses on:

• pre-stop hooki lisamine, mis ootab paar sekundit;
• meie backend'i konfiguratsioonifaili uurimine vastavate parameetrite osas.

Näide NGINX-ist aitab mõista, et isegi rakendus, mis algselt peaks korrektselt lõpetamissignaale töötlema, ei pruugi seda teha, seega on kriitiline kontrollida 500 vigu rakenduse deployimise ajal. Samuti võimaldab see probleemile laiemalt vaadata ja mitte keskenduda eraldi pod'ile või konteinerile, vaid vaadata kogu infrastruktuuri tervikuna.

Testimise tööriigina võib kasutada Yandex.Tank'i koos mis tahes monitooringusüsteemiga (meie juhul kasutati testimiseks andmeid Grafanast, mille backend oli Prometheus). Probleemid graceful shutdowniga on selgelt nähtavad suurte koormate korral, mida võib genereerida benchmark, ja monitooring aitab olukorda täpsemalt analüüsida testi ajal või pärast seda.

Vastates artikli tagasisidele: tuleb märkida, et probleemid ja nende lahendused on siin kirjeldatud NGINX Ingress'i kontekstis. Teiste juhtumite jaoks on olemas teised lahendused, mida me võib-olla käsitleme järgmistes materjalides.

P.S.

Teine osa K8s näpunäidetest ja nippidest:

• «Isikupärastatud vigade lehed NGINX Ingress'is»;
• «Uhkete sõlmede ja koormuste jaotus veebirakendusele»;
• «Juurdepääs dev-keskkondadele»;
• «Kiirendame suurte andmebaaside bootstrap'i».

Allikas: habr.com