🥇Jak získat přístup ke zdrojům Kubernetes Pod

Odměna od Tohada

Když začínáte s Kubernetes, je běžné, že zapomenete na nastavení prostředků kontejneru. V tuto chvíli se stačí ujistit, že obraz Dockeru funguje a lze jej nasadit do clusteru Kubernetes.

Ale pozdější aplikace musí být nasazena do produkčního clusteru spolu s dalšími aplikacemi. Chcete-li to provést, musíte alokovat prostředky pro kontejner a ujistit se, že je jich dostatek pro spuštění a spuštění aplikace a nebudou žádné problémy v jiných spuštěných aplikacích.

Tým Kubernetes aaS z Mail.ru přeložil článek o zdrojích kontejnerů (CPU a MEM), požadavcích na zdroje a limitech. Dozvíte se, jaké výhody tato nastavení poskytují a co se stane, pokud nebudou nastavena.

Výpočetní zdroje

Máme dva typy zdrojů s následujícími jednotkami:

Centrální procesorová jednotka (CPU) - jádra;
Paměť (MEM) - bajty.

Pro každý kontejner jsou specifikovány zdroje. V následujícím souboru pod YAML uvidíte sekci zdrojů, která obsahuje požadované a omezené zdroje:

Pod Resources Requested = součet požadovaných zdrojů všech podů;
Limit zdroje podu = součet všech limitů zdroje 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

Příklad požadovaných a limitních zdrojů

Pole resources.requested ze specifikace Pod - jeden z prvků, který slouží k nalezení požadovaného uzlu. Už na něm můžete naplánovat nasazení pod. Jak najdete vhodný uzel?

Kubernetes se skládá z několika komponent, včetně hlavního uzlu nebo hlavního uzlu (Kubernetes Control Plane). V hlavním uzlu je několik procesů: kube-apiserver, kube-controller-manager a kube-scheduler.

Proces plánovače kube je zodpovědný za prohlížení nově vytvořených podů a hledání možných pracovních uzlů, které odpovídají všem požadavkům podů, včetně počtu požadovaných zdrojů. Seznam uzlů nalezených plánovačem kube je seřazen. Pod je naplánován na uzel s nejvyšším skóre.

Kde bude umístěn fialový pod?

Obrázek ukazuje, že plánovač kube potřebuje naplánovat nový fialový pod. Cluster Kubernetes obsahuje dva uzly: A a B. Jak vidíte, kube-scheduler nemůže naplánovat Pod do uzlu A – dostupné (nevyžádané) zdroje neodpovídají požadavkům fialového Podu. Například 1 GB paměti požadované fialovou podložkou se nevejde do uzlu A, protože dostupná paměť je 0,5 GB. Ale uzel B má dostatek zdrojů. Nakonec kube-scheduler rozhodne, že cílem fialového podu je uzel B.

Nyní víme, jak požadované zdroje ovlivňují výběr uzlu pro spuštění podu. Jaký je však účinek mezních zdrojů?

Limit prostředků je limit, který CPU/MEM nemůže překročit. Zdroj CPU je však flexibilní, takže kontejnery, které narazí na limity CPU, nezpůsobí vypnutí modulu. Místo toho se spustí omezení CPU. Pokud je dosaženo limitu MEM, kontejner bude zastaven kvůli OOM-Killer a restartován, pokud to umožňuje nastavení RestartPolicy.

Požadované a omezené zdroje podrobně

Propojení prostředků mezi Dockerem a Kubernetes

Nejlepší způsob, jak vysvětlit, jak fungují požadované limity a limity zdrojů, je představit si vztah mezi Kubernetes a Dockerem. Na obrázku výše můžete vidět, jak spolu souvisí pole Kubernetes a příznaky spuštění Dockeru.

Paměť: požadavek a limit

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

Jak bylo uvedeno výše, paměť se měří v bajtech. Na základě Dokumentace Kubernetes, můžeme paměť specifikovat jako číslo. Obvykle je to celé číslo, například 2678 - tedy 2678 bajtů. Můžete také použít přípony G и Gi, hlavní věcí je mít na paměti, že nejsou ekvivalentní. První je dekadický a druhý je binární. Jako příklad uvedený v dokumentaci k8s: 128974848, 129e6, 129M, 123Mi — jsou prakticky rovnocenné.

Parametr Kubernetes limits.memory odpovídá vlajce --memory od společnosti Docker. V případě request.memory pro Docker není žádná šipka, protože Docker toto pole nepoužívá. Můžete se zeptat, zda je to vůbec nutné? Ano potřeba. Jak jsem řekl dříve, na poli záleží Kubernetes. Na základě informací z něj se kube-scheduler rozhodne, kterému uzlu naplánovat Pod.

