Viis viga esmakordse rakenduse kasutusele võtmisel Kubernetesis

Aris-Dreamer'i ebaõnnestumine

Paljud arvavad, et piisab rakenduse migreerimisest Kubernetesesse (kas siis Helm'i abil või käsitsi) — ja kõik on hästi. Aga asi ei ole nii lihtne.

Meeskond Mail.ru Cloud Solutions Tõlkis DevOps-inseneri Julian Gindi artikkel. Ta räägib, milliste takistustega tema ettevõte migratsiooni käigus silmitsi seisis, et te ei langeks samadesse lõksudesse.

Esimene samm: podi päringute ja piirangute seadistamine

Alustame puhta keskkonna seadistamisest, kus meie podid töötavad. Kubernetes tegeleb podide planeerimise ja tõrgete töötlemisega suurepäraselt. Kuid selgus, et mõnikord ei suuda planeerija podi paigutada, kui tal on keeruline hinnata, kui palju ressursse on vajalik eduka toimimise jaoks. Just siinkohal ilmnevad ressursipäringute ja piirangute seadistamise küsimused. Selle üle käib palju arutelusid parima lähenemisviisi osas, aeg-ajalt tundub, et see on pigem kunst kui teadus. See on meie lähenemine.

Podide päringud on peamine väärtus, mida planeerija kasutab podi optimaalse paigutuse määramiseks.

Uusimad Kubernetes'i dokumentatsioonis: filtreerimise etapis määratakse node'ite komplekt, kus saab plaanida pod'i. Näiteks filtril PodFitsResources kontrollitakse, kas node'il on piisavalt ressursse, et rahuldada konkreetse pod'i ressursinõudmisi.

Rakenduste nõudmisi kasutame selliselt, et neid saaks hinnata, kui palju ressursse tõepoolest rakendus vajab normaalseks tööks. Nii suudab planijate realistlikult paigutada node'id. Alguses soovisime seada nõudmisi reservides, et garanteerida iga pod'i jaoks piisavalt ressursse, kuid märkisime, et planeerimisaeg suurenes oluliselt ning mõned pod'id ei olnud kunagi täielikult plaanitud, nagu ei oleks nende jaoks ressursinõudmisi esitatud.

Sellisel juhul „väljastas” planeerija sageli pod'e ja ei suutnud neid uuesti planeerida, kuna juhtimisplaadil polnud aimugi, kui palju ressursse rakendus vajab, ja see on planeerimise algoritmi võtmekomponent.

Pod'i piirangud (pod limits) on selgem piirang pod'i jaoks. See on maksimaalne ressursikulu, mille klaster eraldab konteinerile.

Jälle, alates ametlikus dokumentatsioonis: kui konteineril on määratud mälulimiit 4 GiB, siis veebiserver (ja konteineri käituskeskkond) sundimisega kasutab seda limiiti. Käituskeskkond ei luba konteineril kasutada rohkem ressursse, kui see limiit on määratud. Näiteks kui konteineris olev protsess üritab kasutada rohkem lubatud mälu, lõpetab süsteemi tuum selle protsessi „välja mälu” (OOM) veaga.

Konteiner saab alati kasutada rohkem ressursse kui ressursitaotluses määratud, kuid ei tohi kunagi ületada määratud limiiti. Selle väärtuse õige seadmine on keeruline, kuid see on väga oluline.

Ideaalis soovime, et pod'i ressursinõuded muutuksid protsessi elutsükli jooksul, segamata teisi süsteemis töötavaid protsesse – see on piiride seadmise eesmärk.

Kahjuks ei saa ma anda konkreetseid juhiseid, millised väärtused seadistada, kuid järgime ise järgmisi reegleid:

1. Kasuta koormustestimise tööriista, et modelleerida põhitaseme liiklust ja jälgida pod'i ressursikasutust (mälu ja protsessor).
2. Seame podi päringud ja seadistame need juhuslikult madalale tasemele (ressursside piiranguga, mis on umbes 5 korda suurem kui päringute tase) ja jälgime olukorda. Kui päringud on liiga madalal tasemel, ei saa protsess alata, mis tihtipeale põhjustab kummalisi Go jooksuaja vigu.

Soovin märkida, et kõrgemad ressursipiirangud muudavad planeerimise keerulisemaks, kuna pod vajab sihtsõlme, kus on piisavalt ressursse saadaval.

Kujutage ette olukorda, kus teil on kergekaaluline veebiserver väga kõrgete ressursipiirangutega, näiteks 4 GB mälu. Tõenäoliselt tuleb seda protsessi horisontaalselt skaleerida ning iga uus moodul tuleb planeerida sõlmesse, kus on saadaval vähemalt 4 GB mälu. Kui sellist sõlme ei ole, peab klaster lisama uue sõlme selle podi töötlemiseks, mis võib võtta aega. Oluline on saavutada minimaalne erinevus ressursipäringute ja piirangute vahel, et tagada kiire ja sujuv skaleerimine.

Teine samm: Liveness ja Readiness testide seadistamine

See on veel üks peen teema, mis on sageli arutlusel Kubernetes'i kogukonnas. Oluline on hästi mõista elujõudluse (Liveness) ja valmiduse (Readiness) teste, kuna need tagavad tarkvara stabiilse töömehhanismi ja vähendavad seismise aega. Siiski võivad need tõsiselt kahjustada rakenduse jõudlust, kui neid ei ole õigesti seadistatud. Allpool on lühikokkuvõte, mida mõlemad proovid endast kujutavad.

Elujõudlus näitab, kas konteiner töötab. Kui see ebaõnnestub, tapab kubelet konteineri ja rakendatakse taaskäivitamise poliitikat. Kui konteineril ei ole elujõudluse proovi, on vaikimisi olekuks edu — nii on öeldud Kubernetes'i dokumentatsioonis.

Elujõudluse proovid peavad olema odavad, st nad ei tohi tarbida palju ressursse, kuna neid käivitakse sageli ja need peavad teavitama Kubernetes'i, et rakendus on käivitatud.

Kui seadistate parameetri käivitamiseks iga sekundi järel, lisab see 1 päringu sekundis, seega pidage meeles, et selle liikluse töötlemiseks on vaja täiendavaid ressursse.

Meie ettevõttes kontrollivad Liveness-testid rakenduse põhikomponente, isegi kui andmed (näiteks eemalt andmebaasilt või vahemälust) ei ole täielikult kättesaadavad.

Oleme rakendustes seadistanud töökindluse lõpp-punkti, mis lihtsalt tagastab vastuse koodi 200. See näitab, et protsess on käivitunud ja suudab töödelda päringuid (aga mitte veel liiklust).

Proov Valmidus näitab, kas konteiner on valmis päringute teenindamiseks. Kui valmiduse proov ebaõnnestub, eemaldab lõpp-punktide kontrollija podi IP-aadresse kõikidega teenustega, mis vastavad podile. Seda on ka dokumentatsioonis kirjeldatud Kubernetes.

Valmiduse proovid tarbivad rohkem ressursse, kuna need peavad jõudma backend'i viisil, et näidata rakenduse valmidust päringute vastuvõtmiseks.

Kogukonnas käib palju arutelu selle üle, kas otse andmebaasi pöörduda. Arvestades kulusid (kontrollimisi tehakse sageli, kuid neid saab reguleerida), oleme otsustanud, et teatud rakenduste jaoks loetakse liikluse teenindamise valmisolekuks, kui on kontrollitud, et andmebaasist tagastatakse kirjed. Hästi läbi mõeldud valmisoleku proovid tagavad kõrgema kättesaadavuse taseme ja kõrvaldatakse seisakud juurutamise ajal.

Kui otsustate andmebaasi päringut kasutada rakenduse valmisoleku kontrollimiseks, veenduge, et see oleks võimalikult odav. Vaadakem sellist päringut:

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

Võib lisada mõned täiendavad konfiguratsiooniparametrid:

• initialDelaySeconds — kui palju sekundeid möödub konteineri käivitamisest kuni proovide käivitamiseni.
• periodSeconds — proovide käivitamiste vahelise ootamise intervall.
• timeoutSeconds — sekundeid, pärast mida loetakse konteiner defektseks. Tavaline ajapiirang.
• failureThreshold — testide ebaõnnete arv, enne kui konteiner saadab taaskäivitamise signaali.
• successThreshold — edukate proovide arv, enne kui konteiner läheb valmisoleku staatusesse (pärast riket, kui konteiner käivitatakse või taastatakse).

Kolmas samm: konteineri vaikevõrgupoliitikate seadistamine

Kuberneteses on „lamedat“ võrgu topoloogiat, vaikimisi suudavad kõik konteinerid omavahel otse suhelda. Mõnel juhul on see ebasoovitav.

Võimalik turvaprobleem seisneb selles, et ründaja võib kasutada ühte haavatavat rakendust, et suunata liiklust kõikidesse võrgu konteineritesse. Nagu paljudes turvavaldkondades, kehtib ka siin vähimate privileegide printsiip. Ideaalis peaksid võrgu poliitikad selgelt määrama, millised ühendused konteinerite vahel on lubatud ja millised mitte.

Näiteks on allpool lihtne poliitika, mis keelab kogu sissetuleva liikluse konkreetse nimede ruumi jaoks:

---
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)
Üksikasjalikumalt siit.

