Viis viga esimest rakendust Kubernetes'is täiustades

Ebaõnnestumine autorilt Aris-Dreamer

Paljud arvavad, et piisab rakenduse viimisest Kubernetes'i (kas siis Helm’iga või käsitsi) — ja kõik on hästi. Kuid asi ei ole nii lihtne.

Meeskond Mail.ru Pilve Lahendused Tõlkinud DevOps-insener Julian Gindi artikkel. Ta räägib, milliste takistustega tema ettevõte migratsiooni käigus silmitsi seisis, et te ei langeks samadesse auhindadesse.

Esimene samm: podide päringute ja piirangute seadistamine

Alustame puhta keskkonna seadistamisest, milles meie podid töötavad. Kubernetes saab suurepäraselt hakkama podide planeerimise ja rikkeolukordade haldamisega. Kuid selgub, et planeerija ei saa mõnikord podi asetada, kui tal on raske hinnata, kui palju ressursse on tal vaja eduka töö jaoks. Just siin tulevad mängu ressursi päringud ja piirangud. Palju arutelusid käivad selle üle, mis on parim lähenemine päringute ja piirangute seadistamiseks. Mõnikord tundub, et see on pigem kunst kui teadus. Siin on meie lähenemine.

Podide päringud (pod requests) on põhiväärtus, mida planeerija kasutab podi optimaalseks paigutamiseks.

Kuna Kubernetes'e dokumentatsioonile: filtreerimise etapis määratakse kindlaks sõlmed, kuhu podi võib plaanida. Näiteks filter PodFitsResources kontrollib, kas sõlmes on ressursse, et rahuldada konkreetsete podide ressursi päringuid.

Kasutame rakenduste päringuid nii, et nende põhjal saab hinnata, kui palju ressursse tõeliselt on rakendusele normaalseks tööks vajalik. Nii suudab planeerija realistlikult sõlmi paigutada. Esialgu tahtsime seadistada päringud üle, et tagada igale podile piisavalt suuri ressursse, kuid märkasime, et planeerimisaeg kasvas märkimisväärselt, ning mõned podid ei saanud täielikult planeeritud, nagu ei oleks neile mingit ressursi päringut laekunud.

Sellisel juhul viis planeerija sageli podid „välja” ja ei suutnud neid uuesti planeerida, kuna halduskiht ei teadnud, kui palju ressursse rakendusele tuleks, ja see on planeerimise algoritmi võtmeelement.

Podide piirangud (pod limits) on podile selgema piiranguna. See on maksimaalne ressursi maht, mille klaster eraldab konteinerile.

Taaskord, ... ametlikust dokumentatsioonist: kui konteinerile on määratud 4 GiB mälu piirang, sunnib kubelet (ja konteineri käituskeskkond) seda kasutama. Käituskeskkond ei luba konteineril kasutada rohkem kui määratud ressursside piirang. Näiteks, kui konteineris olev protsess üritab kasutada rohkem lubatud mälumahtu, lõpetab süsteemifikaader selle protsessi vigaga „mälu lõpp“ (OOM).

Konteiner võib alati kasutada rohkem ressursse, kui on määratud ressursi taotlemisel, kuid kunagi ei tohi ta kasutada rohkem kui on määratud piirangus. Selle mõistmine on keeruline, kuid see on väga oluline.

Ideaalis soovime, et podi ressursi nõudmised muutuksid protsessi elutsükli jooksul, segamata teisi süsteemi protsesse — see on piirangute seadmise eesmärk.

Kahjuks ei saa ma anda konkreetseid juhiseid, milliseid väärtusi määrata, kuid meie järgime järgmisi reegleid:

1. Kasvatuskatsetamise tööriistaga modelleerime põhitaseme liiklust ja jälgime podi ressursikasutust (mälu ja protsessor).
2. Määrame podi nõudmised meelevaldselt madalale tasemele (ressursi piirang on umbes 5 korda suurem kui nõudmiste väärtus) ja jälgime. Kui nõudmised on liiga madalad, ei saa protsess alata, mis sageli põhjustab Go ajalisi salakavalikke vigu.

Soovin märkida, et kõrgemad ressursipiirangud raskendavad planeerimist, kuna pod vajab sihtsõlme, millel on piisavalt vabu ressursse.

Kujutlege olukorda, kus teil on kergekaaluline veebiserver väga kõrgete ressursipiirangutega, näiteks 4 GB mälu. Tõenäoliselt tuleb see protsess horisontaalselt skaleerida ja iga uus moodul tuleb planeerida sõlme, millel on vähemalt 4 GB vaba mälu. Kui sellist sõlme pole, peab klaster lisama uue sõlme, et seda podi töödelda, mis võib võtta aega. Oluline on saavutada minimaalne erinevus ressursinõuete ja -piirangute vahel, et tagada kiire ja sujuv skaleerimine.

Teine etapp: Liveness ja Readiness testide seadistamine