Co se stane, když pro požadavek není dostatek paměti?

Pokud kontejner dosáhl limitů požadované paměti, pak se modul umístí do skupiny modulů, které se zastaví, když v uzlu není dostatek paměti.

Co se stane, když limit paměti nastavíte příliš nízko?

Pokud kontejner překročí limit paměti, bude ukončen kvůli OOM-Killed. A bude restartován pokud možno na základě RestartPolicy, kde je výchozí hodnota Always.

Co se stane, pokud nezadáte požadovanou paměť?

Kubernetes převezme limit a nastaví jej jako výchozí.

Co se může stát, pokud neurčíte limit paměti?

Kontejner nemá žádné limity, může používat tolik paměti, kolik chce. Pokud začne využívat veškerou dostupnou paměť uzlu, pak ho OOM zabije. Kontejner bude poté restartován, pokud je to možné na základě RestartPolicy.

Co se stane, pokud neurčíte limity paměti?

Toto je nejhorší scénář: plánovač neví, kolik zdrojů kontejner potřebuje, a to může způsobit vážné problémy na uzlu. V tomto případě by bylo hezké mít ve jmenném prostoru výchozí limity (nastavené LimitRange). Bez výchozího limitu - Pod nemá žádný limit, může používat tolik paměti, kolik chce.

Pokud je požadovaná paměť větší, než může uzel nabídnout, modul nebude naplánován. Je důležité si to pamatovat Requests.memory není minimální hodnota. Toto je popis velikosti paměti, která je dostatečná k tomu, aby kontejner neustále běžel.

Obecně se doporučuje nastavit stejnou hodnotu pro request.memory и limit.memory. To zabrání Kubernetes naplánovat Pod na uzlu, který má dostatek paměti ke spuštění Podu, ale málo ke spuštění. Mějte na paměti, že plánování Kubernetes Pod bere v úvahu pouze requests.memorya limits.memory nebere v úvahu.

CPU: požadavek a limit

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

S CPU jsou věci trochu složitější. Když se vrátíme k obrázku se vztahem mezi Kubernetes a Dockerem, můžete to vidět request.cpu odpovídá --cpu-shares, zatímco limit.cpu odpovídá vlajce cpus v Dockeru.

CPU požadovaný Kubernetes se vynásobí 1024, což je podíl cyklů CPU. Pokud chcete požádat o 1 plné jádro, musíte přidat cpu: 1jak je uvedeno výše.

Požadavek na plné jádro (proporce = 1024) neznamená, že jej váš kontejner obdrží. Pokud má váš hostitelský počítač pouze jedno jádro a používáte více než jeden kontejner, pak všechny kontejnery musí sdílet dostupný CPU mezi sebou. Jak se to stane? Podívejme se na obrázek.

Požadavek CPU – jednojádrový systém

Představme si, že máte jeden hlavní hostitelský systém s kontejnery. Máma (Kubernetes) upekla koláč (CPU) a chce se o něj podělit mezi své děti (nádoby). Tři děti chtějí celý koláč (poměr = 1024), další dítě chce polovinu koláče (512). Máma chce být spravedlivá a provede 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ákladě výpočtu dostanou tři děti 28 % jádra a ne celé jádro. Čtvrté dítě dostane 14 % plného jádra, nikoli polovinu. Ale věci budou jiné, pokud máte vícejádrový systém.

Požadavek CPU – vícejádrový (4) systém

Na obrázku výše můžete vidět, že tři děti chtějí celý koláč a jedno chce polovinu. Protože máma upekla čtyři koláče, každé z jejích dětí jich dostane, kolik chce. Ve vícejádrovém systému jsou prostředky procesoru rozděleny mezi všechna dostupná jádra procesorů. Pokud je kontejner omezen na méně než jedno celé jádro CPU, může jej stále využívat na 100 %.

Výše uvedené výpočty jsou zjednodušené, aby bylo možné pochopit, jak je CPU sdílen mezi kontejnery. Kromě samotných kontejnerů samozřejmě existují další procesy, které také využívají prostředky CPU. Když jsou procesy v jednom kontejneru nečinné, ostatní mohou využívat jeho prostředky. CPU: "200m" odpovídá CPU: 0,2, což znamená přibližně 20 % jednoho jádra.

Nyní si promluvme o limit.cpu. Procesor omezující Kubernetes se vynásobí 100. Výsledkem je doba, kterou může kontejner využít každých 100 µs (cpu-period).