Neljas samm: kohandatud käitumine hookide ja init-konteineritega

Üks meie peamisi ülesandeid oli tagada Kuberneteses juurutamiseks katkestusteta arendajatele. See on keeruline, kuna on palju võimalusi rakenduste sulgemiseks ja nende kasutatud ressursside vabastamiseks.

Eriti raskused tekkisid Nginx. Me märkisime, et nendel pod’ide järjestikusel juurutamisel katkestati aktiivsed ühendused enne edukat lõpetamist.

Pärast ulatuslikku uurimist internetis selgus, et Kubernetes ei oota, kuni Nginxi ühendused on ammendunud, enne kui pod’i sulgeb. Pre-stop hook’i abil integreerisime sellise funktsionaalsuse ja pääsesime täielikult katkestusest:

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 kasulik on kasutada init-konteinereid konkreetsete rakenduste käivitamiseks. See on eriti kasulik, kui teil on ressursimahukas andmebaasi migreerimise protsess, mille peate käivitama enne rakenduse tõstmist. Selle protsessi jaoks saate läbi viia ka kõrgema ressursside piiri, ilma et peaksite selle piiri seadma põhiraamatule.

Teine levinud skeem on juurdepääs saladustele init-konteineris, mis edastab need mandaadid põhikomponendile, vältides seeläbi põhikomponendi rakenduse kaudu saladustele volitamata juurdepääsu.

