🥇Hvernig á að fá aðgang að Kubernetes Pod auðlindum

Verðlaunin eftir Tohad

Þegar byrjað er með Kubernetes er algengt að gleyma því að setja upp gámaauðlindir. Á þessum tímapunkti er nóg til að tryggja að Docker myndin virki og hægt sé að dreifa henni á Kubernetes klasann.

En síðar þarf að dreifa forritinu í framleiðsluklasa ásamt öðrum forritum. Til að gera þetta þarftu að úthluta tilföngum fyrir ílátið og ganga úr skugga um að það sé nóg af þeim til að koma forritinu í gang og að önnur keyrandi forrit muni ekki lenda í vandræðum.

Team Kubernetes aaS frá Mail.ru þýddi grein um gámaauðlindir (CPU & MEM), beiðnir og auðlindatakmarkanir. Þú munt læra kosti þessara stillinga og hvað gerist ef þú stillir þær ekki.

Tölvuauðlindir

Við höfum tvær tegundir af auðlindum með eftirfarandi einingum:

Miðvinnslueining (CPU) - kjarna;
Minni (MEM) - bæti.

Tilföng eru tilgreind fyrir hvern gám. Í eftirfarandi Pod YAML skrá muntu sjá auðlindahluta sem inniheldur umbeðnar og takmarkaðar auðlindir:

Requested Pod Resources = summa af umbeðnum tilföngum allra gáma;
Pod Resource Limit = Summa af öllum Pod Resource Limit.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

Dæmi um umbeðin og takmörkuð auðlind

Field resources.requested frá forskriftinni Pod er einn af þáttunum sem eru notaðir til að finna hnútinn sem óskað er eftir. Þú getur nú þegar skipulagt pod dreifingu fyrir það. Hvernig finnurðu viðeigandi hnút?

Kubernetes samanstendur af nokkrum hlutum, þar á meðal aðalhnút eða aðalhnút (Kubernetes Control Plane). Aðalhnúturinn hefur nokkra ferla: kube-apiserver, kube-controller-manager og kube-scheduler.

Kube-áætlunarferlið er ábyrgt fyrir því að endurskoða nýstofnaða belg og finna mögulega starfshnúta sem passa við allar hólfbeiðnir, þar á meðal fjölda tilfanga sem óskað er eftir. Listi yfir hnúta sem kube-scheduler hefur fundið er raðað. Flokkurinn er áætlaður á hnútnum með hæstu stigin.

Hvar verður fjólublái belgurinn settur?

Á myndinni má sjá að kube-scheduler ætti að skipuleggja nýjan fjólubláan Pod. Kubernetes þyrpingin inniheldur tvo hnúta: A og B. Eins og þú sérð getur kube-scheduler ekki tímasett Pod á hnút A - tiltæk (óumbeðin) tilföng passa ekki við beiðnir fjólubláa Podsins. Þannig að 1 GB af minni sem fjólublái Pod biður um mun ekki passa á hnút A, þar sem tiltækt minni er 0,5 GB. En hnútur B hefur nóg fjármagn. Fyrir vikið ákveður kube-scheduler að áfangastaður fjólubláa podsins sé hnútur B.

Nú vitum við hvernig umbeðin úrræði hafa áhrif á val á hnút til að keyra Pod. En hver eru áhrif jaðarauðlinda?

Auðlindamörkin eru mörk sem CPU/MEM getur ekki farið yfir. Hins vegar er CPU auðlindin sveigjanleg, þannig að gámar sem ná CPU takmörkunum munu ekki valda því að Pod hættir. Í staðinn mun inngjöf örgjörva hefjast. Ef MEM notkunarmörkum er náð verður gámurinn stöðvaður vegna OOM-Killer og endurræstur ef RestartPolicy stillingin leyfir það.

Umbeðið og hámarksúrræði í smáatriðum

Auðlindasamskipti milli Docker og Kubernetes

Besta leiðin til að útskýra hvernig auðlindabeiðnir og auðlindatakmarkanir virka er að kynna tengsl Kubernetes og Docker. Á myndinni hér að ofan geturðu séð hvernig Kubernetes reitirnir og Docker ræsingarfánarnir tengjast.

Minni: beiðni og takmörkun

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Eins og getið er hér að ofan er minni mælt í bætum. Byggt á Kubernetes skjöl, við getum tilgreint minni sem tölu. Venjulega er það heil tala, til dæmis 2678 - það er 2678 bæti. Þú getur líka notað viðskeyti G и Gi, aðalatriðið er að muna að þeir eru ekki jafngildir. Sá fyrsti er aukastafur og sá seinni er tvöfaldur. Eins og dæmið sem nefnt er í k8s skjölunum: 128974848, 129e6, 129M, 123Mi - þau eru nánast jafngild.

Kubernetes valkostur limits.memory passar við fánann --memory frá Docker. Ef um er að ræða request.memory Það er engin ör fyrir Docker vegna þess að Docker notar ekki þennan reit. Þú gætir spurt, er þetta jafnvel nauðsynlegt? Já þarf. Eins og ég sagði áður skiptir völlurinn máli fyrir Kubernetes. Byggt á upplýsingum frá því, ákveður kube-scheduler hvaða hnút á að tímasetja Pod.

