Mga tip ug trick sa Kubernetes: mga bahin sa matahum nga pagsira sa NGINX ug PHP-FPM

Usa ka tipikal nga kondisyon kung ipatuman ang CI/CD sa Kubernetes: ang aplikasyon kinahanglan nga dili makadawat sa bag-ong mga hangyo sa kliyente sa dili pa hingpit nga mohunong, ug labaw sa tanan, malampuson nga makompleto ang mga naa na.

Ang pagsunod sa kini nga kondisyon nagtugot kanimo nga makab-ot ang zero downtime sa panahon sa pag-deploy. Bisan pa, bisan kung gigamit ang labi ka sikat nga mga bundle (sama sa NGINX ug PHP-FPM), mahimo nimong masugatan ang mga kalisud nga mosangpot sa pagdagsang sa mga sayup sa matag pag-deploy...

Teorya. Unsaon pod kinabuhi

Gipublikar na namo ang detalye mahitungod sa siklo sa kinabuhi sa usa ka pod kini nga artikulo. Sa konteksto sa hilisgutan nga gikonsiderar, kami interesado sa mosunod: sa higayon nga ang pod mosulod sa estado Pag-terminate, ang mga bag-ong hangyo dili na ipadala niini (pod gikuha gikan sa lista sa mga endpoint alang sa serbisyo). Sa ingon, aron malikayan ang downtime sa panahon sa pag-deploy, igo na alang kanamo nga masulbad ang problema sa paghunong sa aplikasyon sa husto.

Kinahanglan usab nimong hinumdoman nga ang default nga panahon sa grasya mao 30 segundos: pagkahuman niini, ang pod ma-terminate ug ang aplikasyon kinahanglan adunay panahon sa pagproseso sa tanan nga mga hangyo sa wala pa kini nga panahon. Примечание: bisan kung ang bisan unsang hangyo nga molungtad labaw pa sa 5-10 segundos problema na, ug ang maayo nga pagsira dili na makatabang niini...

Aron mas masabtan kung unsa ang mahitabo kung ang usa ka pod matapos, tan-awa lang ang mosunod nga diagram:

A1, B1 - Pagdawat mga pagbag-o bahin sa kahimtang sa abohan
A2 - Pagbiya SIGTERM
B2 - Pagtangtang sa usa ka pod gikan sa mga endpoint
B3 - Pagdawat sa mga pagbag-o (ang lista sa mga endpoint nausab)
B4 - Pag-update sa mga lagda sa iptables

Palihug timan-i: ang pagtangtang sa endpoint pod ug pagpadala sa SIGTERM dili mahitabo nga sunud-sunod, apan managsama. Ug tungod sa kamatuoran nga ang Ingress dili dayon makadawat sa updated nga listahan sa mga Endpoints, ang mga bag-ong hangyo gikan sa mga kliyente ipadala ngadto sa pod, nga maoy hinungdan sa usa ka 500 nga sayup sa panahon sa pagtapos sa pod. (Alang sa mas detalyado nga materyal sa kini nga isyu, kami gihubad). Kini nga problema kinahanglang sulbaron sa mosunod nga mga paagi:

• Ipadala ang Koneksyon: duol sa tubag nga mga ulohan (kung kini may kalabotan sa HTTP nga aplikasyon).
• Kung dili posible ang paghimo og mga pagbag-o sa code, nan ang sunod nga artikulo naghulagway sa usa ka solusyon nga magtugot kanimo sa pagproseso sa mga hangyo hangtod sa katapusan sa graceful nga panahon.

Teorya. Giunsa pagtapos sa NGINX ug PHP-FPM ang ilang mga proseso

NGINX

