Margir halda að það sé nóg að flytja forritið til Kubernetes (annaðhvort með því að nota Helm eða handvirkt) - og það verður hamingja. En ekki er allt svo einfalt.
Team þýddi grein eftir DevOps verkfræðinginn Julian Gindy. Hann segir hvaða gildrur fyrirtæki hans stóð frammi fyrir í flutningsferlinu svo þú stígur ekki á sömu hrífuna.
Skref eitt: Settu upp podbeiðnir og takmörk
Byrjum á því að setja upp hreint umhverfi þar sem belgirnir okkar munu hlaupa. Kubernetes er frábært í pod tímasetningu og failover. En það kom í ljós að tímaáætlunarmaðurinn getur stundum ekki sett belg ef erfitt er að áætla hversu mörg tilföng hann þarf til að virka með góðum árangri. Þetta er þar sem beiðnir um úrræði og takmörk skjóta upp kollinum. Það er mikið deilt um bestu nálgunina við að setja beiðnir og takmarkanir. Stundum virðist sem þetta sé í raun meira list en vísindi. Hér er nálgun okkar.
Pod beiðnir er aðalgildið sem tímaáætlunarmaðurinn notar til að staðsetja belginn sem best.
Af : Síuskrefið skilgreinir mengi hnúta þar sem hægt er að tímasetja Pod. Til dæmis athugar PodFitsResources sían til að sjá hvort hnútur hafi nægt fjármagn til að fullnægja tilteknum tilföngsbeiðnum frá hólf.
Við notum umsóknarbeiðnir á þann hátt að við getum metið hversu mörg tilföng raunar Forritið þarf það til að virka rétt. Þannig getur tímaáætlunarmaðurinn sett hnútana á raunhæfan hátt. Upphaflega vildum við oftíma beiðnum til að tryggja nægjanlegt fjármagn fyrir hvern Pod, en við tókum eftir því að tímasetningartíminn jókst verulega og sumir Pods voru ekki að fullu tímasettir, eins og engar forðabeiðnir væru fyrir þá.
Í þessu tilviki myndi tímaáætlunarmaðurinn oft "kreista út" belgina og geta ekki endurskipulagt þá vegna þess að stjórnvélin hafði ekki hugmynd um hversu mikið fjármagn forritið þyrfti, sem er lykilþáttur í tímasetningaralgríminu.
Pod takmörk er skýrari mörk fyrir belg. Það táknar hámarksmagn auðlinda sem þyrpingin mun úthluta til gámsins.
Aftur, frá : Ef gámur hefur minnistakmörk upp á 4 GiB, þá mun kúbelet (og keyrslutími gáma) framfylgja því. Afgreiðslutíminn kemur í veg fyrir að ílátið noti meira en tilgreind tilfangamörk. Til dæmis, þegar ferli í íláti reynir að nota meira en leyfilegt magn af minni, lýkur kerfiskjarninn ferlinu með "out of memory" (OOM) villu.
Gámur getur alltaf notað fleiri auðlindir en auðlindabeiðnin tilgreinir, en hann getur aldrei notað meira en hámarkið. Þetta gildi er erfitt að stilla rétt, en það er mjög mikilvægt.
Helst viljum við að auðlindaþörf fræbelgs breytist á líftíma ferlis án þess að trufla önnur ferli í kerfinu - þetta er tilgangurinn með því að setja mörk.
Því miður get ég ekki gefið sérstakar leiðbeiningar um hvaða gildi á að setja, en við sjálf höldum okkur við eftirfarandi reglur:
- Með því að nota álagsprófunartæki líkjum við eftir grunnstigi umferðar og fylgjumst með notkun á belgauðlindum (minni og örgjörva).
- Stilltu hólfbeiðnirnar á geðþótta lágt gildi (með auðlindamörkum um það bil 5 sinnum gildi beiðna) og fylgdu. Þegar beiðnir eru á of lágu stigi getur ferlið ekki byrjað, sem veldur oft dulrænum Go runtime villum.
Ég tek fram að hærri auðlindamörk gera tímasetningu erfiðari vegna þess að belgurinn þarf markhnút með nægu fjármagni tiltækt.
Ímyndaðu þér aðstæður þar sem þú ert með léttan vefþjón með mjög háum auðlindamörkum, eins og 4 GB af minni. Þetta ferli mun líklega þurfa að minnka lárétt, og hvern nýr belg þarf að vera tímasettur á hnút með að minnsta kosti 4 GB af lausu minni. Ef enginn slíkur hnút er til, verður þyrpingin að kynna nýjan hnút til að vinna úr þessum belg, sem getur tekið nokkurn tíma. Mikilvægt er að ná lágmarksmun á milli auðlindabeiðna og takmarkana til að tryggja hraða og hnökralausa mælikvarða.
Skref tvö: Settu upp lífleika- og viðbúnaðarpróf
Þetta er annað lúmskt efni sem oft er rætt í Kubernetes samfélaginu. Það er mikilvægt að hafa góðan skilning á líffærni- og viðbúnaðarprófum þar sem þau veita kerfi fyrir stöðuga notkun hugbúnaðarins og lágmarka niðurtíma. Hins vegar geta þau haft alvarleg áhrif á afköst forritsins þíns ef það er ekki rétt stillt. Hér að neðan er samantekt á því hvað bæði sýnin eru.
Lifandi sýnir hvort gámurinn er í gangi. Ef það mistekst drepur kubelet gáminn og endurræsingarstefnan er virkjuð fyrir það. Ef gámurinn er ekki búinn Liveness Probe, þá mun sjálfgefið ástand ná árangri - eins og fram kemur í .
Lífleikarannsakendur ættu að vera ódýrir, þ.e.a.s. eyða ekki miklu fjármagni, vegna þess að þeir keyra oft og ættu að upplýsa Kubernetes um að forritið sé í gangi.
Ef þú stillir valmöguleikann á að keyra á hverri sekúndu mun þetta bæta við 1 beiðni á sekúndu, svo hafðu í huga að viðbótarauðlindir verða nauðsynlegar til að vinna úr þessari umferð.
Hjá fyrirtækinu okkar prófa Liveness próf kjarnaþætti forrits, jafnvel þótt gögnin (til dæmis úr ytri gagnagrunni eða skyndiminni) séu ekki að fullu tiltæk.
Við höfum sett upp „heilsu“ endapunkt í forritunum sem einfaldlega skilar 200 svarkóða. Þetta er vísbending um að ferlið sé í gangi og geti meðhöndlað beiðnir (en ekki umferð ennþá).
Sýnishorn Reiðubúin gefur til kynna hvort gámurinn sé tilbúinn til að þjóna beiðnum. Ef viðbúnaðarrannsóknin mistekst fjarlægir endapunktastýringin IP-tölu hólfsins frá endapunktum allra þjónustu sem passa við hólfið. Þetta kemur einnig fram í Kubernetes skjölunum.
Viðbúnaðarrannsóknir neyta meira fjármagns, þar sem þeir verða að lenda í bakendanum á þann hátt að þeir sýni að forritið sé tilbúið til að samþykkja beiðnir.
Það er mikil umræða í samfélaginu um hvort eigi að fara beint í gagnagrunninn. Með hliðsjón af kostnaðinum (athugunin er tíð, en hægt er að stjórna þeim), ákváðum við að í sumum forritum er reiðubúinn til að þjóna umferð aðeins talinn eftir að athugað hefur verið að skrám sé skilað úr gagnagrunninum. Vel hönnuð viðbúnaðartilraunir tryggðu meira framboð og útilokuðu niður í miðbæ meðan á dreifingu stóð.
Ef þú ákveður að spyrjast fyrir um gagnagrunninn til að prófa viðbúnað umsóknarinnar þinnar, vertu viss um að hann sé eins ódýr og mögulegt er. Við skulum taka þessari fyrirspurn:
SELECT small_item FROM table LIMIT 1Hér er dæmi um hvernig við stillum þessi tvö gildi í Kubernetes:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Þú getur bætt við nokkrum viðbótarstillingarvalkostum:
initialDelaySeconds- hversu margar sekúndur munu líða frá því að gámnum er skotið á loft og þar til rannsakanirnar hefjast.periodSeconds— biðtíma milli sýnataka.timeoutSeconds— fjölda sekúndna eftir að belgurinn er talinn vera í neyðartilvikum. Venjulegur tími.failureThresholder fjöldi prófunarbilana áður en endurræsingarmerki er sent til belgsins.successThresholder fjöldi árangursríkra prófana áður en belgurinn fer yfir í tilbúið ástand (eftir bilun þegar belgurinn ræsist eða jafnar sig).
Skref þrjú: Stilla sjálfgefnar netstefnur podsins
Kubernetes er með „flata“ netkerfi, sjálfgefið hafa allir belgirnir bein samskipti sín á milli. Í sumum tilfellum er þetta ekki æskilegt.
Hugsanlegt öryggisvandamál er að árásarmaður gæti notað eitt viðkvæmt forrit til að senda umferð á alla belg á netinu. Eins og á mörgum sviðum öryggis, gildir meginreglan um minnstu forréttindi hér. Helst ættu netstefnur að taka skýrt fram hvaða tengingar milli belg eru leyfðar og hverjar ekki.
Til dæmis, eftirfarandi er einföld regla sem neitar allri komandi umferð fyrir tiltekið nafnrými:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Sýning á þessari stillingu:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Nánari upplýsingar .
Skref fjögur: Sérsniðin hegðun með krókum og Init gámum
Eitt af meginmarkmiðum okkar var að bjóða upp á dreifingu í Kubernetes án niður í miðbæ fyrir þróunaraðila. Þetta er erfitt vegna þess að það eru margir möguleikar til að slökkva á forritum og gefa út notuð auðlindir þeirra.
Sérstakir erfiðleikar komu upp með . Við tókum eftir því að þegar þessi hólf voru sett upp í röð voru virkar tengingar rofnar áður en þeim tókst að ljúka.
Eftir miklar rannsóknir á netinu kom í ljós að Kubernetes bíður ekki eftir að Nginx tengingar tæmast áður en hann slekkur á belgnum. Með hjálp forstöðvunarkróksins innleiddum við eftirfarandi virkni og losuðum okkur algjörlega við niður í miðbæ:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
En 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
Önnur einstaklega gagnleg hugmyndafræði er notkun init gáma til að sjá um ræsingu ákveðinna forrita. Þetta er sérstaklega gagnlegt ef þú ert með auðlindafrekt gagnagrunnsflutningsferli sem þarf að keyra áður en forritið byrjar. Þú getur líka tilgreint hærri auðlindamörk fyrir þetta ferli án þess að setja slík takmörk fyrir aðalforritið.
Annað algengt kerfi er að fá aðgang að leyndarmálum í init gámnum, sem veitir þessi skilríki til aðaleiningarinnar, sem kemur í veg fyrir óviðkomandi aðgang að leyndarmálum frá aðalforritseiningunni sjálfri.
Eins og venjulega, tilvitnun í skjölin: init gámar keyra á öruggan hátt notendakóða eða tól sem annars myndu skerða öryggi gámamyndar forritsins. Með því að halda óþarfa verkfærum aðskildum takmarkarðu árásaryfirborð gámamyndar forritsins.
Skref fimm: Kjarnastilling
Að lokum skulum við tala um fullkomnari tækni.
Kubernetes er afar sveigjanlegur vettvangur sem gerir þér kleift að keyra vinnuálag eins og þér sýnist. Við höfum fjölda mjög skilvirkra forrita sem eru afar auðlindafrek. Eftir að hafa gert víðtækar álagsprófanir komumst við að því að eitt af forritunum átti erfitt með að halda í við væntanlegt umferðarálag þegar sjálfgefnar Kubernetes stillingar voru í gildi.
Hins vegar, Kubernetes gerir þér kleift að keyra forréttindaílát sem breytir aðeins kjarnabreytum fyrir tiltekið hólf. Hér er það sem við notuðum til að breyta hámarksfjölda opinna tenginga:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Þetta er fullkomnari tækni sem oft er ekki þörf á. En ef forritið þitt á í erfiðleikum með að takast á við mikið álag geturðu reynt að fínstilla nokkrar af þessum stillingum. Frekari upplýsingar um þetta ferli og að setja mismunandi gildi - eins og alltaf .
Að lokum
Þó að Kubernetes kunni að virðast vera út-af-the-box lausn, þá eru nokkur lykilskref sem þarf að taka til að halda forritum í gangi vel.
Í gegnum flutninginn til Kubernetes er mikilvægt að fylgja „álagsprófunarlotunni“: keyra forritið, prófa það undir álagi, fylgjast með mælingum og kvarðahegðun, stilla uppsetninguna út frá þessum gögnum og endurtaka síðan þessa lotu aftur.
Vertu raunsær varðandi væntanlega umferð og reyndu að fara út fyrir hana til að sjá hvaða íhlutir brotna fyrst. Með þessari endurteknu nálgun gætu aðeins nokkrar af tilmælunum sem eru taldar upp nægja til að ná árangri. Eða getur þurft ítarlegri aðlögun.
Spyrðu sjálfan þig alltaf þessara spurninga:
- Hversu margar auðlindir nota forrit og hvernig mun þetta magn breytast?
- Hverjar eru raunverulegar stærðarkröfur? Hversu mikla umferð mun forritið sjá um að meðaltali? Hvað með hámarks umferð?
- Hversu oft þarf að minnka þjónustuna? Hversu hratt þurfa nýir belgjur að vera í gangi til að taka á móti umferð?
- Hversu þokkafullt lokast belg? Er það yfirleitt nauðsynlegt? Er hægt að ná uppsetningu án niður í miðbæ?
- Hvernig á að lágmarka öryggisáhættu og takmarka skemmdir af völdum belgjum sem eru í hættu? Hefur einhver þjónusta heimildir eða aðgang sem hún þarfnast ekki?
Kubernetes býður upp á ótrúlegan vettvang sem gerir þér kleift að nota bestu starfsvenjur til að dreifa þúsundum þjónustu í þyrping. Hins vegar eru öll forrit mismunandi. Stundum krefst innleiðingin aðeins meiri vinnu.
Sem betur fer veitir Kubernetes nauðsynlegar stillingar til að ná öllum tæknilegum markmiðum. Með því að nota blöndu af auðlindabeiðnum og takmörkunum, Liveness og Readiness rannsaka, init gáma, netstefnur og sérsniðna kjarnastillingu, geturðu náð miklum afköstum ásamt bilanaþoli og hröðum sveigjanleika.
Hvað annað að lesa:
- .
- .
- .
Heimild: www.habr.com