See on veel üks delikaatne teema, mida arutatakse sageli Kubernetes'i kogukonnas. On oluline mõista elujõudluskatsete (Liveness) ja valmiduskatsete (Readiness) olemust, kuna need tagavad tarkvara stabiilse töö ja minimeerivad seisakuaega. Kui neid pole õigesti seadistatud, võivad need aga tõsiselt mõjutada teie rakenduse jõudlust. Allpool on lühike kokkuvõte mõlema katse olemusest.

Elujõudlus näitab, kas konteiner töötab. Kui see ebaõnnestub, tapab kubelet konteineri ja aktiveerib sellel taastamisstrateegia. Kui konteineril pole elujõudluskatset, siis on vaikimisi olekuks õnnestumine, nagu öeldakse Kubernetes'e dokumentatsioonile.

Elujõudluskatsetel peaks olema madalad nõudmised, st nad ei tohi tarbida palju ressursse, kuna neid käivitatakse sageli ja need peavad teavitama Kubernetes'i, et rakendus on töötav.

Kui seadistate parameetri käivitamiseks iga sekundi tagant, lisab see 1 päringu sekundis, seega arvestage, et selle liikluse töötlemiseks on vaja lisajõude.

Meie ettevõttes kontrollivad elujõudluskatsetes rakenduse põhikomponente, isegi kui andmed (näiteks eemal olevast andmebaasist või vahemälust) pole täielikult kättesaadavad.

Oleme rakendustes seadnud töökindluse lõpp-punkti, mis lihtsalt tagastab vastuskoodi 200. See tähendab, et protsess on käivitatud ja suudab päringutele vastata (aga mitte veel liiklusele).

Katsed Valmidus näitab, kas konteiner on valmis päringutele vastama. Kui valmiduskatse ebaõnnestub, eemaldab lõpp-punktide kontroller poodi IP-aadressi kõikidest teenuse lõpp-punktidest, mis vastavad poele. See on samuti toodud Kubernetes'i dokumentatsioonis.

Valmiduskatsetel on suuremad ressursinõudmised, kuna need peavad jõudma taustale viisil, mis näitab rakenduse valmidust päringute vastuvõtmiseks.

Kogukonnas arutatakse palju, kas otse andmebaasile pöörduda. Arvestades kulusid (kontrollid toimuvad sageli, kuid neid saab reguleerida), oleme otsustanud, et teatud rakenduste puhul loetakse valmisolek teenindada liiklust kehtivaks ainult pärast seda, kui on kontrollitud, et andmebaasist tagastatakse kirjed. Hästi läbi mõeldud valmisoleku proovid on taganud kõrgema kättesaadavuse taseme ja välistanud seiskumised juurutamise ajal.

Kui otsustate teha andmebaasi päringu rakenduse valmisoleku kontrollimiseks, veenduge, et see maksaks võimalikult vähe. Võtame näiteks selle päringu:

SELECT small_item FROM table LIMIT 1

Siin on näide, kuidas me neid kahte väärtust Kuberneteses seadistame:

livenessProbe:  
 httpGet:  
   path: /api/liveness  
   port: http  
readinessProbe:  
 httpGet:  
   path: /api/readiness  
   port: http  periodSeconds: 2

Saate lisada mõned täiendavad konfigureerimise parameetrid:

• initialDelaySeconds — kui palju sekundite jooksul peaks kuluma konteineri käivitamise ja pinda proovide käivitamise vahel.
• periodSeconds — ootamise intervall katsete tegemise vahel.
• timeoutSeconds — sekundite arv, pärast millega peetakse pinda rikki. Tavaline ajavahemik.
• failureThreshold — katsete ebaõnnestumise arv enne, kui pind saadab taaskäivitamise signaali.
• successThreshold — eduka proovi arv enne, kui pind läheb valmisoleku seisundisse (pärast rikete, kui pind taaskäivitub või taastub).

Kolmas samm: pinda vaikevõrgupoliitikate seadistamine

Kuberneteses on "tasane" võrgu topoloogia, kus kõik pinnad suhtlevad omavahel otse. Mõnes olukorras ei ole see soovitav.

Potentsiaalne turvaprobleem seisneb selles, et kurjategija võib kasutada ühte haavatavat rakendust, et suunata liiklust kõikidele pinna võrku. Nagu paljudes turvavaldkondades, kehtib siin minimaalsete õiguste printsiip. Ideaalis peab võrgupoliitikad selgelt määratlema, millised ühendused pindade vahel on lubatud ja millised mitte.

Näiteks allpool on lihtne poliitika, mis keelab kogu sissetuleva liikluse teatud nimeruumis:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

Selle konfiguratsiooni visualiseerimine:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Rohkem detaile siin.

Neljas samm: mittetavaline käitumine hukkude ja alguse konteinerite abil

Üks meie peamisi ülesandeid oli tagada Kubernetes'e juurutamised, ilma et arendajatele tekiks seiskumisi. See on keeruline, kuna rakenduste sulgemisviise ja nende kasutatud ressursside vabastamise võimalusi on palju.

