Komencante kun Kubernetes, estas ofte forgesi pri agordo de ujresursoj. Je ĉi tiu punkto, sufiĉas certigi, ke la bildo de Docker funkcias kaj povas esti deplojita al la Kubernetes-grupo.
Sed poste la aplikaĵo devas esti deplojita en produktadgrupo kune kun aliaj aplikoj. Por fari tion, vi devas asigni rimedojn por la ujo kaj certigi, ke estas sufiĉe da ili por ekfunkciigi la aplikaĵon, kaj ke aliaj kurantaj aplikaĵoj ne spertos problemojn.
teamo tradukis artikolon pri ujresursoj (CPU & MEM), petoj kaj limigoj de rimedoj. Vi lernos la avantaĝojn de ĉi tiuj agordoj kaj kio okazas se vi ne agordas ilin.
Komputilaj rimedoj
Ni havas du specojn de rimedoj kun la sekvaj unuoj:
- Centra prilaboranta unuo (CPU) - kernoj;
- Memoro (MEM) - bajtoj.
Rimedoj estas specifitaj por ĉiu ujo. En la sekva Pod YAML-dosiero, vi vidos rimedan sekcion, kiu enhavas la petitajn kaj limigajn rimedojn:
- Requested Pod Resources = sumo de petitaj rimedoj de ĉiuj ujoj;
- Pod Resource Limit = Sumo de ĉiuj Pod ResourceLimoj.
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: 1GiEkzemplo de Petitaj kaj Limigitaj Rimedoj
kampo resources.requested de la specifo Pod estas unu el la elementoj, kiuj estas uzataj por trovi la deziratan nodon. Vi jam povas plani Pod-deplojon por ĝi. Kiel vi trovas taŭgan nodon?
Kubernetes konsistas el pluraj komponentoj, inkluzive de majstra nodo aŭ majstra nodo (Kubernetes Control Plane). La majstra nodo havas plurajn procezojn: kube-apiserver, kube-controller-manager kaj kube-scheduler.
La procezo kube-scheduler respondecas pri revizio de lastatempe kreitaj podoj kaj trovado de eblaj labornodoj kiuj kongruas kun ĉiuj podpetoj, inkluzive de la nombro da rimedoj petitaj. La listo de nodoj trovitaj de kube-scheduler estas vicigita. La pod estas planita sur la nodo kun la plej altaj poentoj.
Kie estos metita la purpura Pod?
En la bildo vi povas vidi, ke kube-planisto devus plani novan purpuran Pod. La Kubernetes-areo enhavas du nodojn: A kaj B. Kiel vi povas vidi, kube-scheduler ne povas plani Pod sur nodo A - la disponeblaj (nepetitaj) rimedoj ne kongruas kun la petoj de la purpura Pod. Do, la 1 GB da memoro petita de la purpura Pod ne taŭgas sur la nodo A, ĉar la disponebla memoro estas 0,5 GB. Sed nodo B havas sufiĉe da rimedoj. Kiel rezulto, kube-planisto decidas ke la celloko de la purpura Pod estas nodo B.
Nun ni scias kiel la petitaj rimedoj influas la elekton de nodo por ruli la Pod. Sed kio estas la efiko de marĝenaj rimedoj?
La rimedlimo estas limo kiun la CPU/MEM ne povas transiri. Tamen, la CPU-rimedo estas fleksebla, do ujoj, kiuj atingas siajn CPU-limojn, ne igos la Pod eliri. Anstataŭe, CPU-estraligo komenciĝos. Se la limo de MEM-uzo estas atingita, la ujo estos haltita pro OOM-Killer kaj rekomencita se permesite de la agordo RestartPolicy.
Petitaj kaj maksimumaj rimedoj detale
Rimeda komunikado inter Docker kaj Kubernetes
La plej bona maniero klarigi kiel funkcias petoj de rimedoj kaj limoj de rimedoj estas enkonduki la rilaton inter Kubernetes kaj Docker. En la supra bildo vi povas vidi kiel la Kubernetes-kampoj kaj Docker-komencaj flagoj rilatas.
Memoro: peto kaj limigo
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Kiel menciite supre, memoro estas mezurita en bajtoj. Bazita sur , ni povas specifi memoron kiel nombron. Kutime ĝi estas entjero, ekzemple 2678 - tio estas 2678 bajtoj. Vi povas ankaŭ uzi sufiksojn G и Gi, la ĉefa afero estas memori, ke ili ne estas ekvivalentaj. La unua estas decimala kaj la dua estas duuma. Kiel la ekzemplo menciita en la k8s-dokumentado: 128974848, 129e6, 129M, 123Mi - ili estas praktike ekvivalentaj.
Kubernetes opcio limits.memory kongruas kun la flago --memory de Docker. En kazo de request.memory Ne estas sago por Docker ĉar Docker ne uzas ĉi tiun kampon. Vi povas demandi, ĉu ĉi tio eĉ necesas? Jes bezonas. Kiel mi diris antaŭe, la kampo gravas por Kubernetes. Surbaze de la informoj de ĝi, kube-scheduler decidas pri kiu nodo plani la Pod.
Kio okazas se vi agordas nesufiĉan memoron por peto?
Se la ujo atingis la limojn de la petita memoro, tiam la Pod estas metita en grupon de Pods kiuj haltas kiam ne estas sufiĉe da memoro en la nodo.
Kio okazas se vi fiksas la memorlimon tro malalta?
Se la ujo superas la memorlimon, ĝi estos ĉesigita pro OOM-Killed. Kaj rekomencos se eble surbaze de RestartPolicy kie estas la defaŭlta valoro Always.
Kio okazas se vi ne specifas la petitan memoron?
Kubernetes prenos la limvaloron kaj starigos ĝin kiel la defaŭltan valoron.
Kio povas okazi se vi ne specifas memorlimon?
La ujo ne havas limigojn; ĝi povas uzi tiom da memoro kiom ĝi volas. Se li komencas uzi la tutan disponeblan memoron de la nodo, tiam OOM mortigos lin. La ujo tiam estos rekomencita se eble surbaze de RestartPolicy.
Kio okazas se vi ne specifas memorlimojn?
Ĉi tiu estas la plej malbona kazo: la planisto ne scias kiom da rimedoj la ujo postulas, kaj tio povas kaŭzi gravajn problemojn sur la nodo. En ĉi tiu kazo, estus bone havi defaŭltajn limojn sur la nomspaco (agordita de LimitRange). Ne ekzistas defaŭltaj limoj - la Pod ne havas limojn, ĝi povas uzi tiom da memoro kiom ĝi volas.
Se la petita memoro estas pli ol la nodo povas oferti, la Pod ne estos planita. Gravas memori tion Requests.memory - ne la minimuma valoro. Ĉi tio estas priskribo de la kvanto de memoro sufiĉa por pluigi la ujon senĉese.
Oni kutime rekomendas agordi la saman valoron por request.memory и limit.memory. Ĉi tio certigas, ke Kubernetes ne planos Pod sur nodo kiu havas sufiĉe da memoro por ruli la Pod sed ne sufiĉe por ruli ĝin. Memoru: Kubernetes Pod-planado nur konsideras requests.memorykaj limits.memory ne konsideras.
CPU: peto kaj limo
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Kun CPU ĉio estas iom pli komplika. Revenante al la bildo de la rilato inter Kubernetes kaj Docker, vi povas vidi tion request.cpu соответствует --cpu-shares, dum limit.cpu kongruas kun la flago cpus en Docker.
La CPU, kiun Kubernetes petas, estas multobligita per 1024, la proporcio de CPU-cikloj. Se vi volas peti 1 plenan kernon, vi devas aldoni cpu: 1kiel montrite supre.
Peti plenan kernon (proporcio = 1024) ne signifas, ke via ujo ricevos ĝin. Se via gastiga maŝino nur havas unu kernon kaj vi funkcias pli ol unu ujon, tiam ĉiuj ujoj devas dividi la disponeblan CPU inter ili. Kiel tio okazas? Ni rigardu la bildon.
CPU Peto - Ununura Kerna Sistemo
Ni imagu, ke vi havas unukernan gastigan sistemon, kiu funkcias ujojn. Panjo (Kubernetes) bakis torton (CPU) kaj volas dividi ĝin inter infanoj (ujoj). Tri infanoj volas tutan kukaĵon (proporcio = 1024), alia infano volas duonan torton (512). Panjo volas esti justa kaj faras simplan kalkulon.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Surbaze de la kalkulo, tri infanoj ricevos 28% de la kerno, kaj ne la tutan kernon. La kvara infano ricevos 14% de la plena kerno, ne duonon. Sed aferoj estos malsamaj se vi havas plurkernan sistemon.
CPU Peto - Plurkerna (4) Sistemo
En la supra bildo vi povas vidi, ke tri infanoj volas tutan kukaĵon, kaj unu volas duonon. Ĉar panjo bakis kvar tortojn, ĉiu el ŝiaj infanoj ricevos tiom, kiom ili volas. En plurkerna sistemo, procesorresursoj estas distribuitaj tra ĉiuj disponeblaj procesorkernoj. Se ujo estas limigita al malpli ol unu plena CPU-kerno, ĝi ankoraŭ povas uzi ĝin je 100%.
La supraj kalkuloj estas simpligitaj por kompreni kiel CPU estas distribuita inter ujoj. Kompreneble, krom la ujoj mem, ekzistas aliaj procezoj, kiuj ankaŭ uzas CPU-resursojn. Kiam procezoj en unu ujo estas neaktivaj, aliaj povas uzi ĝian rimedon. CPU: "200m" соответствует CPU: 0,2, kio signifas proksimume 20% de unu kerno.
Nun ni parolu pri limit.cpu. La CPU, kiun Kubernetes limigas, estas multobligita per 100. La rezulto estas la kvanto da tempo, kiun la ujo povas uzi ĉiujn 100 µs (cpu-period).
limit.cpu kongruas kun la Docker-flago --cpus. Ĉi tio estas nova kombinaĵo de malnovaj --cpu-period и --cpu-quota. Fiksante ĝin, ni indikas kiom da disponeblaj CPU-resursoj la ujo povas maksimume uzi antaŭ ol komenciĝos la estrango:
- cpus - kombino
cpu-periodиcpu-quota. cpus = 1.5ekvivalenta al fiksocpu-period = 100000иcpu-quota = 150000; - CPU-periodo - periodo , defaŭlte 100 mikrosekundoj;
- cpu-quota - nombro da mikrosekundoj ene
cpu-period, kiu estas limigita de la ujo.
Kio okazas se vi instalas nesufiĉan petitan CPU?
Se la ujo bezonas pli ol ĝi instalis, ĝi ŝtelos CPU de aliaj procezoj.
Kio okazas se vi fiksas la CPU-limon tro malalta?
Ĉar la CPU-rimedo estas alĝustigebla, strekado ŝaltos.
Kio okazas se vi ne specifas CPU-peton?
Kiel ĉe memoro, la peta valoro estas egala al la limo.
Kio okazas se vi ne specifas CPU-limon?
La ujo uzos tiom da CPU kiom ĝi bezonas. Se defaŭlta CPU-politiko (LimitRange) estas difinita en la nomspaco, tiam ĉi tiu limo ankaŭ estas uzata por la ujo.
Kio okazas se vi ne specifas nek peton nek CPU-limon?
Kiel kun memoro, ĉi tiu estas la plej malbona kazo. La planisto ne scias kiom da rimedoj bezonas via ujo, kaj tio povas kaŭzi gravajn problemojn sur la nodo. Por eviti tion, vi devas agordi defaŭltajn limojn por nomspacoj (LimitRange).
Memoru: se vi petas pli da CPU ol la nodoj povas provizi, la Pod ne estos planita. Requests.cpu - ne la minimuma valoro, sed valoro sufiĉa por komenci la Pod kaj funkcii sen misfunkciadoj. Se la aplikaĵo ne faras kompleksajn kalkulojn, la plej bona elekto estas instali request.cpu <= 1 kaj lanĉi tiom da kopioj kiom necesas.
Ideala kvanto de petitaj rimedoj aŭ limo de rimedoj
Ni lernis pri la limigo de komputikaj rimedoj. Nun estas tempo respondi la demandon: "Kiom da rimedoj bezonas mia Pod por ruli la aplikaĵon sen problemoj? Kio estas la ideala kvanto?
Bedaŭrinde, ne estas klaraj respondoj al ĉi tiuj demandoj. Se vi ne scias kiel funkcias via aplikaĵo aŭ kiom da CPU aŭ memoro ĝi bezonas, la plej bona elekto estas doni al la aplikaĵo multe da memoro kaj CPU kaj poste fari rendimentajn testojn.
Krom agado-testoj, monitoru la konduton de la aplikaĵo en monitorado dum semajno. Se la grafikaĵoj indikas, ke via aplikaĵo konsumas malpli da rimedoj ol vi petis, vi povas redukti la kvanton de CPU aŭ memoro petita.
Kiel ekzemplo vidu ĉi tion . Ĝi montras la diferencon inter la petitaj rimedoj aŭ limo de rimedoj kaj la nuna uzado de rimedoj.
konkludo
Peti kaj limigi rimedojn helpas konservi vian Kubernetes-areton sana. Ĝusta limkonfiguracio minimumigas kostojn kaj daŭre funkcias aplikaĵojn.
Resume, estas kelkaj aferoj por konsideri:
- Petitaj rimedoj estas agordo, kiu estas konsiderata ĉe ekfunkciigo (kiam Kubernetes planas gastigi la aplikaĵon). Kontraste, limigi rimedojn estas grava ĉe rultempo—kiam la aplikaĵo jam funkcias sur la nodo.
- Kompare kun memoro, la CPU estas reguligita rimedo. Se ne estas sufiĉe da CPU, via Pod ne malŝaltos kaj la ŝtorma mekanismo ekŝaltos.
- Petitaj rimedoj kaj limo de rimedoj ne estas minimumaj kaj maksimumaj valoroj! Difinante la petitajn rimedojn, vi certigas, ke la aplikaĵo funkcios sen problemoj.
- Bona praktiko estas agordi la memorpeton egala al la memorlimo.
- Bone instalo petis
CPU <=1, se la aplikaĵo ne faras kompleksajn kalkulojn. - Se vi petas pli da rimedoj ol disponeblaj en nodo, la Pod neniam estos planita al tiu nodo.
- Por determini la ĝustan kvanton de petitaj rimedoj/limoj de rimedoj, uzu ŝarĝtestadon kaj monitoradon.
Mi esperas, ke ĉi tiu artikolo helpos vin kompreni la bazan koncepton pri limigo de rimedoj. Kaj vi povos apliki ĉi tiun scion en via laboro.
Bonŝancon!
Kion alian legi:
- .
- .
- .
fonto: www.habr.com