Hvað gerist ef þú stillir ófullnægjandi minni fyrir beiðni?

Ef gámurinn hefur náð mörkum umbeðs minnis, þá er Pod settur í hóp Pods sem stoppa þegar ekki er nóg minni í hnútnum.

Hvað gerist ef þú stillir minnismörkin of lág?

Ef gámurinn fer yfir minnismörkin verður honum hætt vegna OOM-Killed. Og mun endurræsa ef mögulegt er byggt á RestartPolicy þar sem sjálfgefið gildi er Always.

Hvað gerist ef þú tilgreinir ekki umbeðið minni?

Kubernetes mun taka viðmiðunarmörkin og setja það sem sjálfgefið gildi.

Hvað getur gerst ef þú tilgreinir ekki minnistakmörk?

Ílátið hefur engar takmarkanir; það getur notað eins mikið minni og það vill. Ef hann byrjar að nota allt tiltækt minni hnútsins mun OOM drepa hann. Gámurinn verður síðan endurræstur ef mögulegt er byggt á RestartPolicy.

Hvað gerist ef þú tilgreinir ekki minnismörk?

Þetta er í versta falli: tímaáætlunarmaðurinn veit ekki hversu mörg tilföng gámurinn þarfnast og þetta getur valdið alvarlegum vandamálum á hnútnum. Í þessu tilfelli væri gaman að hafa sjálfgefna takmörk á nafnrýminu (sett af LimitRange). Það eru engin sjálfgefin takmörk - Podinn hefur engin takmörk, hann getur notað eins mikið minni og hann vill.

Ef umbeðið minni er meira en hnúturinn getur boðið upp á, verður Pod ekki tímasettur. Það er mikilvægt að muna það Requests.memory - ekki lágmarksgildi. Þetta er lýsing á því minni sem nægir til að halda ílátinu í gangi stöðugt.

Venjulega er mælt með því að stilla sama gildi fyrir request.memory и limit.memory. Þetta tryggir að Kubernetes mun ekki tímasetja Pod á hnút sem hefur nóg minni til að keyra Pod en ekki nóg til að keyra hann. Hafðu í huga: Kubernetes Pod skipulagning tekur aðeins tillit til requests.memoryOg limits.memory tekur ekki tillit til.

CPU: beiðni og takmörk

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

Með CPU er allt aðeins flóknara. Þegar þú ferð aftur að myndinni af sambandi Kubernetes og Docker geturðu séð það request.cpu соответствует --cpu-shares, en limit.cpu passar við fánann cpus í Docker.

Örgjörvinn sem Kubernetes biður um er margfaldaður með 1024, hlutfalli örgjörvalota. Ef þú vilt biðja um 1 heilan kjarna verður þú að bæta við cpu: 1eins og sýnt er hér að ofan.

Að biðja um fullan kjarna (hlutfall = 1024) þýðir ekki að ílátið þitt muni fá hann. Ef gestgjafi vélin þín hefur aðeins einn kjarna og þú ert að keyra fleiri en einn gám, þá verða allir gámar að deila tiltækum örgjörva á milli sín. Hvernig gerist þetta? Við skulum skoða myndina.

CPU beiðni - Einkjarna kerfi

Við skulum ímynda okkur að þú sért með einskjarna hýsingarkerfi sem keyrir ílát. Mamma (Kubernetes) bakaði böku (CPU) og vill skipta henni á milli barna (íláta). Þrjú börn vilja heila tertu (hlutfall = 1024), annað barn vill hálfa tertu (512). Mamma vill vera sanngjörn og gerir einfaldan útreikning.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

Miðað við útreikninginn fá þrjú börn 28% af kjarnanum en ekki allan kjarnann. Fjórða barnið fær 14% af fullum kjarna, ekki helming. En hlutirnir verða öðruvísi ef þú ert með fjölkjarna kerfi.

CPU beiðni - Fjölkjarna (4) kerfi

Á myndinni hér að ofan má sjá að þrjú börn vilja heila tertu og eitt vill hálfa. Þar sem mamma bakaði fjórar bökur fær hvert barn hennar eins margar og þau vilja. Í fjölkjarna kerfi er örgjörvaauðlindum dreift yfir alla tiltæka örgjörvakjarna. Ef ílát er takmarkað við minna en einn fullan CPU kjarna getur hann samt notað hann 100%.

Ofangreindar útreikningar eru einfaldaðir til að skilja hvernig CPU dreifist á ílát. Auðvitað, fyrir utan gámana sjálfa, eru aðrir ferlar sem nota einnig CPU auðlindir. Þegar ferlar í einum gámi eru aðgerðalausir geta aðrir notað tilföng þess. CPU: "200m" соответствует CPU: 0,2, sem þýðir um það bil 20% af einum kjarna.

Nú skulum við tala um limit.cpu. Örgjörvinn sem Kubernetes takmarkar er margfaldaður með 100. Niðurstaðan er sá tími sem ílátið getur notað á 100 µs fresti (cpu-period).

