Kubernetes'ega alustades unustatakse tavaliselt konteinerite ressursside seadistamine. Sel etapil piisab, kui veenduda, et Docker'i pilt töötab ja seda saab Kubernetes'i klastris rakendada.
Kuid hiljem tuleb rakendus käivitada tootmisklastris 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 tõuseks probleeme.
Meeskond tõlkis artikli konteinerite ressurssidest (CPU & MEM), ressursside päringutest ja piirangutest. Saate teada, millised on nende seadistuste eelised ja mis juhtub, kui neid ei seadista.
Arvutusressursid
Meil on kaks tüüpi ressursse järgmiste ühikutega:
- Keskprotsessor (CPU) — tuumad;
- Mälu (MEM) — baitid.
Ressursid on määratud iga konteineri jaoks. Järgmises YAML-failis Pod'i kohta näete ressursside jaotust, mis sisaldab nõutud ja piiratud ressursse:
- Nõutud ressursid Pod'i jaoks = kõigi konteinerite nõutud ressursside summa;
- Piiratud ressursid Pod'i jaoks = 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 # NÕUTUD CPU: 200m tuuma
memory: "1Gi" # NÕUTUD 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" # NÕUTUD CPU: 200m tuuma
memory: "0.5Gi" # NÕUTUD MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU KASUTUS: 1 tuum
memory: "1Gi" # MAX MEM KASUTUS: 1GiNõutud ja piiratud ressursside näide
Väli resources.requested Pod'i spetsifikatsioonist — üks elementidest, mida kasutatakse sobiva sõlme otsimiseks. Juba sellele saab planeerida Pod'i juurutamise. Kuidas otsitakse sobivat sõlme?
Kubernetes koosneb mitmest komponendist, sealhulgas sisaldab peamist sõlme ehk master-sõlme (Kubernetes Control Plane). Master-sõlmes on mitu protsessi: kube-apiserver, kube-controller-manager ja kube-scheduler.
Kube-scheduleri protsess vastutab uuscreateeritud moodulite vaatamise ja sobivate tööde sõlmede leidmise eest, mis vastavad kõikidele moodulite nõudmistele, sealhulgas nõutavatele ressurssidele. Kube-scheduleri leidnud sõlmede nimekiri järjestatakse. Pod planeeritakse sõlmele, millel on kõrgeim skoor.
Kuhu paigutatakse lilla Pod?
Pildilt näeme, et kube-scheduler peab kavandama uue lilla Pod. Kubernetes'i klaster sisaldab kahte sõlme: A ja B. Nagu näha, ei saa kube-scheduler kavandada Pod-i sõlmele A — vabad (mitte-nõutud) ressursid ei vasta lilla Pod-i nõudmistele. Nii et lilla Pod-i nõutud 1 GB mälu ei mahu sõlmele A, kuna saadaval olev mälu on 0,5 GB. Kuid sõlmel B on piisavalt ressursse. Seetõttu otsustab kube-scheduler, et lilla Pod-i sihtkoht on sõlm B.
Nüüd teame, kuidas nõutud ressursid mõjutavad sõlme valikut Pod'i käitamiseks. Aga kuidas mõjutavad piiravad ressursid?
Piiravad ressursid on piir, mida CPU/MEM ei saa ületada. Siiski on CPU ressurss paindlik, seega konteinerid, mis on jõudnud CPU piiridest üle, ei viima Pod-i töö lõpetamisele. Selle asemel saab alguse CPU piiramine. Kui aga MEM-i kasutamise piir on saavutatud, peatub konteiner OOM-Killeri tõttu ja taaskäivitub, kui see on lubatud RestartPolicy seadistuse abil.
Nõutud ja piiravad ressursid üksikasjalikult
Ressursside seos Dockeriga ja Kubernetesega
Parim viis selgitada, kuidas toimivad nõutud ja piiravad ressursid, on näidata seost Kubernetes'i ja Docker'i vahel. Ülaltoodud joonisel näete, kuidas on seotud Kubernetes'i väljad ja Docker'i käivitamislipud.
Mälu: nõue ja piirang
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Nagu eespool mainitud, mõõdetakse mälu baitides. Põhinedes , võime määrata mälu numbrina. Tavaline on, et see on täisarv, nagu näiteks 2678 — see tähendab 2678 baiti. Samuti on võimalik kasutada sufikse. G ja Gi, oluline on meeles pidada, et need ei ole liikmed. Esimene on kümnend, teine aga on binaarne. Näiteks, nagu mainitud k8s dokumentatsioonis: 128974848, 129e6, 129M, 123Mi — need on praktiliselt ekvivalentne.
Kubernetes'i parameeter limits.memory vastab Docker'i lipule --memory seoses request.memory Dockeri noole ei ole, kuna Docker seda välja ei kasuta. Kas te saate küsida, kas see on üldse vajalik? Jah, see on vajalik. Nagu ma juba mainisin, on see väli olulise tähtsusega Kubernetes'i jaoks. Sellel põhinevalt otsustab kube-scheduler, millisele solgule Pod planeerida.
Mida juhtub, kui taotlusele määratakse liiga vähe mälu?
Kui konteiner saavutab määratud mälu piirid, siis asetatakse Pod Pod-gruppi, mis peatatakse, kui solgus on mälu puudus.
Mida juhtub, kui määratud mälu ülemine piir on liiga väike?
Kui konteiner ületab mälu piiri, lõpetatakse see OOM-Killed'i tõttu. Ja see taaskäivitatakse, kui see on võimalik RestartPolicy alusel, mille vaikimisi väärtus on Alati.
Mida juhtub, kui taotletud mälu väärtust ei määrata?
Kubernetes võtab ülemise piiri väärtuse ja määrab selle vaikimisi väärtuseks.
Mida võib juhtuda, kui ülemine mälu piir ei ole määratud?
Konteineril ei ole piiranguid, ta võib kasutada nii palju mälu, kui tahab. Kui aga ta hakkab kasutama kogu saadaval olevat mälu, tuleb ta OOM-i tõttu maha. Seejärel, kui see on võimalik RestartPolicy alusel, taaskäivitab konteiner.
Mida juhtub, kui mälu piiranguid ei määrata?
See on kõige halvem stsenaarium: planeerija ei tea, kui palju ressursse konteiner vajab, ja see võib põhjustada tõsiseid probleeme solgus. Sel juhul oleks hea omada vaikimisi piiranguid nimede ruumis (mida seadistavad LimitRange). Vaikimisi piiranguid pole – Podil ei ole piiranguid, ta võib kasutada nii palju mälu, kui tahab.
Kui taotletud mälu on suurem kui solgu pakutav, siis Podi ei planeerita. Oluline on meeles pidada, et Requests.memory ei ole minimaalne väärtus. See on kirjeldus mäluhulk, mis on piisav konteineri pidevaks tööks.
Tavaliselt soovitatakse seada sama väärtus request.memory ja limit.memory. Nii ei planeeri Kubernetes Pod'i solgus, kus on piisavalt mälu Pod'i käivitamiseks, kuid mitte piisavalt tööks. Pidage meeles: Pod'i planeerimisel arvestab Kubernetes ainult requests.memory, vaid limits.memory ei arvesta.
CPU: taotlus ja piirang
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
CPU-de puhul on kõik veidi keerulisem. Tagasi tulles pildile, mis näitab suhete seost Kubernetes'i ja Docker'i vahel, võib märkida, et request.cpu vastab --cpu-shares, samas kui limit.cpu vastab Docker'i lipule cpus Docker'is.
CPU, mis Kubernetes küsib, korrutatakse 1024-ga — CPU tsüklite suhe. Kui soovite küsida 1 täispüsi, peate lisama cpu: 1, nagu eespool näidatud.
Täispüsi nõudmine (suhe = 1024) ei tähenda, et teie konteiner seda kindlasti saab. Kui teie host-süsteemil on vaid üks püsi ja kasutate rohkem kui ühte konteinerit, peavad kõik konteinerid jagama kergesti kergesti saadaolevat CPU-d. Kuidas see toimub? Vaatame pilti.
CPU nõudmine — süsteem, kus on üks püsi
Kujutage ette, et teil on host-süsteem, kus on üks püsi, millel töötavad konteinerid. Ema (Kubernetes) küpsetab koogi (CPU) ja soovib seda jagada laste vahel (konteinerid). Kolm last soovivad tervet koogi (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%Aruande kohaselt saavad kolm last 28% püsi, mitte tervet püsi. Neljas laps saab 14% täispüsi, mitte pool. Kuid kõik on erinev, kui teil on mitme põlvkonna süsteem.
CPU nõudmine — mitme põlvkonna (4) süsteem
Ülaltoodud pildil on näha, et kolm last soovivad tervet kooki, ja üks — poole. Kuna ema küpsetab neli kooki, saavad kõik tema lapsed seda, mida nad tahavad. Mitme põlvkonna süsteemis on protsessori ressursid jaotatud kõikide saadaolevate püside vahel. Kui konteiner on piiratud alla ühe täispüsi CPU, võib see siiski ära kasutada 100%.
Ülaltoodud arvutused on lihtsustatud, et mõista, kuidas CPU jaotatakse konteinerite vahel. Loomulikult on peale konteinerite ka muid protsesse, mis kasutavad CPU ressursse. Kui protsessid ühes konteineris on mitteaktiivsed, saavad teised kasutada nende ressursse. CPU: "200m" vastab CPU: 0,2, mis tähendab umbes 20% ühest püsi.
Nüüd räägime me limit.cpu. CPU, mida Kubernetes piirab, korrutatakse 100-ga. Tulemuseks on see, kui kaua konteiner saab kasutada igas 100 mikrosekundis (cpu-period).
limit.cpu vastab Docker'i lipule --cpus. See on vana segu uue kombinatsiooniga --cpu-period ja --cpu-quota. Selle seadistamisega märgime, kui palju saadaolevaid CPU ressursse konteiner saab maksimaalselt kasutada enne, kui hakkab vahetama:
- cpus — kombinatsioon
cpu-periodjacpu-quota. cpus = 1.5on ekvivalentse seadistamisegacpu-period = 100000jacpu-quota = 150000; - cpu-period — periood , vaikimisi 100 mikrosekundit;
- cpu-quota — mikrosekundite arv, mille jooksul
cpu-period, millega konteinerit piiratakse.
Mida juhtub, kui määrate liiga vähe nõutud CPU-d?
Kui konteiner vajab rohkem, kui on määratud, siis varastab see CPU teistelt protsessidelt.
Mida juhtub, kui määrate ka madala CPU limiidi?
Kuna CPU ressursid on reguleeritavad, aktiveeritakse throttling.
Mis juhtub, kui CPU nõuet ei määrata?
Nagu ka mälu puhul, on nõude väärtus sama mis limiit.
Mida juhtub, kui CPU limiiti ei määrata?
Konteiner kasutab nii palju CPU-d, kui tal on vaja. Kui nimespetsiifilis jaotuses on määratud vaike CPU poliitika (LimitRange), siis kasutatakse seda limiiti ka konteineri jaoks.
Mida juhtub, kui ei määrata ei nõuet ega limiiti CPU-le?
Nagu ka mälu puhul, on see halvim stsenaarium. Planeerijal ei ole aimu, kui palju ressursse teie konteiner vajab, ja see võib põhjustada tõsiseid probleeme sõlmes. Selle vältimiseks tuleb määrata vaikimisi piirangud nimespetsiifilistes jaotustes (LimitRange).
Pidage meeles: kui küsida rohkem CPU-d, kui sõlmed saavad pakkuda, siis Pod ei saa planeeritud. Requests.cpu — mitte minimaalne väärtus, vaid väärtus, mis on piisav Pod-i käivitamiseks ja probleemivabaks töötamiseks. Kui rakendus ei tee keerulisi arvutusi, on parem määrata request.cpu <= 1 ja käivitada nii palju koopiaid, kui vajalik.
Ideaalne nõutud ressursside või ressursside limiit
Oleme õppinud arvutusressursside piirangutest. Nüüd on aeg vastata küsimusele: 'Kui palju ressursse vajab minu Pod rakenduse probleemivabaks toimimiseks? Milline on ideaalne kogus?'.
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 lahendus anda rakendusele rohkelt mälu ja CPU-d ning seejärel läbida jõudluse testid.
Lisaks jõudluse testidele jälgige rakenduse käitumist seitsme päeva jooksul monitooringus. Kui graafikud näitavad, et teie rakendus tarbib vähem ressursse, kui küsisite, siis võib vähendada nõutud CPU või mälu kogust.
Kuna näide vaadake seda See näitab välja küsitud ressursside või ressursipiirangute ja praeguse ressursikasutuse vahet.
Kokkuvõte
Ressursside küsitlus ja piirangud aitavad hoida Kubernetes'e klastrit töökorras. Õige piirangute seadmine minimeerib kulud ja hoiab rakendused pidevalt töötamas.
Kokkuvõttes tuleks meeles pidada mitmeid aspekte:
- Nõutavad ressursid on konfiguratsioon, mida arvestatakse rakenduse käivitamisel (kui Kubernetes plaanib rakenduse paigutust). Vastupidiselt on ressursipiirang oluline rakenduse käitamise ajal — kui rakendus on juba sõlmes töötamas.
- Kuigi mälu on stabiilne ressurss, on CPU seadistatav ressurss. Kui CPU-d on liiga vähe, ei lõpetata teie Pod-i tööd, vaid aktiveeritakse throttle’imise mehhanism.
- Nõutavad ressursid ja ressursipiirangud ei ole minimaalne ja maksimaalne väärtus! Nõutavate ressursside määramine tagab, et rakendus töötab probleemideta.
- Hea praktika on seada mälu küsitlus võrdseks mälu piiranguga.
- Hea on seada küsitud
CPU <=1, kui rakendus ei teosta keerukaid arvutusi. - Kui küsitakse rohkem ressursse, kui on sõlmes, ei plaanita Pod-i kunagi sellele sõlmele.
- Õigete küsitavate ressursside/piirangute määramiseks kasutage koormustestimist ja jälgimist.
Loodan, et see artikkel aitab teil mõista ressursside piirangute põhimõtet. Ja te suudate neid teadmisi oma töös rakendada.
Edu!
Mida veel lugeda:
- .
- .
- .
Allikas: habr.com