Magsugod kita sa NGINX, tungod kay ang tanan labi pa o dili kaayo klaro niini. Pagsusi sa teorya, nahibal-an namon nga ang NGINX adunay usa ka master nga proseso ug daghang "mga trabahante" - kini ang mga proseso sa bata nga nagproseso sa mga hangyo sa kliyente. Gihatag ang usa ka kombenyente nga kapilian: gamit ang mando nginx -s <SIGNAL> tapuson ang mga proseso bisan sa paspas nga pagsira o madanihon nga mode sa pagsira. Dayag, kini ang ulahi nga kapilian nga nakapainteres kanato.

Unya ang tanan yano ra: kinahanglan nimo nga idugang preStop-hook usa ka mando nga magpadala usa ka madanihon nga signal sa pagsira. Mahimo kini sa Deployment, sa sudlanan block:

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

Karon, kung ang pod magsira, atong makita ang mosunod sa NGINX container logs:

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

Ug kini magpasabot sa atong gikinahanglan: NGINX naghulat alang sa mga hangyo nga makompleto, ug dayon mopatay sa proseso. Bisan pa, sa ubos atong hisgotan usab ang usa ka sagad nga problema tungod niini, bisan sa mando nginx -s quit sayop nga natapos ang proseso.

Ug sa kini nga yugto nahuman na kami sa NGINX: labing menos gikan sa mga troso nga imong masabtan nga ang tanan nagtrabaho ingon nga kini kinahanglan.

Unsa ang deal sa PHP-FPM? Giunsa niini pagdumala ang maayo nga pagsira? Atong hisgotan kini.

PHP-FPM

Sa kaso sa PHP-FPM, adunay gamay nga impormasyon. Kung magtutok ka sa opisyal nga manwal sumala sa PHP-FPM, kini moingon nga ang mosunod nga POSIX signal gidawat:

1. SIGINT, SIGTERM - paspas nga pagsira;
2. SIGQUIT — graceful shutdown (unsay atong gikinahanglan).

Ang nahabilin nga mga senyales wala kinahanglana sa kini nga buluhaton, mao nga atong laktawan ang ilang pagtuki. Aron tapuson ang proseso sa saktong paagi, kinahanglan nimong isulat ang mosunod nga preStop hook:

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

Sa una nga pagtan-aw, kini ra ang gikinahanglan aron mahimo ang usa ka matahum nga pagsira sa duha nga mga sudlanan. Apan, ang tahas mas lisod kay sa daw. Sa ubos mao ang duha ka mga kaso diin ang maayo nga pagsira wala molihok ug nagpahinabog hamubo nga panahon nga dili magamit ang proyekto sa panahon sa pag-deploy.

Pagpraktis. Posible nga mga problema sa maayo nga pagsira

NGINX

Una sa tanan, kini mapuslanon sa paghinumdom: dugang pa sa pagpatuman sa sugo nginx -s quit Adunay usa pa ka yugto nga angay hatagan pagtagad. Nakasugat mi og isyu diin magpadala gihapon ang NGINX og SIGTERM imbes nga signal sa SIGQUIT, hinungdan nga dili makompleto sa husto ang mga hangyo. Ang susamang mga kaso makita, pananglitan, dinhi. Ikasubo, wala namo matino ang espesipikong rason alang niini nga kinaiya: adunay usa ka pagduda mahitungod sa NGINX nga bersyon, apan wala kini gikumpirma. Ang simtoma mao nga ang mga mensahe naobserbahan sa NGINX container logs "abli nga socket #10 nahabilin sa koneksyon 5", pagkahuman nihunong pod.

Mahimo natong makita ang ingon nga problema, pananglitan, gikan sa mga tubag sa Ingress nga atong gikinahanglan:

Mga timailhan sa status code sa panahon sa pag-deploy

Sa kini nga kaso, nakadawat lang kami og 503 error code gikan sa Ingress mismo: dili kini maka-access sa NGINX nga sudlanan, tungod kay dili na kini ma-access. Kung imong tan-awon ang mga sudlanan nga log nga adunay NGINX, kini adunay mga musunud:

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