limit.cpu odpovídá vlajce Docker --cpus. Je to nová kombinace starého --cpu-period и --cpu-quota. Jeho nastavením určíme, kolik dostupných zdrojů CPU může kontejner maximálně využít, dokud se nespustí omezení:

cpus - kombinace cpu-period и cpu-quota. cpus = 1.5 je ekvivalentní nastavení cpu-period = 100000 и cpu-quota = 150000;
cpu-období - doba Plánovač CPU CFS, výchozí 100 mikrosekund;
cpu-kvóta je počet mikrosekund uvnitř cpu-periodKe kterému je kontejner omezen.

Co se stane, když nainstalujete nedostatečně požadovaný procesor?

Pokud kontejner potřebuje více, než je nastaveno, ukradne CPU jiným procesům.

Co se stane, když nastavíte nedostatečný limit CPU?

Protože je zdroj CPU nastavitelný, zapne se omezení.

Co se stane, když nezadáte požadavek CPU?

Stejně jako v případě paměti je hodnota požadavku rovna limitu.

Co se stane, pokud neurčíte limit CPU?

Kontejner bude využívat tolik CPU, kolik potřebuje. Pokud je ve jmenném prostoru definována výchozí zásada CPU (LimitRange), pak se tento limit použije také pro kontejner.

Co se stane, pokud není zadán požadavek ani limit CPU?

Stejně jako u paměti je to nejhorší možný scénář. Plánovač neví, kolik zdrojů váš kontejner potřebuje, a to může způsobit vážné problémy na uzlu. Abyste tomu zabránili, musíte nastavit výchozí limity pro jmenné prostory (LimitRange).

Pamatujte, že pokud požadujete více CPU, než mohou uzly poskytnout, modul nebude naplánován. Requests.cpu - ne minimální hodnota, ale hodnota postačující ke spuštění podu a práci bez poruch. Pokud aplikace neprovádí složité výpočty, je nejlepší možností instalace request.cpu <= 1 a spustit tolik replik, kolik je potřeba.

Ideální množství požadovaných zdrojů nebo limit zdrojů

Dozvěděli jsme se o omezení výpočetních zdrojů. Nyní je čas odpovědět na otázku: „Kolik zdrojů potřebuje můj Pod k bezproblémovému běhu aplikace? Jaká je ideální částka?

Na tyto otázky bohužel neexistují jednoznačné odpovědi. Pokud nevíte, jak vaše aplikace funguje, kolik CPU nebo paměti potřebuje, nejlepší možností je dát aplikaci hodně paměti a CPU a poté spustit benchmarky.

Kromě testů výkonu sledujte během týdne chování aplikace při sledování. Pokud grafy ukazují, že vaše aplikace spotřebovává méně zdrojů, než jste požadovali, můžete snížit požadované množství CPU nebo paměti.

Příklad viz toto Palubní deska Grafana. Zobrazuje rozdíl mezi požadovanými zdroji nebo limitem zdrojů a aktuálním využitím zdrojů.

Závěr

Požadavek na prostředky a limit pomáhají udržovat cluster Kubernetes zdravý. Správná konfigurace limitů minimalizuje náklady a udržuje aplikace neustále v provozu.

Stručně řečeno, je třeba mít na paměti několik věcí:

Požadované zdroje – konfigurace, která se bere v úvahu při spuštění (když Kubernetes plánuje hostovat aplikaci). Naproti tomu omezení zdrojů je důležité za běhu – když aplikace již běží na hostiteli.
Ve srovnání s pamětí je CPU regulovaný zdroj. V případě nedostatku CPU se váš Pod nevypne, zapne se škrtící mechanismus.
Požadované zdroje a limit zdroje nejsou minimální a maximální hodnoty! Zadáním zdrojů, které mají být požadovány, zajistíte hladký chod aplikace.
Je dobrým zvykem nastavit požadavek na paměť rovnající se limitu paměti.
Dobrá instalace požadována CPU <=1pokud aplikace neprovádí složité výpočty.
Pokud požadujete více prostředků, než má uzel, pod se nikdy nenaplánuje pro tento uzel.
Použijte zátěžové testování a monitorování k určení správného množství požadovaných zdrojů/limitů zdrojů.

Doufám, že vám tento článek pomůže pochopit základní koncept omezování zdrojů. A tyto znalosti můžete uplatnit ve své práci.

Good Luck!

Co ještě číst:

Zdroj: www.habr.com

Jak získat přístup ke zdrojům Kubernetes Pod