Eriti suured raskused tekkisid Nginx. Me märkasime, et nende podide järjestikuse juurutamise ajal katkestati aktiivsed ühendused enne eduka sulgemise lõpuleviimist.

Pärast ulatuslikku uurimistööd internetis selgus, et Kubernetes ei oota, kuni Nginxi ühendused on ammendatud, enne kui podi sulgeb. Pre-stop huki abil integreerisime sellise funktsionaalsuse ja vabanesime täielikult seisakutest:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

Ja siin on nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

Veel üks äärmiselt kasulik paradigma on init-konteinerite kasutamine konkreetsete rakenduste käivitamiseks. See on eriti kasulik, kui teil on ressursimahukas andmebaasi migratsiooniprotsess, mis tuleb algatada enne rakenduse käivitamist. Selle protsessi jaoks saate samuti määrata kõrgema ressursi limiidi, ilma et peaksite seda limiiti seadma põhietendusele.

Teine levinud skeem on salajastele ligipääs init-konteineris, mis edastab need volitused põhikomponendile, vältides seadusliku juurdepääsu salajastele otse põhikomponendist.

Nagu tavaliselt, küsite dokumentatsioonist: init-konteinerid käivitavad ohutult kasutaja koodi või utiliite, mis muidu vähendaksid rakenduse konteineri pildi turvalisust. Hoides eraldi tarbetud tööriistad, piirate rakenduse konteineri pildi ründe pinda.

Viies samm: tuuma seadistamine

Lõpetuseks räägime pisut edasijõudnud tehnikast.

Kubernetes on erakordselt paindlik platvorm, mis võimaldab käitada töökoormusi nii, nagu te seda soovite. Meil on mitmeid kõrge tootlikkusega rakendusi, mis nõuavad tohutult palju ressursse. Ulatuslikul koormustestimisel avastasime, et üks rakendustest peab liikluse oodatavat koormust silmas pidades vaeva.

Kubernetes võimaldab käivitada privileeritud konteineri, mis muudab tuuma parameetreid ainult konkreetse podi jaoks. Siin on, mida me kasutasime maksimaalse avatud ühenduste arvu muutmiseks:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

See on keerukam tehnika, mida ei pruugita sageli vajada. Kuid kui teie rakendus vaevu talub suurt koormust, võite proovida mõningaid neist parameetritest seadistada. Täiendav teave selle protsessi ja erinevate väärtuste seadistamise kohta on, nagu alati, ametlikus dokumentatsioonis.

Kokkuvõtteks

Kuigi Kubernetes võib tunduda valmis lahendusena "karbist välja", on rakenduste sujuvaks toimimiseks vajalik võtta mõned olulised sammud.

Kogu Kubernetesesse migreerimise jooksul on oluline järgida "koormustestis tsüklit": käivitate rakenduse, testeeri seda koormuse all, jälgige mõõdikuid ja käitumist skaleerimise ajal, seadistate konfiguratsiooni nende andmete alusel, seejärel kordate tsüklit.

Hinnake realistlikult oodatavat liiklust ja proovige sellest üle jõuda, et näha, millised komponendid murduvad esimesena. Sellise iteratiivse lähenemisega võib piisata vaid mõne ülaltoodud soovituse järgimisest, või võib olla vajalik sügavam seadistamine.

Küsi endalt alati järgmisi küsimusi:

1. Kui palju ressursse rakendused kasutavad ja kuidas see maht muutub?
2. Millised on tegelikud skaleerimise nõuded? Kui palju liiklust keskmiselt rakendus talub? Aga tippkoormuse ajal?
3. Kui sageli vajab teenus horisontaalset skaleerimist? Kui kiiresti tuleb uusi pode tööle võtta, et liiklust vastu võtta?
4. Kuidas toimub pode korrektne lõpetamine? Kas see on vajalik? Kas on võimalik saavutada üleslaadimist ilma seisakuteta?
5. Kuidas minimeerida turvariske ja piirata kahju mistahes kompromiteeritud pode puhul? Kas mõnel teenusel on õigusi või juurdepääse, mida nad ei vaja?

Kubernetes pakub uskumatu platvormi, mis võimaldab rakendada parimaid praktikaid tuhandete teenuste juurutamiseks klastrisse. Siiski on kõik rakendused erinevad. Mõnikord nõuab juurutamine natuke rohkem tööd.

Õnneks pakub Kubernetes vajalikke seadistusi, et saavutada kõik tehnilised eesmärgid. Kasutades ressursside päringute ja piiride kombinatsiooni, Liveness ja Readiness proove, init-konteinereid, võrgu poliitikaid ning kohandatud tuuma seadistust, saate saavutada kõrge jõudluse koos tõrke taluvuse ja kiire skaleeritavusega.

Mida veel lugeda:

1. Parimad tavad ja soovitused konteinerite ja Kubernetes'i käitamiseks tootmiskeskkondades.
2. 90+ kasulikku tööriista Kubernetes'ile: juurutamine, haldamine, jälgimine, turvalisus ja mitte ainult.
3. Meie Tee Kuberneetes kanal Telegrmis.

Allikas: habr.com