🥇Ako získať prístup k zdrojom Kubernetes Pod

Odmena od Tohada

Keď začínate s Kubernetes, je bežné, že zabudnete na nastavenie prostriedkov kontajnera. V tomto bode stačí zabezpečiť, aby obraz Docker fungoval a mohol byť nasadený do klastra Kubernetes.

Neskôr je však potrebné aplikáciu nasadiť v produkčnom klastri spolu s ďalšími aplikáciami. Ak to chcete urobiť, musíte prideliť prostriedky pre kontajner a uistiť sa, že ich je dostatok na spustenie aplikácie a že iné spustené aplikácie nebudú mať problémy.

Tím Kubernetes aaS z Mail.ru preložil článok o zdrojoch kontajnerov (CPU a MEM), požiadavkách a obmedzeniach zdrojov. Dozviete sa výhody týchto nastavení a čo sa stane, ak ich nenastavíte.

Výpočtové zdroje

Máme dva typy zdrojov s nasledujúcimi jednotkami:

Centrálna procesorová jednotka (CPU) - jadrá;
Pamäť (MEM) - bajty.

Zdroje sú špecifikované pre každý kontajner. V nasledujúcom súbore pod YAML uvidíte sekciu zdrojov, ktorá obsahuje požadované a obmedzené zdroje:

Requested Pod Resources = súčet požadovaných zdrojov všetkých kontajnerov;
Limit zdrojov podu = súčet všetkých limitov zdrojov podu.

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:  1Gi

Príklad požadovaných a obmedzených zdrojov

Pole resources.requested zo špecifikácie Pod je jedným z prvkov, ktorý sa používa na nájdenie požadovaného uzla. Už teraz si môžete naplánovať nasadenie modulu Pod. Ako nájdete vhodný uzol?

Kubernetes pozostáva z niekoľkých komponentov vrátane hlavného uzla alebo hlavného uzla (Kubernetes Control Plane). Hlavný uzol má niekoľko procesov: kube-apiserver, kube-controller-manager a kube-scheduler.

Proces plánovača kube je zodpovedný za kontrolu novovytvorených modulov a nájdenie možných pracovných uzlov, ktoré zodpovedajú všetkým požiadavkám na moduly, vrátane počtu požadovaných zdrojov. Zoznam uzlov nájdených plánovačom kube je zoradený. Modul je naplánovaný na uzol s najvyšším skóre.

Kde bude umiestnený fialový pod?

Na obrázku môžete vidieť, že plánovač kube by mal naplánovať nový fialový Pod. Klaster Kubernetes obsahuje dva uzly: A a B. Ako vidíte, kube-scheduler nemôže naplánovať Pod na uzle A – dostupné (nevyžiadané) zdroje nezodpovedajú požiadavkám fialového Podu. Takže 1 GB pamäte, ktorú požaduje fialový modul, sa nezmestí do uzla A, pretože dostupná pamäť je 0,5 GB. Ale uzol B má dostatok zdrojov. Výsledkom je, že plánovač kube rozhodne, že cieľom fialového podu je uzol B.

Teraz vieme, ako požadované zdroje ovplyvňujú výber uzla na spustenie modulu. Aký je však vplyv okrajových zdrojov?

Limit prostriedkov je hranica, ktorú CPU/MEM nemôže prekročiť. Prostriedok CPU je však flexibilný, takže kontajnery, ktoré dosiahnu svoje limity CPU, nespôsobia ukončenie modulu. Namiesto toho sa spustí obmedzovanie CPU. Ak sa dosiahne limit používania MEM, kontajner sa zastaví kvôli OOM-Killer a reštartuje sa, ak to umožňuje nastavenie RestartPolicy.

Požadované a maximálne zdroje podrobne

Komunikácia zdrojov medzi Dockerom a Kubernetes

Najlepším spôsobom, ako vysvetliť, ako fungujú požiadavky na zdroje a limity zdrojov, je predstaviť vzťah medzi Kubernetes a Dockerom. Na obrázku vyššie môžete vidieť, ako súvisia polia Kubernetes a príznaky spustenia Dockera.

Pamäť: požiadavka a obmedzenie

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Ako bolo uvedené vyššie, pamäť sa meria v bajtoch. Založené na Dokumentácia Kubernetes, môžeme pamäť špecifikovať ako číslo. Zvyčajne je to celé číslo, napríklad 2678 – teda 2678 bajtov. Môžete použiť aj prípony G и Gi, hlavnou vecou je pamätať na to, že nie sú ekvivalentné. Prvý je desiatkový a druhý je binárny. Ako príklad uvedený v dokumentácii k8s: 128974848, 129e6, 129M, 123Mi - sú prakticky rovnocenné.

Možnosť Kubernetes limits.memory zodpovedá vlajke --memory od spoločnosti Docker. V prípade request.memory Pre Docker nie je žiadna šípka, pretože Docker toto pole nepoužíva. Môžete sa opýtať, je to vôbec potrebné? Áno treba. Ako som už povedal, pre Kubernetes záleží na poli. Na základe informácií z neho sa kube-scheduler rozhodne, ktorý uzol naplánuje Pod.