limit.cpu passar við Docker fána --cpus. Þetta er ný samsetning af gömlu --cpu-period и --cpu-quota. Með því að stilla það tilgreinum við hversu mörg tiltæk örgjörvaforða gámurinn getur notað að hámarki áður en inngjöf hefst:

örgjörvi - samsetning cpu-period и cpu-quota. cpus = 1.5 jafngildir stillingu cpu-period = 100000 и cpu-quota = 150000;
CPU-tímabil - tímabil CPU CFS tímaáætlun, sjálfgefið 100 míkrósekúndur;
örgjörva-kvóti - fjöldi míkrósekúndna inni cpu-period, sem afmarkast af gámnum.

Hvað gerist ef þú setur upp ófullnægjandi örgjörva?

Ef ílátið þarf meira en það hefur sett upp mun það stela CPU frá öðrum ferlum.

Hvað gerist ef þú stillir CPU mörkin of lág?

Þar sem CPU auðlindin er stillanleg mun inngjöf kveikja á.

Hvað gerist ef þú tilgreinir ekki CPU beiðni?

Eins og með minni er beiðnigildið jafnt við mörkin.

Hvað gerist ef þú tilgreinir ekki CPU takmörk?

Gámurinn mun nota eins mikinn CPU og hann þarf. Ef sjálfgefin CPU stefna (LimitRange) er skilgreind í nafnrýminu, þá er þessi takmörk einnig notuð fyrir ílátið.

Hvað gerist ef þú tilgreinir hvorki beiðni né CPU takmörk?

Eins og með minni er þetta versta tilvikið. Tímaáætlunin veit ekki hversu mörg auðlindir gámurinn þinn þarfnast og þetta getur valdið alvarlegum vandamálum á hnútnum. Til að forðast þetta þarftu að setja sjálfgefna takmörk fyrir nafnrými (LimitRange).

Mundu: ef þú biður um meiri örgjörva en hnútarnir geta veitt, verður Pod ekki tímasettur. Requests.cpu - ekki lágmarksgildi, heldur gildi sem nægir til að ræsa Pod og vinna án bilana. Ef forritið framkvæmir ekki flókna útreikninga er besti kosturinn að setja upp request.cpu <= 1 og ræstu eins margar eftirmyndir og þarf.

Tilvalið magn af umbeðnum auðlindum eða auðlindamörkum

Við lærðum um takmörkun tölvuauðlinda. Nú er kominn tími til að svara spurningunni: „Hversu mörg úrræði þarf Pod minn til að keyra forritið án vandræða? Hver er kjör upphæð?

Því miður eru engin skýr svör við þessum spurningum. Ef þú veist ekki hvernig forritið þitt virkar eða hversu mikinn örgjörva eða minni það þarf, þá er besti kosturinn að gefa forritinu mikið af minni og örgjörva og keyra síðan árangurspróf.

Auk árangursprófa skaltu fylgjast með hegðun forritsins við eftirlit í viku. Ef línuritin gefa til kynna að forritið þitt eyði minna fjármagni en þú baðst um geturðu dregið úr magni örgjörva eða minnis sem óskað er eftir.

Sjáið þetta sem dæmi Grafana mælaborð. Það sýnir muninn á umbeðnum auðlindum eða auðlindamörkum og núverandi auðlindanotkun.

Ályktun

Að biðja um og takmarka auðlindir hjálpar til við að halda Kubernetes klasanum þínum heilbrigðum. Rétt uppsetning takmarka lágmarkar kostnað og heldur forritum í gangi alltaf.

Í stuttu máli eru nokkur atriði sem þarf að hafa í huga:

Umbeðin tilföng eru stillingar sem tekið er tillit til við ræsingu (þegar Kubernetes ætlar að hýsa forritið). Aftur á móti er takmörkun á tilföngum mikilvægt á keyrslutíma - þegar forritið er þegar í gangi á hnútnum.
Í samanburði við minni er örgjörvinn stjórnað auðlind. Ef það er ekki nægur örgjörvi, mun Pod þinn ekki slökkva á sér og inngjöfin mun kveikja á.
Umbeðin auðlindir og auðlindamörk eru ekki lágmarks- og hámarksgildi! Með því að skilgreina tilföngin sem óskað er eftir tryggirðu að forritið gangi án vandræða.
Góð venja er að stilla minnisbeiðnina jafnt minnistakmörkunum.
Ok uppsetning óskað CPU <=1, ef forritið framkvæmir ekki flókna útreikninga.
Ef þú biður um fleiri tilföng en eru tiltæk á hnút, verður Pod aldrei tímasettur á þann hnút.
Til að ákvarða rétt magn af umbeðnum tilföngum/auðlindamörkum, notaðu álagsprófun og vöktun.

Ég vona að þessi grein hjálpi þér að skilja grunnhugtakið um takmörkun auðlinda. Og þú munt geta beitt þessari þekkingu í starfi þínu.

Good Luck!

Hvað annað að lesa:

Heimild: www.habr.com

Hvernig á að fá aðgang að Kubernetes Pod auðlindum