Human sa pagbag-o sa stop signal, ang sudlanan nagsugod sa paghunong sa husto: kini gipamatud-an sa kamatuoran nga ang 503 nga sayop wala na maobserbahan.

Kung makasugat ka og susama nga problema, makatarunganon nga mahibal-an kung unsa nga signal sa paghunong ang gigamit sa sudlanan ug kung unsa gyud ang hitsura sa preStop hook. Posible nga ang hinungdan naa gyud niini.

PHP-FPM... ug uban pa

Ang problema sa PHP-FPM gihulagway sa usa ka gamay nga paagi: wala kini maghulat sa pagkompleto sa mga proseso sa bata, kini nagtapos kanila, mao nga ang 502 nga mga sayup mahitabo sa panahon sa pag-deploy ug uban pang mga operasyon. Adunay daghang mga bug report sa bugs.php.net sukad 2005 (eg dinhi и dinhi), nga naghulagway niini nga problema. Apan lagmit dili ka makakitag bisan unsa sa mga log: Ang PHP-FPM magpahibalo sa pagkompleto sa proseso niini nga walay mga sayop o mga pahibalo sa ikatulo nga partido.

Angayan nga ipatin-aw nga ang problema mismo mahimong magdepende sa gamay o mas dako nga gidak-on sa aplikasyon mismo ug mahimong dili magpakita sa kaugalingon, pananglitan, sa pag-monitor. Kung masugatan nimo kini, usa ka yano nga solusyon ang una sa hunahuna: pagdugang usa ka preStop hook nga adunay sleep(30). Makatugot kini kanimo sa pagkompleto sa tanan nga mga hangyo nga kaniadto (ug dili kami modawat sa mga bag-o, tungod kay pod na makahimo sa Pag-terminate), ug pagkahuman sa 30 segundos ang pod mismo matapos sa usa ka signal SIGTERM.

Nahitabo kana lifecycle kay ang sudlanan mahimong ingon niini:

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

Apan, tungod sa 30-segundos sleep kita kusganon dugangan namon ang oras sa pag-deploy, tungod kay ang matag pod ma-terminate minimum 30 segundos, nga dili maayo. Unsa ang mahimo bahin niini?

Modangop kita sa partido nga responsable sa direktang pagpatuman sa aplikasyon. Sa among kaso mao kini PHP-FPM, nga pinaagi sa default wala magmonitor sa pagpatuman sa mga proseso sa bata niini: Ang master nga proseso gitapos dayon. Mahimo nimong usbon kini nga pamatasan gamit ang direktiba process_control_timeout, nga nagtino sa mga limitasyon sa panahon alang sa mga proseso sa bata nga maghulat alang sa mga signal gikan sa agalon. Kon imong ibutang ang bili ngadto sa 20 segundos, kini maglakip sa kadaghanan sa mga pangutana nga nagdagan sa sudlanan ug mohunong sa master nga proseso sa higayon nga sila makompleto.

Uban niini nga kahibalo, mobalik kita sa atong katapusang problema. Sama sa nahisgotan na, ang Kubernetes dili usa ka monolitikong plataporma: ang komunikasyon tali sa lain-laing mga sangkap niini nagkinahanglan ug panahon. Tinuod kini labi na kung gikonsiderar naton ang operasyon sa Ingresses ug uban pang mga may kalabutan nga sangkap, tungod kay tungod sa ingon nga paglangan sa panahon sa pag-deploy dali nga makakuha usa ka pagdagsang sa 500 nga mga sayup. Pananglitan, ang usa ka sayup mahimong mahitabo sa yugto sa pagpadala sa usa ka hangyo sa usa ka upstream, apan ang "oras nga lag" sa interaksyon tali sa mga sangkap medyo mubo - wala’y usa ka segundo.

Busa Sa kinatibuk-an uban sa nahisgutan na nga direktiba process_control_timeout mahimo nimong gamiton ang mosunod nga pagtukod alang sa lifecycle:

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