Čo sa stane, ak nastavíte nedostatok pamäte pre požiadavku?

Ak kontajner dosiahol limity požadovanej pamäte, modul sa umiestni do skupiny modulov, ktoré sa zastavia, keď v uzle nie je dostatok pamäte.

Čo sa stane, ak limit pamäte nastavíte príliš nízko?

Ak kontajner prekročí limit pamäte, bude ukončený z dôvodu OOM-Killed. A reštartuje sa, ak je to možné, na základe RestartPolicy, kde je predvolená hodnota Always.

Čo sa stane, ak nešpecifikujete požadovanú pamäť?

Kubernetes vezme limitnú hodnotu a nastaví ju ako predvolenú hodnotu.

Čo sa môže stať, ak nešpecifikujete limit pamäte?

Kontajner nemá žiadne obmedzenia, môže použiť toľko pamäte, koľko chce. Ak začne využívať všetku dostupnú pamäť uzla, tak ho OOM zabije. Kontajner sa potom reštartuje, ak je to možné na základe RestartPolicy.

Čo sa stane, ak nešpecifikujete limity pamäte?

Toto je najhorší možný scenár: plánovač nevie, koľko zdrojov kontajner vyžaduje, a to môže spôsobiť vážne problémy v uzle. V tomto prípade by bolo pekné mať predvolené limity pre menný priestor (nastavené pomocou LimitRange). Neexistujú žiadne predvolené limity - Pod nemá žiadne limity, môže použiť toľko pamäte, koľko chce.

Ak je požadovaná pamäť väčšia, ako môže uzol ponúknuť, modul sa nenaplánuje. Je dôležité si to zapamätať Requests.memory - nie je minimálna hodnota. Toto je popis množstva pamäte postačujúcej na udržanie nepretržitého chodu kontajnera.

Zvyčajne sa odporúča nastaviť rovnakú hodnotu pre request.memory и limit.memory. To zaisťuje, že Kubernetes nenaplánuje modul na uzle, ktorý má dostatok pamäte na spustenie modulu, ale nie dostatok na jeho spustenie. Majte na pamäti: Plánovanie Kubernetes Pod berie do úvahy iba requests.memoryA limits.memory neberie do úvahy.

CPU: požiadavka a limit

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

S CPU je všetko trochu komplikovanejšie. Keď sa vrátime k obrázku vzťahu medzi Kubernetes a Dockerom, môžete to vidieť request.cpu zodpovedá --cpu-shares, keďže limit.cpu zodpovedá vlajke cpus v Dockeri.

CPU, ktoré Kubernetes požaduje, sa vynásobí 1024, čo je podiel cyklov CPU. Ak chcete požiadať o 1 celé jadro, musíte pridať cpu: 1ako je uvedené vyššie.

Požiadanie o úplné jadro (proporcia = 1024) neznamená, že ho váš kontajner dostane. Ak má váš hostiteľský počítač iba jedno jadro a máte spustených viac ako jeden kontajner, všetky kontajnery musia medzi sebou zdieľať dostupné CPU. Ako sa to stane? Pozrime sa na obrázok.

Požiadavka CPU – jednojadrový systém

Predstavme si, že máte jednojadrový hostiteľský systém s kontajnermi. Mama (Kubernetes) upiekla koláč (CPU) a chce ho rozdeliť medzi deti (nádoby). Tri deti chcú celý koláč (pomer = 1024), ďalšie dieťa chce polovicu koláča (512). Mama chce byť spravodlivá a robí 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 dostanú tri deti 28% jadra, a nie celé jadro. Štvrté dieťa dostane 14 % z celého jadra, nie polovicu. Ale veci budú iné, ak máte viacjadrový systém.

Požiadavka CPU – viacjadrový (4) systém

Na obrázku vyššie vidíte, že tri deti chcú celý koláč a jedno chce polovicu. Keďže mama upiekla štyri koláče, každé z jej detí ich dostane koľko chce. Vo viacjadrovom systéme sú prostriedky procesora rozdelené medzi všetky dostupné jadrá procesorov. 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é, aby ste pochopili, ako je CPU rozdelený medzi kontajnery. Samozrejme, okrem samotných kontajnerov existujú aj iné procesy, ktoré tiež využívajú prostriedky CPU. Keď sú procesy v jednom kontajneri nečinné, ostatné môžu využívať jeho zdroj. CPU: "200m" zodpovedá CPU: 0,2, čo znamená približne 20 % jedného jadra.

Teraz si pohovorme o limit.cpu. CPU, ktoré Kubernetes obmedzuje, sa vynásobí 100. Výsledkom je množstvo času, ktorý môže kontajner využiť každých 100 µs (cpu-period).