Nagu tavaliselt, tsitaat dokumentatsioonist: init-konteinerid käivitavad kasutaja koodi või utiliite turvaliselt, mis muidu vähendaks rakenduse konteineri pildi turvalisust. Hoides eraldi tarbetuid tööriistu, piirate rakenduse konteineri pildi rünnaku pindala.

Viies samm: tuuma seadistamine

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

Kubernetes on äärmiselt paindlik platvorm, mis võimaldab teil töökoormusi hallata just niimoodi, nagu te soovite. Meil on mitmeid kõrgjõudlusega rakendusi, mis nõuavad väga palju ressursse. Põhjalike koormustestide käigus oleme avastanud, et üks rakendus vaevab end oodatava liikluse koormusega, kui kehtivad Kubernetes'e vaikeseaded.

Kuid Kubernetes võimaldab käivitada privileegitud konteineri, mis muudab tuumaparameetreid ainult konkreetse pod'i jaoks. Sedasi muutisime avatud ühenduste maksimumarvu:

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

See on arenenum tehnika, mis ei pruugi alati vajalik olla. Kuid kui teie rakendus vaevleb suure koormuse all, võite proovida mõningaid neist parameetritest seadistada. Üksikasjalikumat teavet selle protsessi ja erinevate väärtuste seadistamise kohta leiate — nagu alati ametlikust dokumentatsioonist.

Kokkuvõtteks

Kuigi Kubernetes võib tunduda kui valmis lahendus "karbist välja", on rakenduste sujuvaks toimimiseks vajalikud mitmed olulised sammud.

Kogu Kubernetesesse migreerimise vältel on oluline järgida "koormustestimise tsüklit": käivitage rakendus, testige seda koormuse all, jälgige mõõdikute ja käitumise muutusi skaleerimise ajal, seadistage konfiguratsioon vastavalt nendele andmetele ning korrake seda tsüklit.

Hinnake realistlikult oodatavat liiklust ja proovige sellest üle astuda, et näha, millised komponendid purunevad esimesena. Sellise iteratiivse lähenemisviisi puhul võivad mõned nimetatud soovitustest olla piisavad eduks. Võib-olla on 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 reaalsed skaleerimisnõuded? Kui palju liiklust suudab rakendus keskmiselt käidelda? Ent kuidas on olukord tippläbilaske korral?
3. Kui tihti vajab teenus horisontaalset skaleerimist? Kui kiiresti tuleb uusi pod'e käiku lasta, et liiklust vastu võtta?
4. Kuidas pod'id lõpetavad oma töö? Kas see on üldse vajalik? Kas saab saavutada juurutamist ilma seisakuteta?
5. Kuidas minimeerida turvariske ja piirata kahju, mis tuleneb mistahes kompromiteeritud pod'idest? Kas mõni teenus omab õigusi või juurdepääse, mis pole vajalikud?

Kubernetes pakub uskumatut platvormi, mis võimaldab kasutada parimaid tavasid tuhande teenuse juurutamiseks klastris. Siiski on kõik rakendused erinevad. Mõnikord vajab juurutamine veidi rohkem tööd.

Õnneks pakub Kubernetes vajalikud seadistused kõigi tehniliste eesmärkide saavutamiseks. Kasutades ressursside nõudeid ja piire, Liveness ja Readiness probe'e, init-konteinereid, võrgu poliitikaid ja kohandatud tuuma konfiguratsiooni, on võimalik saavutada kõrge jõudlus koos talitluskindluse ja kiire skaleeritavusega.

Mida veel lugeda:

1. Parimad praktikad ja soovitused konteinerite ja Kubernetes'i käitamiseks tootmisringkondades..
2. 90+ kasulikku tööriista Kubernetes'ile: juurutamine, haldamine, jälgimine, turvalisus ja mitte ainult.
3. Meie kanal Kubernetesest Telegramis.

Allikas: habr.com