Sa kini nga kaso, atong bayran ang paglangan sa mando sleep ug dili kaayo madugangan ang oras sa pag-deploy: aduna bay mamatikdan nga kalainan tali sa 30 segundos ug usa?.. Sa tinuud, kini ang process_control_timeoutug lifecycle gigamit lamang ingon nga usa ka "safety net" sa kaso sa lag.

Sa kinatibuk-an ang gihulagway nga kinaiya ug ang katugbang nga workaround magamit dili lamang sa PHP-FPM. Ang usa ka susama nga sitwasyon mahimong usa ka paagi o lain nga motumaw sa paggamit sa ubang mga pinulongan/mga gambalay. Kung dili nimo ayohon ang madanihon nga pagsira sa ubang mga paagi - pananglitan, pinaagi sa pagsulat pag-usab sa code aron ang aplikasyon husto nga magproseso sa mga signal sa pagtapos - mahimo nimong gamiton ang gihulagway nga pamaagi. Tingali dili kini ang labing matahum, apan kini molihok.

Pagpraktis. Pag-load sa pagsulay aron masusi ang operasyon sa pod

Ang pagsulay sa pag-load usa sa mga paagi aron masusi kung giunsa ang paggana sa sudlanan, tungod kay kini nga pamaagi nagpaduol sa tinuod nga mga kondisyon sa kombat kung ang mga tiggamit mobisita sa site. Aron masulayan ang mga rekomendasyon sa ibabaw, mahimo nimong gamiton Yandex.Tankom: Kini naglangkob sa tanan natong mga panginahanglan sa hingpit. Ang mga mosunud mao ang mga tip ug rekomendasyon sa pagpahigayon sa pagsulay nga adunay tin-aw nga panig-ingnan gikan sa among kasinatian salamat sa mga graph sa Grafana ug Yandex.Tank mismo.

Ang labing importante nga butang dinhi mao susiha ang mga pagbag-o sa lakang. Human makadugang ug bag-ong ayo, padagana ang pagsulay ug tan-awa kon nausab ba ang mga resulta kon itandi sa kataposang dagan. Kung dili, lisud ang pag-ila sa dili epektibo nga mga solusyon, ug sa kadugayan mahimo ra kini makadaot (pananglitan, pagdugang oras sa pag-deploy).

Ang laing nuance mao ang pagtan-aw sa mga troso sa sudlanan sa panahon sa pagtapos niini. Narekord ba didto ang impormasyon bahin sa maayong pagsira? Aduna bay bisan unsang mga sayup sa mga troso kung nag-access sa ubang mga kapanguhaan (pananglitan, sa usa ka silingan nga sudlanan sa PHP-FPM)? Mga sayup sa aplikasyon mismo (sama sa kaso sa NGINX nga gihulagway sa ibabaw)? Nanghinaut ko nga ang pasiuna nga kasayuran gikan sa kini nga artikulo makatabang kanimo nga mas masabtan kung unsa ang mahitabo sa sudlanan sa panahon sa pagtapos niini.

Busa, ang unang pagsulay run nahitabo nga wala lifecycle ug walay dugang nga mga direktiba alang sa server sa aplikasyon (process_control_timeout sa PHP-FPM). Ang katuyoan niini nga pagsulay mao ang pag-ila sa gibanabana nga gidaghanon sa mga sayup (ug kung adunay bisan unsa). Usab, gikan sa dugang nga impormasyon, kinahanglan nimong masayran nga ang kasagarang oras sa pag-deploy sa matag pod maoy mga 5-10 ka segundos hangtod nga kini hingpit nga andam. Ang mga resulta mao ang:

