Kubernetesega alustades unustatakse tavaliselt konteineriressursside seadistamine. Siinkohal piisab, kui veenduda, et Dockeri pilt töötab ja seda saab Kubernetese klastris juurutada.
Kuid hiljem tuleb rakendus juurutada tootmisklastris koos teiste rakendustega. Selleks tuleb konteinerile eraldada ressursid ja veenduda, et neid oleks piisavalt, et rakendus saaks tööle panna ning teistel töötavatel rakendustel probleeme ei tekiks.
Meeskond tõlkis artikli konteineriressursside (CPU ja MEM), taotluste ja ressursside piirangute kohta. Saate teada nende seadete eelistest ja sellest, mis juhtub, kui te neid ei määra.
Arvutusressursid
Meil on kahte tüüpi ressursse järgmiste üksustega:
- Keskprotsessor (CPU) - südamikud;
- Mälu (MEM) - baidid.
Ressursid on määratud iga konteineri jaoks. Järgmises Pod YAML-failis näete ressursside jaotist, mis sisaldab nõutud ja piiratud ressursse:
- Requested Pod Resources = kõigi konteinerite nõutud ressursside summa;
- Podi ressursi limiit = kõigi Podi ressursipiirangute summa.
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: 1GiTaotletud ja piiratud ressursside näide
Väli resources.requested spetsifikatsioonist Pod on üks elementidest, mida kasutatakse soovitud sõlme leidmiseks. Saate selle jaoks juba Podi juurutamist planeerida. Kuidas leida sobiv sõlm?
Kubernetes koosneb mitmest komponendist, sealhulgas põhisõlmest või põhisõlmest (Kubernetes Control Plane). Põhisõlmel on mitu protsessi: kube-apiserver, kube-kontroller-haldur ja kube-planeerija.
Kube-planeerija protsess vastutab äsja loodud kaustade ülevaatamise ja võimalike töötajate sõlmede leidmise eest, mis vastavad kõigile podipäringutele, sealhulgas taotletud ressursside arvule. Kube-scheduleri leitud sõlmede loend on järjestatud. Pod on ajastatud kõrgeimate punktisummadega sõlmele.
Kuhu lilla kaun paigutatakse?
Pildil on näha, et kube-scheduler peaks planeerima uue lilla Podi. Kubernetese klaster sisaldab kahte sõlme: A ja B. Nagu näete, ei saa kube-planeerija ajastada Podi sõlmele A – saadaolevad (taotlemata) ressursid ei ühti lilla Podi taotlustega. Nii et lilla Podi nõutud 1 GB mälu ei mahu sõlme A, kuna saadaolevat mälu on 0,5 GB. Kuid sõlmel B on piisavalt ressursse. Selle tulemusena otsustab kube-planeerija, et lilla Podi sihtkoht on sõlm B.
Nüüd teame, kuidas taotletud ressursid mõjutavad Podi käitamiseks sõlme valikut. Aga milline on marginaalsete ressursside mõju?
Ressursipiirang on piir, mida CPU/MEM ei saa ületada. Protsessori ressurss on siiski paindlik, nii et konteinerid, mis jõuavad oma CPU piiranguteni, ei põhjusta Podi väljumist. Selle asemel algab protsessori drossel. Kui MEM-i kasutuslimiit on saavutatud, peatatakse konteiner OOM-Killeri tõttu ja taaskäivitatakse, kui RestartPolicy säte seda võimaldab.
Nõutud ja maksimaalsed ressursid üksikasjalikult
Dockeri ja Kubernetese vaheline ressursside suhtlus
Parim viis ressursitaotluste ja ressursipiirangute toimimise selgitamiseks on tutvustada Kubernetese ja Dockeri vahelisi suhteid. Ülaltoodud pildil näete, kuidas Kubernetese väljad ja Dockeri käivituslipud on seotud.
Mälu: taotlus ja piirang
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Nagu eespool mainitud, mõõdetakse mälu baitides. Põhineb , saame määrata mälu numbrina. Tavaliselt on see täisarv, näiteks 2678 - see tähendab 2678 baiti. Võite kasutada ka järelliiteid G и Gi, peamine on meeles pidada, et need ei ole samaväärsed. Esimene on kümnend ja teine binaarne. Nagu k8s dokumentatsioonis mainitud näide: 128974848, 129e6, 129M, 123Mi - need on praktiliselt samaväärsed.
Kubernetese valik limits.memory sobib lipuga --memory Dockerilt. Juhul kui request.memory Dockeri jaoks noolt pole, kuna Docker seda välja ei kasuta. Võite küsida, kas see on üldse vajalik? Jah vaja. Nagu ma varem ütlesin, on valdkond Kubernetese jaoks oluline. Sellest saadud teabe põhjal otsustab kube-planeerija, milline sõlm Podi ajastada.
Mis juhtub, kui määrate päringu jaoks ebapiisava mälumahu?
Kui konteiner on jõudnud nõutud mälu piirini, paigutatakse Pod Podide rühma, mis peatuvad, kui sõlmes pole piisavalt mälu.
Mis juhtub, kui seate mälupiirangu liiga madalaks?
Kui konteiner ületab mälupiirangu, suletakse see OOM-Killed tõttu. Ja taaskäivitub võimalusel RestartPolicy alusel, kus on vaikeväärtus Always.
Mis juhtub, kui te ei määra soovitud mälu?
Kubernetes võtab piirväärtuse ja määrab selle vaikeväärtuseks.
Mis võib juhtuda, kui te mälupiirangut ei määra?
Konteineril pole piiranguid; see võib kasutada nii palju mälu kui soovib. Kui ta hakkab kasutama kogu sõlme saadaolevat mälu, tapab OOM ta. Seejärel taaskäivitatakse konteiner, kui see on RestartPolicy alusel võimalik.
Mis juhtub, kui te mälupiiranguid ei määra?
See on halvim stsenaarium: planeerija ei tea, kui palju ressursse konteiner nõuab, ja see võib sõlmes tõsiseid probleeme tekitada. Sel juhul oleks tore, kui nimeruumile oleks vaikepiirangud (määratud LimitRange'i poolt). Vaikimisi piiranguid pole – Podil pole piiranguid, see võib kasutada nii palju mälu kui tahab.
Kui nõutud mälu on rohkem, kui sõlm suudab pakkuda, siis Podit ei planeerita. Oluline on seda meeles pidada Requests.memory - mitte miinimumväärtus. See kirjeldab mälumahtu, mis on piisav konteineri pidevaks töötamiseks.
Tavaliselt on soovitatav määrata sama väärtus request.memory и limit.memory. See tagab, et Kubernetes ei planeeri Podit sõlmes, millel on Podi käitamiseks piisavalt mälu, kuid mitte piisavalt selle käitamiseks. Pidage meeles: Kubernetes Podi planeerimine võtab arvesse ainult requests.memoryJa limits.memory ei arvesta.
CPU: taotlus ja piirang
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Protsessori puhul on kõik veidi keerulisem. Naastes Kubernetese ja Dockeri suhete pildi juurde, näete seda request.cpu vastab --cpu-shares, arvestades, et limit.cpu sobib lipuga cpus Dockeris.
CPU, mida Kubernetes taotleb, korrutatakse 1024-ga, protsessori tsüklite osakaaluga. Kui soovite taotleda 1 täistuuma, peate lisama cpu: 1nagu ülal näidatud.
Täieliku tuuma taotlemine (proportsioon = 1024) ei tähenda, et teie konteiner selle vastu võtab. Kui teie hostmasinal on ainult üks tuum ja te kasutate rohkem kui ühte konteinerit, peavad kõik konteinerid jagama nende vahel saadaolevat protsessorit. Kuidas see juhtub? Vaatame pilti.
Protsessori taotlus – ühetuumaline süsteem
Kujutagem ette, et teil on ühetuumaline hostsüsteem, mis käitab konteinereid. Ema (Kubernetes) küpsetas piruka (CPU) ja tahab selle laste vahel ära jagada (konteinerid). Kolm last tahavad tervet pirukat (proportsioon = 1024), teine laps poolikut pirukat (512). Ema tahab olla õiglane ja teeb lihtsa arvutuse.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Arvutuse põhjal saavad kolm last 28% tuumikust, mitte aga kogu tuum. Neljas laps saab 14% täistuumast, mitte poole. Kuid asjad on teisiti, kui teil on mitmetuumaline süsteem.
Protsessori taotlus – mitmetuumaline (4) süsteem
Ülaltoodud pildil näete, et kolm last tahavad tervet pirukat ja üks pool. Kuna ema küpsetas neli pirukat, saab iga tema laps nii palju, kui tahab. Mitmetuumalises süsteemis jaotatakse protsessoriressursid kõigi saadaolevate protsessorituumade vahel. Kui konteineris on vähem kui üks täis protsessorituum, saab see seda siiski 100% kasutada.
Ülaltoodud arvutusi on lihtsustatud, et mõista, kuidas CPU konteinerite vahel jaotatakse. Muidugi on peale konteinerite endi ka teisi protsesse, mis kasutavad CPU ressursse. Kui ühes konteineris olevad protsessid on jõude, saavad teised selle ressurssi kasutada. CPU: "200m" vastab CPU: 0,2, mis tähendab ligikaudu 20% ühest tuumast.
Nüüd räägime sellest limit.cpu. CPU, mida Kubernetes piirab, korrutatakse 100-ga. Tulemuseks on aeg, mida konteiner saab kasutada iga 100 µs järel (cpu-period).
limit.cpu sobib Dockeri lipuga --cpus. See on uus kombinatsioon vanast --cpu-period и --cpu-quota. Selle seadistamisel näitame, kui palju saadaolevaid protsessori ressursse mahuti saab maksimaalselt kasutada, enne kui drosselit alustatakse:
- cpus - kombinatsioon
cpu-periodиcpu-quota. cpus = 1.5võrdväärne seadistusegacpu-period = 100000иcpu-quota = 150000; - CPU-periood - periood , vaikimisi 100 mikrosekundit;
- cpu-kvoot - mikrosekundite arv sees
cpu-period, mis on piiratud konteineriga.
Mis juhtub, kui installite ebapiisavalt nõutud protsessori?
Kui konteiner vajab rohkem, kui see on installitud, varastab see protsessori teistelt protsessidelt.
Mis juhtub, kui seate CPU limiidi liiga madalaks?
Kuna protsessori ressurss on reguleeritav, lülitub drossel sisse.
Mis juhtub, kui te CPU päringut ei määra?
Nagu mälu puhul, on päringu väärtus võrdne limiidiga.
Mis juhtub, kui te CPU limiiti ei määra?
Konteiner kasutab nii palju protsessorit kui vaja. Kui nimeruumis on määratletud CPU vaikepoliitika (LimitRange), kasutatakse seda piirangut ka konteineri jaoks.
Mis juhtub, kui te ei määra päringut ega protsessori limiiti?
Nagu mälu puhul, on see halvim stsenaarium. Planeerija ei tea, kui palju ressursse teie konteiner vajab, ja see võib sõlmes tõsiseid probleeme põhjustada. Selle vältimiseks peate määrama nimeruumidele vaikepiirangud (LimitRange).
Pidage meeles: kui taotlete rohkem protsessorit, kui sõlmed suudavad pakkuda, siis Podit ei ajastata. Requests.cpu - mitte miinimumväärtus, vaid väärtus, mis on piisav Podi käivitamiseks ja tõrgeteta töötamiseks. Kui rakendus ei teosta keerulisi arvutusi, on parim võimalus installida request.cpu <= 1 ja käivitage nii palju koopiaid kui vaja.
Ideaalne nõutud ressursside kogus või ressursilimiit
Saime teada arvutusressursside piiratusest. Nüüd on aeg vastata küsimusele: "Kui palju ressursse vajab minu Pod, et rakendust probleemideta käivitada? Mis on ideaalne summa?
Kahjuks pole neile küsimustele selgeid vastuseid. Kui te ei tea, kuidas teie rakendus töötab või kui palju protsessorit või mälu see vajab, on parim valik anda rakendusele palju mälu ja protsessorit ning seejärel käivitada jõudlustestid.
Lisaks jõudlustestidele jälgige nädala jooksul rakenduse käitumist monitooringus. Kui graafikud näitavad, et teie rakendus tarbib vähem ressursse, kui taotlesite, saate vähendada nõutava protsessori või mälu mahtu.
Näitena vaadake seda . See kuvab erinevuse taotletud ressursside või ressursipiirangu ja praeguse ressursikasutuse vahel.
Järeldus
Ressursside taotlemine ja piiramine aitab hoida teie Kubernetese klastri tervena. Õige piirangu konfigureerimine minimeerib kulusid ja hoiab rakendused pidevalt töös.
Lühidalt, on mõned asjad, mida meeles pidada:
- Taotletud ressursid on konfiguratsioon, mida võetakse arvesse käivitamisel (kui Kubernetes plaanib rakendust majutada). Seevastu ressursside piiramine on oluline käitusajal – kui rakendus sõlmes juba töötab.
- Võrreldes mäluga on protsessor reguleeritud ressurss. Kui protsessorit pole piisavalt, ei lülitu teie Pod välja ja drosselmehhanism lülitub sisse.
- Soovitud ressursid ja ressursi limiit ei ole miinimum- ja maksimumväärtused! Nõutavate ressursside määratlemisega tagate, et rakendus töötab probleemideta.
- Hea tava on seada mälupäring võrdseks mälupiiranguga.
- Nõutud on OK installimine
CPU <=1, kui rakendus ei teosta keerulisi arvutusi. - Kui taotlete rohkem ressursse, kui sõlmes saadaval on, ei planeerita Podi kunagi sellesse sõlme.
- Nõutud ressursside/ressursipiirangute õige hulga määramiseks kasutage koormustestimist ja jälgimist.
Loodan, et see artikkel aitab teil mõista ressursside piiramise põhikontseptsiooni. Ja saate neid teadmisi oma töös rakendada.
Õnn kaasa!
Mida veel lugeda:
- .
- .
- .
Allikas: www.habr.com