Na začiatku práce s Kubernetes sa zvyčajne zabúda na nastavenie zdrojov kontajnerov. V tejto fáze stačí overiť, že obraz Docker funguje a dá sa nasadiť v klastre Kubernetes.
Neskôr sa však vyžaduje nasadenie aplikácie do produkčného klastra spolu s inými aplikáciami. Na to je potrebné vyčleniť zdroje pre kontajner a zabezpečiť, že sú dostatočné na spustenie a prevádzku aplikácie, a že sa nevyskytnú problémy s inými bežiacimi aplikáciami.
Tím preložila článok o zdrojoch kontajnerov (CPU & MEM), požiadavkách a obmedzeniach zdrojov. Zistíte, aké výhody poskytujú tieto nastavenia a čo sa stane, ak sa nenastavia.
Výpočtové zdroje
Máme dva typy zdrojov s nasledujúcimi jednotkami:
- Centrálny procesor (CPU) — jadrá;
- Pamäť (MEM) — bajty.
Zdroje sú určené pre každý kontajner. V nasledujúcom YAML súbore Pod uvidíte sekciu zdrojov, ktorá obsahuje požadované a maximálne zdroje:
- Požadované zdroje Pod = suma požadovaných zdrojov všetkých kontajnerov;
- Maximálne zdroje Pod = suma maximálnych zdrojov všetkých kontajnerov.
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 # POŽADOVANÝ CPU: 200m jadier
memory: "1Gi" # POŽADOVANÁ MEM: 1Gi
limits:
cpu: 1 # MAXIMÁLNE VYUŽITIE CPU: 1 jadro
memory: "1Gi" # MAXIMÁLNE VYUŽITIE MEM: 1Gi
- name: other-container
image: other-app
tag: v1
ports:
- containerPort: 8000
resources:
requests:
cpu: "200m" # POŽADOVANÝ CPU: 200m jadier
memory: "0.5Gi" # POŽADOVANÁ MEM: 0.5Gi
limits:
cpu: 1 # MAXIMÁLNE VYUŽITIE CPU: 1 jadro
memory: "1Gi" # MAXIMÁLNE VYUŽITIE MEM: 1GiPríklad požadovaných a maximálnych zdrojov
Pole resources.requested z špecifikácie Pod — jeden z prvkov, ktorý sa používa na vyhľadávanie potrebného uzla. Naň sa môže naplánovať nasadenie Pod. Ako sa hľadá vhodný uzol?
Kubernetes sa skladá z niekoľkých komponentov, vrátane hlavného uzla alebo master uzla (Kubernetes Control Plane). Na master uzle beží niekoľko procesov: kube-apiserver, kube-controller-manager a kube-scheduler.
Proces kube-scheduler zodpovedá za prehľadávanie novo vytvorených modulov a hľadanie potenciálnych pracovných uzlov, ktoré spĺňajú všetky požiadavky modulov, vrátane počtu požadovaných zdrojov. Zoznam uzlov, ktoré nájde kube-scheduler, sa hodnotí. Pod sa plánuje na uzle s najvyššími bodmi.
Kam bude umiestnený fialový Pod?
Na obrázku je vidieť, že kube-scheduler má naplánovať nový fialový Pod. Kubernetes klaster obsahuje dva uzly: A a B. Ako si môžete všimnúť, kube-scheduler nemôže naplánovať Pod na uzol A — dostupné (nepožiadané) zdroje nezodpovedajú požiadavkám fialového Pod. Takže požadovaných 1 GB pamäte pre fialový Pod sa nezmestí na uzol A, pretože dostupný objem pamäte je 0,5 GB. Ale uzol B má dostatok zdrojov. Nakoniec kube-scheduler rozhodne, že určením fialového Pod je uzol B.
Teraz už vieme, ako požadované zdroje ovplyvňujú výber uzla pre spustenie Pod. Ale ako ovplyvňujú predbežné zdroje?
Predbežné zdroje sú hranicou, ktorú CPU/MEM nemôže prekročiť. Naviac, CPU je flexibilné, takže kontajnery, ktoré dosiahnu predbežné hodnoty CPU, nespôsobia ukončenie Pod. Namiesto toho sa aktivuje obmedzenie CPU. Avšak, ak sa dosiahne limit na využitie MEM, kontajner bude zastavený kvôli OOM-Killer a reinicializovaný, ak to povolí nastavenie RestartPolicy.
Požadované a predbežné zdroje v detalhoch
Prepojenie zdrojov medzi Dockerom a Kubernetes
Najlepší spôsob, ako vysvetliť, ako fungujú požadované a predbežné zdroje, je predstaviť prepojenie medzi Kubernetes a Dockerom. Na obrázku vyššie si môžete pozrieť, ako sú navzájom prepojené polia Kubernetes a spúšťacie flagy Dockeru.
Pamäť: požiadavka a obmedzenie
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Ako bolo spomenuté vyššie, pamäť sa meria v bajtoch. Na základe , môžeme určiť pamäť ako číslo. Zvyčajne je to celé číslo, napríklad 2678 — teda 2678 bajtov. Môžeme tiež použiť prípony G a Gi, dôležité je pamätať, že nie sú ekvivalentné. Prvý je desiatkový, zatiaľ čo druhý je dvojkový. Ako príklad, uvedený v dokumentácii k8s: 128974848, 129e6, 129M, 123Mi — sú prakticky ekvivalentné.
Parametr Kubernetes limits.memory zodpovedá flagu --memory z Dockeru. V prípade request.memory nenachádzajú sa žiadne šípky pre Docker, pretože Docker toto pole nepoužíva. Môžete sa opýtať, či je to vôbec potrebné? Áno, je. Ako som už spomenul, pole má význam pre Kubernetes. Na základe informácií v ňom kube-scheduler rozhoduje, na ktorý uzol naplánovať Pod.
Čo sa stane, ak nastavíte pre požiadavku nedostatočnú pamäť?
Ak kontajner dosiahne hranice požadovanej pamäte, Pod sa umiestni do skupiny Pod, ktoré sa zastavujú pri nedostatku pamäte v uzle.
Čo sa stane, ak nastavíte príliš nízky limit pamäte?
Ak kontajner prekročí limit pamäte, bude ukončený z dôvodu OOM-Killed. A bude znovu spustený, ak je to možné na základe RestartPolicy, kde je predvolené nastavenie — Vždy.
Čo sa stane, ak neuvádzate požadovanú pamäť?
Kubernetes vezme limit a nastaví ho ako predvolenú hodnotu.
Čo sa môže stať, ak neuvádzate limit na pamäť?
Kontajner nemá obmedzenia, môže používať toľko pamäte, koľko chce. Ak však začne využívať celú dostupnú pamäť nody, bude zlikvidovaný OOM. Potom bude kontajner znova spustený, ak je to možné na základe RestartPolicy.
Čo sa stane, ak neuvádzate limity pamäte?
Toto je najhorší scenár: plánovač nevie, koľko zdrojov kontajner potrebuje, a to môže spôsobiť vážne problémy na node. V tomto prípade by bolo dobré mať predvolené obmedzenia v namespacu (nastavené LimitRange). Neexistujú žiadne predvolené obmedzenia — pod nemá obmedzenia, môže používať toľko pamäte, koľko chce.
Ak je požadovaná pamäť väčšia, než môže node ponúknuť — pod nebude naplánovaný. Je dôležité si zapamätať, že Requests.memory — nie je minimálna hodnota. Toto je popis objemu pamäte, ktorý je dostatočný na nepretržitú prevádzku kontajnera.
Zvyčajne sa odporúča nastaviť rovnakú hodnotu pre request.memory a limit.memory. Vďaka tomu Kubernetes nenaplánuje pod na uzle, ktorý má dostatok pamäte na spustenie podu, ale nie dostatok na jeho prevádzku. Pamätajte: pri plánovaní podu Kubernetes zohľadňuje iba requests.memory, a limits.memory neráta.
CPU: požiadavka a limit
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
S CPU je to trochu zložitejšie. Ak sa vrátite k obrázku týkajúcemu sa súvislosti medzi Kubernetes a Dockerom, môžete si všimnúť, že request.cpu zodpovedá --cpu-shares, zatiaľ čo limit.cpu zodpovedá flagu cpus v Dockeri.
CPU, ktorý Kubernetes požaduje, sa násobí 1024 — proporciou cyklov CPU. Ak chcete požiadať o 1 celé jadro, musíte pridať cpu: 1, ako je uvedené vyššie.
Žiadosť o plné jadro (proporcia = 1024) neznamená, že váš kontajner ho dostane. Ak má váš hostiteľský počítač len jedno jadro a používate viac ako jeden kontajner, všetky kontajnery musia zdieľať dostupný CPU medzi sebou. Ako sa to deje? Pozrime sa na obrázok.
Žiadosť CPU — systém s jedným jadrom
Predstavte si, že máte hostiteľský systém s jedným jadrom, na ktorom sú spustené kontajnery. Mama (Kubernetes) upiekla koláč (CPU) a chce ho rozdeliť medzi deti (kontajnery). Tri deti chcú celý koláč (proporcia = 1024), ďalšie dieťa chce polovicu koláča (512). Mama chce byť spravodlivá a vykonáva jednoduchý výpočet.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Na základe výpočtu tri deti dostanú po 28% jadra, nie po celom jadre. Štvrtému dieťaťu pripadne 14% z celého jadra, nie polovica. Ale všetko bude iné, ak máte viacjadrový systém.
Žiadosť CPU — viacjadrový (4) systém
Na obrázku vyššie je vidieť, že tri deti chcú celý koláč a jedno chce polovicu. Keďže mama upiekla štyri koláče, každé z jej detí dostane toľko, koľko chce. V višejadrovom systéme sú procesorové zdroje rozdelené medzi všetky dostupné jadrá procesora. Ak je kontajner obmedzený na menej ako jedno celé jadro CPU, stále ho môže využívať na 100%.
Vyššie uvedené výpočty sú zjednodušené na pochopenie toho, ako sa CPU rozdeľuje medzi kontajnery. Samozrejme, okrem samotných kontajnerov existujú aj iné procesy, ktoré tiež využívajú zdroje CPU. Keď procesy v jednom kontajneri nepracujú, iné môžu využívať jeho zdroje. CPU: "200m" zodpovedá CPU: 0,2, čo znamená približne 20% jedného jadra.
Teraz sa poďme porozprávať o limit.cpu. CPU, ktorý obmedzuje Kubernetes, sa vynásobí 100. Výsledok je množstvo času, počas ktorého môže kontajner používať každých 100 µs (cpu-period).
limit.cpu súvisí s vlajkou Docker --cpus. Toto je nová kombinácia starých --cpu-period a --cpu-quota. Nastavením tohto parametra určujeme, koľko dostupných zdrojov CPU môže kontajner maximálne využiť, kým nezačne obmedzovanie:
- cpus — kombinácia
cpu-periodacpu-quota. cpus = 1.5je ekvivalentná nastaveniucpu-period = 100000acpu-quota = 150000; - cpu-period — obdobie , predvolené nastavenie je 100 mikrosekúnd;
- cpu-quota — počet mikrosekúnd v rámci
cpu-period, ktorým je kontajner obmedzený.
Čo sa stane, ak nastavíte nedostatočný požiadavok na CPU?
Ak kontajner potrebuje viac, ako je nastavené, ukradne CPU ostatným procesom.
Čo sa stane, ak nastavíte nedostatočný limit CPU?
Pretože je zdroj CPU regulovaný, začne obmedzovanie.
Čo sa stane, ak neurčíte žiadosť CPU?
Rovnako ako pri pamäti, hodnota požiadavky je rovná limitu.
Čo sa stane, ak neuviedete limit CPU?
Kontajner bude používať toľko CPU, koľko potrebuje. Ak je v názvovom priestore definovaná predvolená politika CPU (LimitRange), tento limit sa použije aj pre kontajner.
Čo sa stane, ak neuviediete požiadavku ani limit CPU?
Rovnako ako pri pamäti, toto je najhorší scenár. Plánovač nevie, koľko zdrojov váš kontajner potrebuje, a to môže spôsobiť vážne problémy na uzle. Aby ste tomu predišli, je potrebné nastaviť predvolené obmedzenia pre názvové priestory (LimitRange).
Pamätajte: ak požiadate o viac CPU, ako môžu poskytnúť uzly, Pod nebude naplánovaný. Requests.cpu — nie minimálna hodnota, ale hodnota dostatočná na spustenie Podu a jeho bezproblémové fungovanie. Ak aplikácia nevykonáva zložitý výpočtový proces, najlepšou voľbou je nastaviť request.cpu <= 1 a spustiť toľko replik, koľko je potrebné.
Ideálne množstvo požadovaných zdrojov alebo limitu zdrojov
Dozvedeli sme sa o obmedzení výpočtových zdrojov. Teraz je čas odpovedať na otázku: „Koľko zdrojov potrebuje môj Pod na to, aby aplikácia fungovala bez problémov? Aké množstvo je ideálne?“.
Žiaľ, na tieto otázky nie je jednoznačná odpoveď. Ak neviete, ako vaša aplikácia funguje, koľko CPU alebo pamäte potrebuje, najlepšou voľbou je poskytnúť aplikácii veľa pamäte a CPU, a potom spustiť výkonnostné testy.
Okrem výkonnostných testov, po dobu jedného týždňa sledujte správanie aplikácie v monitoringu. Ak z grafov vyplýva, že vaša aplikácia spotrebúva menej zdrojov, ako ste požadovali, môžete znížiť množstvo požadovaného CPU alebo pamäte.
Ako príklad sa pozrite na tento . Zobrazuje rozdiel medzi požadovanými zdrojmi alebo limitom zdrojov a aktuálnym využitím zdrojov.
Záver
Požiadavky a obmedzenia zdrojov pomáhajú udržiavať funkčnosť klastrov Kubernetes. Správna konfigurácia limitov minimalizuje náklady a neustále udržuje aplikácie v chode.
Stručne povedané, mali by ste mať na pamäti niekoľko aspektov:
- Požadované prostriedky sú konfigurácia, ktorá sa zohľadňuje počas spúšťania (keď Kubernetes plánuje umiestnenie aplikácie). Naopak, obmedzenie prostriedkov je dôležité počas prevádzky — keď už je aplikácia spustená na uzle.
- V porovnaní s pamäťou je CPU regulovateľný prostriedok. V prípade nedostatku CPU váš Pod nebude ukončený, ale zapne sa mechanizmus spomalenia.
- Požadované prostriedky a limit prostriedkov nie sú minimálne a maximálne hodnoty! Určením požadovaných prostriedkov zaručujete, že aplikácia bude fungovať bez problémov.
- Dobrou praxou je nastaviť požiadavku na pamäť, ktorá sa rovná limitu pamäti.
- Je dobré nastaviť požiadavku
CPU <=1, ak aplikácia nevykonáva zložitý výpočtový proces. - Ak požiadate o viac prostriedkov, ako sú k dispozícii na uzle, Pod nikdy nebude naplánovaný na tento uzol.
- Na určenie správneho množstva požadovaných prostriedkov/limitov prostriedkov použite záťažové testovanie a monitoring.
Dúfam, že tento článok vám pomôže pochopiť základný koncept obmedzenia prostriedkov. A budete môcť uplatniť tieto poznatky vo svojej práci.
Veľa šťastia!
Čo ďalšie čítať:
- .
- .
- .
Zdroj: habr.com