Ang panel sa impormasyon sa Yandex.Tank nagpakita sa usa ka spike sa 502 nga mga sayup, nga nahitabo sa panahon sa pag-deploy ug milungtad sa aberids hangtod sa 5 segundos. Tingali kini tungod kay ang naglungtad nga mga hangyo sa daan nga pod gitapos sa dihang kini gitapos. Pagkahuman niini, ang 503 nga mga sayup nagpakita, nga mao ang sangputanan sa usa ka nahunong nga sudlanan sa NGINX, nga naghulog usab sa mga koneksyon tungod sa backend (nga nagpugong sa Ingress sa pagkonektar niini).

Tan-awon nato kung giunsa process_control_timeout sa PHP-FPM makatabang kanato sa paghulat alang sa pagkompleto sa mga proseso sa bata, i.e. pagtul-id sa maong mga sayop. I-deploy pag-usab gamit kini nga direktiba:

Wala nay mga sayup sa panahon sa ika-500 nga pag-deploy! Malampuson ang pag-deploy, maayo nga pagsira.

Bisan pa, angay nga hinumdoman ang isyu sa mga sudlanan sa Ingress, usa ka gamay nga porsyento sa mga sayup diin mahimo naton madawat tungod sa usa ka paglangan sa oras. Aron malikayan kini, ang nahabilin mao ang pagdugang usa ka istruktura sleep ug sublion ang deployment. Bisan pa, sa among partikular nga kaso, wala’y mga pagbag-o nga makita (pag-usab, wala’y mga sayup).

konklusyon

Aron tapuson ang proseso nga maayo, gipaabut namon ang mosunod nga pamatasan gikan sa aplikasyon:

1. Paghulat sa pipila ka mga segundo ug unya hunong sa pagdawat sa bag-ong mga koneksyon.
2. Paghulat alang sa tanan nga mga hangyo nga makompleto ug isira ang tanan nga keepalive nga mga koneksyon nga wala magpatuman sa mga hangyo.
3. Tapusa ang imong proseso.

Bisan pa, dili tanan nga mga aplikasyon mahimo nga molihok niini nga paagi. Usa ka solusyon sa problema sa mga kamatuoran sa Kubernetes mao ang:

• pagdugang og pre-stop hook nga maghulat og pipila ka segundo;
• pagtuon sa configuration file sa among backend alang sa angay nga mga parameter.

Ang panig-ingnan sa NGINX nagpatin-aw nga bisan ang usa ka aplikasyon nga kinahanglan una nga magproseso sa mga signal sa pagtapos sa husto mahimo nga dili mahimo, busa hinungdanon nga susihon ang 500 nga mga sayup sa panahon sa pag-deploy sa aplikasyon. Kini usab nagtugot kanimo sa pagtan-aw sa problema nga mas lapad ug dili mag-focus sa usa ka pod o sudlanan, apan tan-awa ang tibuok nga imprastraktura sa kinatibuk-an.

Ingon usa ka himan sa pagsulay, mahimo nimong gamiton ang Yandex.Tank kauban ang bisan unsang sistema sa pag-monitor (sa among kaso, ang datos gikuha gikan sa Grafana nga adunay backend nga Prometheus alang sa pagsulay). Ang mga problema sa madanihon nga pagsira tin-aw nga makita sa ilawom sa bug-at nga mga karga nga mahimo sa benchmark, ug ang pagmonitor makatabang sa pag-analisar sa sitwasyon sa mas detalyado sa panahon o pagkahuman sa pagsulay.

Agig tubag sa feedback sa artikulo: angay nga hisgutan nga ang mga problema ug solusyon gihulagway dinhi nga may kalabotan sa NGINX Ingress. Alang sa ubang mga kaso, adunay uban nga mga solusyon, nga mahimo natong tagdon sa mosunod nga mga materyales sa serye.

PS

Ang uban gikan sa K8s tips & tricks series:

• «Pasadya nga Mga Pahina sa Sayop sa NGINX Ingress";
• «Mahitungod sa alokasyon sa mga node ug sa mga load sa web application";
• «Pag-access sa mga site sa dev";
• «Pagpadali sa bootstrap alang sa dagkong mga database".

Source: www.habr.com