As jo begjinne mei Kubernetes, is it gewoan om te ferjitten oer it ynstellen fan kontenerboarnen. Op dit punt is it genôch om te soargjen dat de Docker-ôfbylding wurket en kin wurde ynset op it Kubernetes-kluster.
Mar letter moat de applikaasje tegearre mei oare applikaasjes yn in produksjekluster ynset wurde. Om dit te dwaan, moatte jo boarnen tawize foar de kontener en soargje derfoar dat d'r genôch binne om de applikaasje op en rinne te krijen, en dat oare rinnende applikaasjes gjin problemen sille ûnderfine.
team oerset in artikel oer container boarnen (CPU & MEM), fersiken en boarne beheinings. Jo sille de foardielen fan dizze ynstellingen leare en wat bart as jo se net ynstelle.
Computing boarnen
Wy hawwe twa soarten boarnen mei de folgjende ienheden:
- Central Processing Unit (CPU) - kearnen;
- Unthâld (MEM) - bytes.
Boarnen wurde spesifisearre foar elke kontener. Yn it folgjende Pod YAML-bestân sille jo in boarne seksje sjen dy't de frege en limyt boarnen befettet:
- Requested Pod Resources = som fan oanfrege boarnen fan alle konteners;
- Pod Resource Limit = Som fan alle Pod Resource Limits.
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: 1GiFoarbyld fan oanfrege en beheinde boarnen
fjild resources.requested út de spesifikaasje Pod is ien fan de eleminten dy't wurdt brûkt om te finen de winske node. Jo kinne Pod-ynset al foar planne. Hoe fine jo in geskikte knooppunt?
Kubernetes bestiet út ferskate komponinten, ynklusyf in master node of master node (Kubernetes Control Plane). It masterknooppunt hat ferskate prosessen: kube-apiserver, kube-controller-manager en kube-scheduler.
It kube-scheduler-proses is ferantwurdlik foar it besjen fan nij oanmakke pods en it finen fan mooglike arbeidersknooppunten dy't oerienkomme mei alle pod-oanfragen, ynklusyf it oantal oanfrege boarnen. De list mei knooppunten fûn troch kube-scheduler is ranglist. De pod is pland op it knooppunt mei de heechste skoares.
Wêr sil de pearse Pod pleatst wurde?
Op 'e foto kinne jo sjen dat kube-scheduler in nije pearse Pod moat planne. It Kubernetes-kluster befettet twa knooppunten: A en B. Sa't jo sjen kinne, kin kube-scheduler gjin Pod planne op knooppunt A - de beskikbere (net frege) boarnen komme net oerien mei de fersiken fan 'e pearse Pod. Dat, de 1 GB ûnthâld frege troch de pearse Pod sil net passe op knooppunt A, om't it beskikbere ûnthâld 0,5 GB is. Mar node B hat genôch boarnen. As resultaat beslút kube-scheduler dat de bestimming fan 'e pearse Pod knooppunt B is.
No witte wy hoe't de frege boarnen ynfloed hawwe op de kar fan knooppunt om de Pod út te fieren. Mar wat is de ynfloed fan marginale boarnen?
De boarne limyt is in grins dat de CPU / MEM kin net oerstekke. De CPU-boarne is lykwols fleksibel, dus konteners dy't har CPU-grinzen berikke, sille de Pod net feroarsaakje. Ynstee sil CPU-throttling begjinne. As de MEM-gebrûkslimyt wurdt berikt, sil de kontener wurde stoppe fanwege OOM-Killer en opnij starte as tastien troch de RestartPolicy-ynstelling.
Oanfrege en maksimale boarnen yn detail
Boarnekommunikaasje tusken Docker en Kubernetes
De bêste manier om te ferklearjen hoe't boarneoanfragen en boarnegrinzen wurkje is om de relaasje tusken Kubernetes en Docker yn te fieren. Yn 'e ôfbylding hjirboppe kinne jo sjen hoe't de Kubernetes-fjilden en Docker-opstartflaggen relatearre binne.
Unthâld: fersyk en beheining
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Lykas hjirboppe neamd, wurdt ûnthâld metten yn bytes. Basearre op , kinne wy oantsjutte ûnthâld as in nûmer. Meastal is it in hiel getal, bygelyks 2678 - dat is 2678 bytes. Jo kinne ek efterheaksels brûke G и Gi, It wichtichste is om te ûnthâlden dat se net lykweardich binne. De earste is desimaal en de twadde is binêr. Lykas it foarbyld neamd yn 'e k8s dokumintaasje: 128974848, 129e6, 129M, 123Mi - se binne praktysk lykweardich.
Kubernetes opsje limits.memory komt oerien mei de flagge --memory fan Docker. Yn it gefal dat request.memory D'r is gjin pylk foar Docker, om't Docker dit fjild net brûkt. Jo kinne freegje, is dit sels nedich? Ja nedich. Lykas ik earder sei, is it fjild fan belang foar Kubernetes. Op grûn fan de ynformaasje derfan beslút kube-scheduler op hokker knooppunt de Pod te plannen.
Wat bart der as jo ynstelle net genôch ûnthâld foar in fersyk?
As de kontener de grinzen fan it frege ûnthâld berikt hat, dan wurdt de Pod yn in groep Pods pleatst dy't stopje as d'r net genôch ûnthâld is yn 'e node.
Wat bart der as jo ynstelle it ûnthâld limyt te leech?
As de kontener grutter is as de ûnthâldlimyt, wurdt it beëinige fanwege OOM-Killed. En sil as mooglik opnij starte op basis fan RestartPolicy wêr't de standertwearde is Always.
Wat bart der as jo net oantsjutte it frege ûnthâld?
Kubernetes sil de limytwearde nimme en it as standertwearde ynstelle.
Wat kin barre as jo gjin ûnthâld limyt oantsjutte?
De kontener hat gjin beheiningen; it kin safolle ûnthâld brûke as it wol. As hy begjint mei it brûken fan alle beskikbere ûnthâld fan it knooppunt, dan sil OOM him deadzje. De kontener sil dan as mooglik opnij starte wurde basearre op RestartPolicy.
Wat bart der as jo gjin ûnthâld grinzen oantsjutte?
Dit is it slimste senario: de planner wit net hoefolle boarnen de kontener fereasket, en dit kin serieuze problemen op it knooppunt feroarsaakje. Yn dit gefal soe it moai wêze om standertgrinzen te hawwen op 'e nammeromte (ynsteld troch LimitRange). D'r binne gjin standertgrinzen - de Pod hat gjin grinzen, it kin safolle ûnthâld brûke as it wol.
As it frege ûnthâld mear is dan it knooppunt kin biede, sil de Pod net pland wurde. It is wichtich om dat te ûnthâlden Requests.memory - net de minimale wearde. Dit is in beskriuwing fan 'e hoemannichte ûnthâld genôch om de kontener kontinu te hâlden.
It wurdt meastal oan te rieden om te setten deselde wearde foar request.memory и limit.memory. Dit soarget derfoar dat Kubernetes gjin Pod sil plannen op in knooppunt dat genôch ûnthâld hat om de Pod út te fieren, mar net genôch om it út te fieren. Hâld der rekken mei: Kubernetes Pod-planning hâldt allinich rekken mei requests.memoryen limits.memory nimt gjin rekken mei.
CPU: fersyk en limyt
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Mei in CPU is alles wat komplisearre. Werom nei it byld fan 'e relaasje tusken Kubernetes en Docker, kinne jo dat sjen request.cpu соответствует --cpu-shares, wylst limit.cpu komt oerien mei de flagge cpus in Docker.
De CPU dy't Kubernetes freget wurdt fermannichfâldige mei 1024, it oanpart fan CPU-syklusen. As jo 1 folsleine kearn oanfreegje wolle, moatte jo tafoegje cpu: 1lykas hjirboppe werjûn.
It oanfreegjen fan in folsleine kernel (ferhâlding = 1024) betsjut net dat jo kontener it sil ûntfange. As jo hostmasine mar ien kearn hat en jo hawwe mear dan ien kontener, dan moatte alle konteners de beskikbere CPU tusken har diele. Hoe komt dit? Litte wy nei de foto sjen.
CPU Request - Single Core System
Litte wy ús foarstelle dat jo in single-core hostsysteem hawwe mei konteners. Mem (Kubernetes) bakt in taart (CPU) en wol it ferdielen tusken bern (konteners). Trije bern wolle in hiele taart (ferhâlding = 1024), in oar bern wol in heale taart (512). Mem wol earlik wêze en makket in ienfâldige berekkening.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Op grûn fan de berekkening krije trije bern 28% fan de kearn, en net de hiele kearn. It fjirde bern sil 14% fan 'e folsleine kearn krije, net de helte. Mar dingen sille oars as jo in multi-core systeem.
CPU Request - Multi-Core (4) Systeem
Yn de ôfbylding hjirboppe kinne jo sjen dat trije bern wol in hiele taart, en ien wol de helte. Sûnt mem fjouwer taarten bakt, krijt elk fan har bern safolle as se wolle. Yn in multi-core systeem wurde prosessor boarnen ferdield oer alle beskikbere prosessor kearnen. As in kontener wurdt beheind ta minder as ien folsleine CPU kearn, kin it noch brûke op 100%.
De boppesteande berekkeningen wurde ferienfâldige om te begripen hoe't CPU wurdt ferdield ûnder konteners. Fansels, neist de konteners sels, binne d'r oare prosessen dy't ek CPU-boarnen brûke. As prosessen yn ien kontener idle binne, kinne oaren har boarne brûke. CPU: "200m" соответствует CPU: 0,2, dat betsjut likernôch 20% fan ien kearn.
No litte wy it oer hawwe limit.cpu. De CPU dy't Kubernetes beheint wurdt fermannichfâldige mei 100. It resultaat is de hoemannichte tiid dat de kontener elke 100 µs kin brûke (cpu-period).
limit.cpu komt oerien mei de flagge fan Docker --cpus. Dit is in nije kombinaasje fan âlde --cpu-period и --cpu-quota. Troch it yn te stellen, jouwe wy oan hoefolle beskikbere CPU-boarnen de kontener maksimaal kin brûke foardat throttling begjint:
- cpus - kombinaasje
cpu-periodиcpu-quota. cpus = 1.5lykweardich oan ynstellingcpu-period = 100000иcpu-quota = 150000; - CPU-perioade - perioade , standert 100 mikrosekonden;
- cpu-kwota - oantal mikrosekonden binnen
cpu-period, dat wurdt begrinze troch de kontener.
Wat bart der as jo ynstallearje net genôch oanfrege CPU?
As de kontener mear nedich is as it is ynstalleare, sil it CPU stelle fan oare prosessen.
Wat bart der as jo ynstelle de CPU limyt te leech?
Sûnt de CPU-boarne ferstelber is, sil throttling ynskeakelje.
Wat bart der as jo gjin CPU-fersyk opjaan?
Lykas by ûnthâld, de fersyk wearde is gelyk oan de limyt.
Wat bart der as jo gjin CPU limyt oantsjutte?
De kontener sil safolle CPU brûke as it nedich is. As in standert CPU-belied (LimitRange) is definiearre yn 'e nammeromte, dan wurdt dizze limyt ek brûkt foar de kontener.
Wat bart der as jo gjin oantsjutting of in fersyk of in CPU limyt?
Lykas by ûnthâld is dit it slimste senario. De planner wit net hoefolle boarnen jo kontener nedich is, en dit kin serieuze problemen op it knooppunt feroarsaakje. Om dit te foarkommen, moatte jo standertgrinzen ynstelle foar nammeromten (LimitRange).
Unthâld: as jo mear CPU freegje dan de knooppunten kinne leverje, sil de Pod net pland wurde. Requests.cpu - net de minimale wearde, mar in wearde genôch om de Pod te begjinnen en sûnder mislearrings te wurkjen. As de applikaasje gjin komplekse berekkeningen útfiert, is de bêste opsje om te ynstallearjen request.cpu <= 1 en lansearje safolle replika's as nedich.
Ideale hoemannichte oanfrege boarnen as boarnelimyt
Wy learden oer de beheining fan komputerboarnen. No is it tiid om de fraach te beantwurdzjen: "Hoefolle boarnen hat myn Pod nedich om de applikaasje sûnder problemen út te fieren? Wat is it ideale bedrach?
Spitigernôch binne d'r gjin dúdlike antwurden op dizze fragen. As jo net witte hoe't jo applikaasje wurket of hoefolle CPU of ûnthâld it nedich is, is de bêste opsje om de applikaasje in soad ûnthâld en CPU te jaan en dan prestaasjestests út te fieren.
Njonken prestaasjestests, kontrolearje it gedrach fan 'e applikaasje by tafersjoch foar in wike. As de grafiken oanjaan dat jo applikaasje minder boarnen ferbrûkt dan jo frege hawwe, kinne jo it oanfrege bedrach fan CPU of ûnthâld ferminderje.
As foarbyld sjoch dit . It toant it ferskil tusken de frege boarnen of boarnelimyt en it hjoeddeistige boarnegebrûk.
konklúzje
Boarnen oanfreegje en beheine helpt jo Kubernetes-kluster sûn te hâlden. De juste limytkonfiguraasje minimearret kosten en hâldt applikaasjes altyd rinnend.
Koartsein, d'r binne in pear dingen om yn gedachten te hâlden:
- Oanfrege boarnen binne in konfiguraasje dy't rekken holden wurdt by it opstarten (as Kubernetes fan plan is de applikaasje te hostjen). Yn tsjinstelling, it beheinen fan boarnen is wichtich by runtime - as de applikaasje al rint op it knooppunt.
- Yn ferliking mei ûnthâld is de CPU in regele boarne. As d'r net genôch CPU is, sil jo Pod net ôfslute en sil it gasmeganisme ynskeakelje.
- Oanfrege boarnen en boarnelimyt binne gjin minimale en maksimale wearden! Troch de oanfrege boarnen te definiearjen, soargje jo derfoar dat de applikaasje sûnder problemen rint.
- In goede praktyk is in set it ûnthâld fersyk gelyk oan de ûnthâld limyt.
- Ok ynstallaasje frege
CPU <=1, as de applikaasje gjin komplekse berekkeningen útfiert. - As jo mear boarnen oanfreegje dan beskikber binne op in knooppunt, sil de Pod nea op dat knooppunt wurde pland.
- Om it juste bedrach fan oanfrege boarnen / boarnegrinzen te bepalen, brûk load testen en tafersjoch.
Ik hoopje dat dit artikel jo helpt it basisbegryp fan boarnebeheining te begripen. En jo sille dizze kennis kinne tapasse yn jo wurk.
Súkses!
Wat oars te lêzen:
- .
- .
- .
Boarne: www.habr.com