Kubernetes'iga alustades unustatakse tavaliselt konteinerite ressursi seadistamine. Sel etapil piisab, kui veenduda, et Docker'i pilt töötab ja seda saab Kubernetes'i klastris juurutada.
Kuid hiljem tuleb rakendus juurutada tootmisklastrisse koos teiste rakendustega. Selleks tuleb konteinerile ressursid eraldada ja veenduda, et neid on piisavalt rakenduse käivitamiseks ja töötamiseks, ning et teistes käivitatud rakendustes ei tekiks probleeme.
Meeskond tõlkis artikli konteinerite ressurssidest (CPU & MEM), ressursside nõudmistest ja piirangutest. Saate teada, millised eelised annavad need seadistused ja mis juhtub, kui neid ei seadistata.
Arvutusressursid
Meil on kaks tüüpi ressursse järgmiste ühikutega:
- Keskmine protsessor (CPU) — südamikud;
- Mälu (MEM) — baitid.
Ressursid määratakse iga konteineri jaoks. Järgmises YAML-failis Pod näete ressurside jaotust, mis sisaldab nõutud ja piiratud ressursse:
- Nõutud ressursid Pod = kõigi konteinerite nõutud ressursside summa;
- Piiratud ressursid Pod = kõigi konteinerite piiratud ressursside 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 # KÜSITUD CPU: 200m tuuma
memory: "1Gi" # KÜSITUD MEM: 1Gi
limits:
cpu: 1 # MAX CPU KASUTUS: 1 tuum
memory: "1Gi" # MAX MEM KASUTUS: 1Gi
- name: other-container
image: other-app
tag: v1
ports:
- containerPort: 8000
resources:
requests:
cpu: "200m" # KÜSITUD CPU: 200m tuuma
memory: "0.5Gi" # KÜSITUD MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU KASUTUS: 1 tuum
memory: "1Gi" # MAX MEM KASUTUS: 1GiPalutud ja piiritletud ressurside näide
Väli resources.requested Pod-spetsiifikast — üks elemente, mida kasutatakse õige sõlme otsimiseks. Sellele saab juba planeerida Pod'i juurutamise. Kuidas aga sobivat sõlme otsitakse?
Kubernetes koosneb mitmest komponendist, sealhulgas sisaldab peamist sõlme ehk master-sõlme (Kubernetes Control Plane). Master-sõlmes on mitmeid protsesse: kube-apiserver, kube-controller-manager ja kube-scheduler.
Kube-scheduleri protsess vastutab uute moodulite jälgimise ja sobivate töönode otsimise eest, mis vastavad kõikidele moodulite nõudmistele, sealhulgas nõutud ressursside hulgale. Kube-scheduleri leitud node'id on järjekorda pandud. Pod planeeritakse node'ile, millel on kõige kõrgemad punktid.
Kuhu paigutatakse lilla Pod?
Pildilt on näha, et kube-scheduler peab planeerima uue lillakase Pod'i. Kubernetes'i klaster sisaldab kahte node'i: A ja B. Nagu võib märgata, ei saa kube-scheduler planeerida Pod'i node'ile A — saadaolevad (mitte nõutud) ressursid ei vasta lilla Pod'i nõudmistele. Nii, lilla Pod'i nõutav 1 GB mälu ei mahuks node'ile A, kuna saadaolev mälu on 0,5 GB. Kuid node'il B on piisavalt ressursse. Lõppkokkuvõttes otsustab kube-scheduler, et lilla Pod'i sihtkoht on node B.
Nüüd teame, kuidas nõutud ressursid mõjutavad node'i valikut Pod'i käivitamiseks. Aga kuidas mõjutavad piiriressursid?
Ressursside piirangud on piir, mida CPU/MEM ei saa ületada. Siiski on CPU ressurss paindlik, seega konteinerid, mis on saavutanud CPU piirväärtused, ei põhjusta Pod'i seiskumist. Selle asemel käivitub CPU talitluspiirang. Kui aga saavutatakse MEM kasutamise piir, siis konteiner peatatakse OOM-Killer'i tõttu ja taaskäivitatakse, kui see on RestartPolicy seadistusega lubatud.
Küsitud ja piiratud ressursid detailides
Ressursside seos Docker'i ja Kubernetes'e vahel
Parim viis selgitada, kuidas küsitud ja piiratud ressursid töötavad, on näha seost Kubernetes'e ja Docker'i vahel. Ülaltoodud joonisel näete, kuidas on seotud Kubernetes'e väljad ja Docker'i käivitamislipikud.
Mälu: küsimine ja piirang
konteinerid:
...
ressursid:
küsitud:
mälu: "0.5Gi"
piirangud:
mälu: "1Gi"
Nagu eelpool mainitud, mõõdetakse mälu baitides. Tuginedes , saame mälu määrata numbrina. Tavaline on, et see on täisarv, näiteks 2678 — see tähendab 2678 baiti. Samuti saab kasutada sufikseid G ja Gi, oluline on meeles pidada, et need ei ole samaväärsed. Esimene on kümnendi, teine aga binaarsüsteemi. Näiteks k8s dokumentatsioonis mainitud: 128974848, 129e6, 129M, 123Mi — need on praktiliselt ekvivalentsed.
Kubernetesi parameeter limits.memory vastab lipule --memory Dockerist. Kui request.memory näidik Dockerile puudub, kuna Docker ei kasuta seda välja. Kas on mõtet seda üldse küsida? Jah, on. Nagu ma juba mainisin, on välja jaoks Kubernetesel oluline. Selle teabe põhjal otsustab kube-scheduler, millisele sõlmele Planeerida Pod.
Mis juhtub, kui määrate päringule liiga vähe mälu?
Kui konteiner saavutab küsitud mälu piirid, paigutatakse Pod gruppi Podide hulgast, mis peatatakse, kui nodis on mälu puudus.
Mis juhtub, kui määrate liiga väikese mälu piiri?
Kui konteiner ületab mälu piiri, lõpetatakse see OOM-Killed'i tõttu. Ja see taaskäivitub, kui see on võimalik RestartPolicy alusel, kus vaikimisi väärtus on Always.
Mis juhtub, kui nõutavat mälu ei näidata?
Kubernetes võtab piiri väärtuse ja seab selle vaikimisi väärtuseks.
Mis võib juhtuda, kui piiravat mälu ei näidata?
Konteineril pole piiranguid, ta võib kasutada nii palju mälu, kui soovib. Kui ta aga hakkab kasutama kogu sõlme olemasolevat mälu, tapab ta OOM. Seejärel ta taaskäivitatakse, kui see on võimalik RestartPolicy põhjal.
Mis juhtub, kui mälu piiranguid ei määrata?
See on halvim stsenaarium: planeerija ei tea, kui palju ressursse konteiner vajab, ja see võib põhjustada tõsiseid probleeme sõlmes. Sellisel juhul oleks hea omada vaikimisi piiranguid nimespaces (mille määravad LimitRange). Vaikimisi piiranguid ei ole — Podil ei ole piiranguid, see võib kasutada nii palju mälu, kui soovib.
Kui taotletud mälu on suurem, kui sõlm suudab pakkuda — Pod ei ole planeeritud. Oluline on meeles pidada, et Requests.memory — ei ole minimaalne väärtus. See kirjeldab mälu mahtu, mis on piisav konteineri pidevaks tööks.
Tavaliselt soovitatakse määrata sama väärtus request.memory ja limit.memory. See tagab, et Kubernetes ei planeeri Pod-i sõlmele, millel on piisavalt mälu Pod-i käivitamiseks, kuid mitte piisavalt tööks. Pidage meeles: Pod-i planeerimisel võtab Kubernetes arvesse ainult requests.memory, ja limits.memory ei arvesse võta.
CPU: päring ja piirang
konteinerid:
...
ressursid:
päringud:
cpu: 1
piirangud:
cpu: "1200m"
CPU puhul on kõik natuke keerulisem. Naastes pildi juurde Kubernetes'i ja Docker'i vahelisest seosest, võib märkida, et request.cpu vastab --cpu-shares, samas kui limit.cpu vastab lipule cpus Docker'is.
Kubernetes'i poolt küsitud CPU korrutatakse 1024-ga — CPU tsüklite suhe. Kui soovite küsida 1 täis tuuma, peate lisama cpu: 1, nagu eespool näidatud.
Täis tuuma pärimine (suhe = 1024) ei tähenda, et teie konteiner seda saab. Kui teie host-arvutis on ainult üks tuum ja kasutate rohkem kui ühte konteinerit, peavad kõik konteinerid jagama saadaolevat CPU-d omavahel. Kuidas see toimub? Vaadakem pilti.
CPU päring — süsteem ühe tuumaga
Kujutage ette, et teil on host-süsteem, kus on üks tuum ja käivad konteinerid. Ema (Kubernetes) on küpsetanud koogi (CPU) ja soovib seda jagada laste vahel (konteinerid). Kolm last soovivad ühte täis kooki (suhe = 1024), veel üks laps soovib poole kooki (512). Ema soovib 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%Arvutuste kohaselt saavad kolm last 28% südamikust, mitte täit südamikku. Neljas laps saab 14% täisest südamikust, mitte poolt. Kuid kõik oleks teistsugune, kui teil on mitme südamikuga süsteem.
Päring CPU — mitme südamikuga (4) süsteem
Ülaltoodud pildil on näha, et kolm last tahavad täielikku pirukat, ja üks — poolt. Kuna ema küpsetati neli pirukat, saavad tema lapsed nii palju, kui nad soovivad. Mitme südamikuga süsteemis jaotatakse protsessori ressursid kõigi saadaval olevate protsessorite südamike vahel. Kui konteiner on piiratud vähem kui ühe täise CPU südamikuga, võib see ikkagi seda 100% ulatuses kasutada.
Ülaltoodud arvutused on lihtsustatud, et selgitada, kuidas CPU jaotatakse konteinerite vahel. Loomulikult kasutatakse CPU ressursse ka teiste protsesside poolt peale konteinerite. Kui ühes konteineris on protsessid ootel, saavad teised kasutada selle ressursse. CPU: "200m" vastab CPU: 0,2, mis tähendab umbes 20% ühest südamikust.
Nüüd räägime limit.cpu. CPU, mida Kubernetes piirab, korrutatakse 100-ga. Tulemus on aeg, mille jooksul konteiner saab kasutada iga 100 µs ("cpu-periood).
limit.cpu vastab Docker'i lippu --cpu-jõud. See on uus kombinatsioon vanadest --cpu-periood ja --cpu-kvoota. Seadistades selle, määrame, kui palju CPU ressursse konteiner saab maksimaalselt kasutada, enne kui algab piiramise protsess:
- cpus — kombinatsioon
cpu-perioodjacpu-kvoota. cpus = 1.5võrdub seadistamisegacpu-periood = 100000jacpu-kvoota = 150000; - cpu-periood — periood , vaikimisi 100 mikrosekundit;
- cpu-kvoota — arv mikrosekundeid sees
cpu-periood, millega konteiner on piiratud.
Mis juhtub, kui määran liiga vähe küsitud CPU-d?
Kui konteiner vajab rohkem, kui on määratud, siis ta varastab CPU teistelt protsessidelt.
Mis juhtub, kui määran liiga madala CPU limiidi?
Kuna CPU ressurss on reguleeritav, siis käivitub piiramise protsess.
Mis juhtub, kui ei määra CPU nõuet?
Nagu ka mälu puhul, on nõude väärtus võrdne limiidiga.
Mis juhtub, kui ei määra CPU limiiti?
Konteiner kasutab nii palju CPU-d, kui tal on vaja. Kui nimede ruumis on määratud vaikimisi CPU poliitika (LimitRange), siis seda limiiti kasutatakse ka konteineri jaoks.
Mis juhtub, kui ei määra ei nõuet ega limiiti CPU-le?
Nagu mälu puhul, see on halvim stsenaarium. Planeerija ei tea, kui palju ressursse teie konteiner vajab, ja see võib põhjustada tõsiseid probleeme sõlmes. Selle vältimiseks on oluline seada vaikimisi piirangud nimedele (LimitRange).
Pidage meeles: kui küsite rohkem CPU-d, kui sõlmed saavad pakkuda, siis Pod ei planeerita. Requests.cpu — see ei ole minimaalne väärtus, vaid väärtus, mis on piisav Podi käivitamiseks ja probleemideta töötamiseks. Kui rakendus ei teosta keerulisi arvutusi, on parim valik seada request.cpu <= 1 ja käivitada nii palju koopiakontosid, kui on vaja.
Ideaalne küsitud ressursside või ressursside piiri kogus
Oleme õppinud arvutusressursside piirangust. Nüüd on aeg vastata küsimusele: 'Kui palju ressursse vajab minu Pod rakenduse probleemivabaks töötamiseks? Milline kogus on ideaalne?'.
Kahjuks ei ole nendele küsimustele selgeid vastuseid. Kui te ei tea, kuidas teie rakendus töötab, kui palju CPU-d või mälu tal vaja on, on parim valik anda rakendusele palju mälu ja CPU-d ning seejärel läbi viia jõudlustestid.
Lisaks jõudluskatsetele jälgige rakenduse käitumist monitorimisprotsessis nädala jooksul. Kui graafikud näitavad, et teie rakendus tarbib vähem ressursse kui soovisite, siis on võimalik vähendada küsitud CPU või mälu arvu.
Näidisena vaadake seda . See kuvab erinevuse küsitud ressursside või ressursside limiidi ja praeguse ressursikasutuse vahel.
Kokkuvõte
Ressursside küsimine ja piiramine aitab säilitada Kubernetes-klastri töökindlust. Õige piirangute seadistamine vähendab kulusid ja hoiab rakendused pidevalt töökorras.
Kokkuvõttes tuleb meeles pidada mitmeid aspekte:
- Küsitud ressursid on konfigureerimine, mis arvestatakse rakenduse käivitamise ajal (kui Kubernetes plaanib rakenduse paigutust). Vastupidi, ressursside piiramine on oluline rakenduse töö ajal — kui rakendus on juba sõlmes käinud.
- Võrreldes mäluga on CPU reguleeritav ressurss. Kui CPU on liiga vähe, ei katkesta teie Pod töö, vaid aktiveeritakse trottlingu mehhanism.
- Taotletavad ressursid ja ressursipiirangud ei ole minimaalsetest ega maksimaalsetest väärtustest! Määrates taotletavad ressursid, tagate, et rakendus töötab sujuvalt.
- Hea praktika on määrata mälu taotlus, mis on võrdne mälu piiranguga.
- On soovitatav määrata taotletud
CPU <=1, kui rakendus ei teosta keerukaid arvutusi. - Kui taotlete rohkem ressursse, kui node'il on, ei planeerita Pod'i kunagi sellele nodile.
- Õige taotletud ressursi/piirangu määramiseks kasutage koormustestimist ja jälgimist.
Loodan, et see artikkel aitab teil mõista ressursside piirangute põhikontseptsiooni ja et saate neid teadmisi oma töös rakendada.
Edu!
Mida veel lugeda:
- .
- .
- .
Allikas: habr.com