limit.cpu sa zhoduje s vlajkou Docker --cpus. Toto je nová kombinácia starého --cpu-period и --cpu-quota. Jeho nastavením uvádzame, koľko dostupných zdrojov CPU môže kontajner maximálne využiť pred začatím obmedzovania:

procesory - kombinácia cpu-period и cpu-quota. cpus = 1.5 ekvivalentné nastaveniu cpu-period = 100000 и cpu-quota = 150000;
CPU-obdobie - bodka Plánovač CPU CFS, predvolených 100 mikrosekúnd;
cpu-kvóta - počet mikrosekúnd vo vnútri cpu-period, ktorý je ohraničený kontajnerom.

Čo sa stane, ak nainštalujete nedostatočný požadovaný procesor?

Ak kontajner potrebuje viac, ako má nainštalovaný, ukradne CPU z iných procesov.

Čo sa stane, ak limit CPU nastavíte príliš nízko?

Keďže zdroj CPU je nastaviteľný, škrtenie sa zapne.

Čo sa stane, ak nezadáte požiadavku CPU?

Rovnako ako v prípade pamäte sa hodnota požiadavky rovná limitu.

Čo sa stane, ak nešpecifikujete limit CPU?

Kontajner bude využívať toľko CPU, koľko potrebuje. Ak je v mennom priestore definovaná predvolená politika CPU (LimitRange), potom sa tento limit použije aj pre kontajner.

Čo sa stane, ak nešpecifikujete požiadavku ani limit CPU?

Podobne ako pri pamäti, aj tu ide o najhorší scenár. Plánovač nevie, koľko zdrojov potrebuje váš kontajner, a to môže spôsobiť vážne problémy v uzle. Aby ste tomu zabránili, musíte nastaviť predvolené limity pre menné priestory (LimitRange).

Pamätajte: ak požadujete viac CPU, ako môžu poskytnúť uzly, modul nebude naplánovaný. Requests.cpu - nie minimálna hodnota, ale hodnota dostatočná na spustenie modulu a fungovanie bez porúch. Ak aplikácia nevykonáva zložité výpočty, najlepšou možnosťou je inštalácia request.cpu <= 1 a spustite toľko replík, koľko je potrebné.

Ideálne množstvo požadovaných zdrojov alebo limit zdrojov

Dozvedeli sme sa o obmedzenosti výpočtových zdrojov. Teraz je čas odpovedať na otázku: „Koľko zdrojov potrebuje môj modul na bezproblémové spustenie aplikácie? Aká je ideálna suma?

Bohužiaľ, na tieto otázky neexistujú jednoznačné odpovede. Ak neviete, ako vaša aplikácia funguje alebo koľko CPU alebo pamäte potrebuje, najlepšou možnosťou je dať aplikácii veľa pamäte a CPU a potom spustiť testy výkonu.

Okrem testov výkonu sledujte týždeň aj správanie aplikácie v monitoringu. Ak grafy naznačujú, že vaša aplikácia spotrebováva menej zdrojov, ako ste požadovali, môžete znížiť požadované množstvo CPU alebo pamäte.

Ako príklad pozri toto Palubná doska Grafana. Zobrazuje rozdiel medzi požadovanými zdrojmi alebo limitom zdrojov a aktuálnym využitím prostriedkov.

Záver

Vyžiadanie a obmedzenie zdrojov pomáha udržiavať váš klaster Kubernetes zdravý. Správna konfigurácia limitov minimalizuje náklady a udržuje aplikácie neustále spustené.

Stručne povedané, je potrebné mať na pamäti niekoľko vecí:

Požadované zdroje sú konfiguráciou, ktorá sa berie do úvahy pri spustení (keď Kubernetes plánuje hostiť aplikáciu). Naproti tomu obmedzenie zdrojov je dôležité pri behu – keď už aplikácia beží na uzle.
V porovnaní s pamäťou je CPU regulovaný zdroj. Ak nie je dostatok CPU, váš Pod sa nevypne a zapne sa škrtiaci mechanizmus.
Požadované zdroje a limit zdrojov nie sú minimálne a maximálne hodnoty! Definovaním požadovaných prostriedkov zaistíte, že aplikácia bude bežať bez problémov.
Dobrou praxou je nastaviť požiadavku na pamäť rovnú pamäťovému limitu.
Vyžiadaná inštalácia v poriadku CPU <=1, ak aplikácia nevykonáva zložité výpočty.
Ak požadujete viac zdrojov, ako je k dispozícii na uzle, modul sa nikdy nenaplánuje do tohto uzla.
Na určenie správneho množstva požadovaných zdrojov/limitov prostriedkov použite testovanie záťaže a monitorovanie.

Dúfam, že vám tento článok pomôže pochopiť základný koncept obmedzenia zdrojov. A tieto poznatky budete môcť uplatniť vo svojej práci.

Good Luck!

Čo ešte čítať:

Zdroj: hab.com

Ako získať prístup k zdrojom Kubernetes Pod