Sdílet prostřednictvím

Osvědčené postupy pro výkon a škálování pro malé až střední úlohy ve službě Azure Kubernetes Service (AKS)

  • Článek

Poznámka:

Tento článek se zaměřuje na obecné osvědčené postupy pro malé až střední úlohy. Osvědčené postupy specifické pro velké úlohy najdete v tématu Osvědčené postupy týkající se výkonu a škálování pro velké úlohy ve službě Azure Kubernetes Service (AKS).

Při nasazování a údržbě clusterů v AKS můžete použít následující osvědčené postupy, které vám pomůžou optimalizovat výkon a škálování.

V tomto článku se dozvíte o těchto článcích:

  • Kompromisy a doporučení pro automatické škálování úloh
  • Správa škálování a efektivity uzlů na základě požadavků vašich úloh
  • Důležité informace o sítích pro příchozí a odchozí provoz
  • Monitorování a řešení potíží s výkonem řídicí roviny a uzlu
  • Plánování kapacity, scénáře nárůstu kapacity a upgrady clusterů
  • Důležité informace o úložišti a sítích pro výkon roviny dat

Automatické škálování aplikací vs. automatické škálování infrastruktury

Automatické škálování aplikace

Automatické škálování aplikací je užitečné při řešení omezení nákladů nebo infrastruktury. Dobře nakonfigurovaný automatický nástroj pro škálování udržuje vysokou dostupnost vaší aplikace a zároveň minimalizuje náklady. Platíte jenom za prostředky potřebné k udržení dostupnosti bez ohledu na poptávku.

Pokud má například existující uzel místo, ale nemá dostatek IP adres v podsíti, může být možné přeskočit vytvoření nového uzlu a místo toho okamžitě spustit aplikaci na novém podu.

Horizontální automatické škálování podů

Implementace horizontálního automatického škálování podů je užitečná pro aplikace s stabilní a předvídatelnou poptávkou po prostředcích. Horizontální automatické škálování podů (HPA) dynamicky škáluje počet replik podů, které efektivně distribuují zatížení mezi několik podů a uzlů. Tento mechanismus škálování je obvykle nejvhodnější pro aplikace, které je možné rozdělit do menších nezávislých komponent schopných paralelně běžet.

HpA ve výchozím nastavení poskytuje metriky využití prostředků. Můžete také integrovat vlastní metriky nebo využít nástroje, jako je automatické škálování řízené událostmi Kubernetes (KEDA) (Preview). Díky těmto rozšířením může HPA rozhodovat o škálování na základě různých perspektiv a kritérií, což poskytuje komplexnější pohled na výkon vaší aplikace. To je užitečné zejména pro aplikace s různými složitými požadavky na škálování.

Poznámka:

Pokud je udržování vysoké dostupnosti pro vaši aplikaci nejvyšší prioritou, doporučujeme ponechat mírně vyšší vyrovnávací paměť pro minimální počet podů, aby vaše HPA zohlednila dobu škálování.

Vertikální automatické škálování podů

Implementace vertikálního automatického škálování podů je užitečná pro aplikace s proměnlivými a nepředvídatelnými požadavky na prostředky. Vertikální automatické škálování podů (VPA) umožňuje vyladit požadavky na prostředky, včetně procesoru a paměti, pro jednotlivé pody, což umožňuje přesnou kontrolu nad přidělením prostředků. Tato členitost minimalizuje plýtvání zdroji a zvyšuje celkovou efektivitu využití clusteru. VPA také zjednodušuje správu aplikací tím, že automatizuje přidělování prostředků a uvolní prostředky pro kritické úlohy.

Upozorňující

Ve spojení s HPA byste neměli používat stejnou metriku procesoru nebo paměti. Tato kombinace může vést ke konfliktům, protože se oba automatické škálování pokusí reagovat na změny v poptávce pomocí stejných metrik. Pokud ale chcete zabránit překrývání a zajistit, aby se jednotlivé automatické škálování zaměřovaly na různé aspekty škálování úloh, můžete použít VPA pro procesor nebo paměť ve spojení s hpA pro vlastní metriky.

Poznámka:

VPA funguje na základě historických dat. Doporučujeme počkat aspoň 24 hodin po nasazení analyzátoru osvědčených údajů, než použijete jakékoli změny, abyste mohli shromáždit data doporučení.

Automatické škálování infrastruktury

Automatické škálování clusteru

Implementace automatického škálování clusteru je užitečná, pokud stávající uzly nemají dostatečnou kapacitu, protože pomáhá se vertikálním navýšením a zřizováním nových uzlů.

Při zvažování automatického škálování clusteru se rozhodnutí o odebrání uzlu týká kompromisu mezi optimalizací využití prostředků a zajištěním dostupnosti prostředků. Eliminování nevyužitých uzlů vylepšuje využití clusteru, ale může vést k tomu, že nové úlohy musí čekat, než se prostředky zřídí, než je možné je nasadit. Je důležité najít rovnováhu mezi těmito dvěma faktory, které odpovídají požadavkům vašeho clusteru a úloh a odpovídajícím způsobem nakonfigurovat nastavení profilu automatického škálování clusteru.

Nastavení profilu automatického škálování clusteru se obecně vztahuje na všechny fondy uzlů s podporou automatického škálování ve vašem clusteru. To znamená, že všechny akce škálování, ke kterým dochází v jednom fondu uzlů s podporou automatického škálování, můžou ovlivnit chování automatického škálování v jiném fondu uzlů. Je důležité použít konzistentní a synchronizovaná nastavení profilu ve všech příslušných fondech uzlů, aby se zajistilo, že se automatické škálování chová podle očekávání.

Nadměrné zřízení

Nadměrné zřizování je strategie, která pomáhá zmírnit riziko tlaku aplikace tím, že zajišťuje, že existuje nadbytek snadno dostupných prostředků. Tento přístup je zvlášť užitečný pro aplikace, které mají zkušenosti s vysoce proměnlivým zatížením a vzory škálování clusteru, které zobrazují časté vertikální navýšení a snížení kapacity.

K určení optimálního množství nadměrného zřízení můžete použít následující vzorec:

1-buffer/1+traffic

Řekněme například, že chcete zabránit dosažení 100% využití procesoru v clusteru. Můžete se rozhodnout pro 30% vyrovnávací paměť pro zachování bezpečnostní marže. Pokud očekáváte průměrnou míru růstu provozu 40 %, můžete zvážit nadměrné zřízení o 50 %, jak je vypočítáno vzorcem:

1-30%/1+40%=50%

Efektivní metoda nadměrného zřízení zahrnuje použití podů pozastavení. Pozastavit pody jsou nasazení s nízkou prioritou, která se dají snadno nahradit nasazeními s vysokou prioritou. Vytvoříte pody s nízkou prioritou, které slouží výhradně k rezervaci prostoru vyrovnávací paměti. Pokud pod s vysokou prioritou vyžaduje mezeru, odeberou se pody pozastavení a přeplánují na jiném uzlu nebo na novém uzlu, aby vyhovovaly podu s vysokou prioritou.

Následující YAML ukazuje příklad manifestu podu pozastavení:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Škálování a efektivita uzlů

Pokyny k osvědčeným postupům:

Pečlivě monitorujte zásady využití prostředků a plánování, abyste zajistili efektivní používání uzlů.

Škálování uzlů umožňuje dynamicky upravit počet uzlů v clusteru na základě požadavků na úlohy. Je důležité si uvědomit, že přidání dalších uzlů do clusteru není vždy nejlepším řešením pro zlepšení výkonu. Abyste zajistili optimální výkon, měli byste pečlivě monitorovat využití prostředků a zásady plánování, abyste zajistili efektivní používání uzlů.

Image uzlů

Pokyny k osvědčeným postupům:

Pomocí nejnovější verze image uzlu se ujistěte, že máte nejnovější opravy zabezpečení a opravy chyb.

Použití nejnovější verze image uzlu poskytuje nejlepší výkon. AKS dodává vylepšení výkonu v týdenních verzích imagí. Nejnovější image démona jsou uložené v mezipaměti na nejnovější imagi virtuálního pevného disku, což poskytuje nižší výhody latence pro zřizování a spouštění uzlů. Pokles aktualizací může mít negativní dopad na výkon, takže je důležité se vyhnout velkým mezerám mezi verzemi.

Azure Linux

Hostitel kontejneru Azure Linux v AKS používá nativní image AKS a poskytuje jediné místo pro vývoj pro Linux. Každý balíček je sestavený ze zdroje a ověřen a zajišťuje, aby vaše služby běžely na ověřených součástech.

Azure Linux je jednoduchý, zahrnuje pouze potřebnou sadu balíčků pro spouštění úloh kontejneru. Poskytuje menší prostor pro útoky a eliminuje opravy a údržbu nepotřebných balíčků. Ve své základní vrstvě má jádro posílené Microsoftem vyladěné pro Azure. Tato image je ideální pro úlohy citlivé na výkon a techniky platformy nebo operátory, kteří spravují flotily clusterů AKS.

Ubuntu 2204

Image Ubuntu 2204 je výchozí image uzlu pro AKS. Jedná se o jednoduchý a efektivní operační systém optimalizovaný pro spouštění kontejnerizovaných úloh. To znamená, že může pomoct snížit využití prostředků a zlepšit celkový výkon. Image obsahuje nejnovější opravy zabezpečení a aktualizace, které pomáhají zajistit ochranu vašich úloh před ohroženími zabezpečení.

Image Ubuntu 2204 je plně podporovaná komunitou Microsoftu, Canonical a Ubuntu a může vám pomoct dosáhnout lepšího výkonu a zabezpečení pro kontejnerizované úlohy.

Virtuální počítače

Pokyny k osvědčeným postupům:

Při výběru virtuálního počítače se ujistěte, že velikost a výkon disku s operačním systémem a skladové položky virtuálního počítače nemají velký rozdíl. Nesrovnalosti ve velikosti nebo výkonu můžou způsobit problémy s výkonem a kolize prostředků.

Výkon aplikace je úzce svázaný se skladovými položkami virtuálních počítačů, které používáte ve svých úlohách. Větší a výkonnější virtuální počítače, obecně poskytují lepší výkon. Pro důležité úlohy nebo úlohy produktů doporučujeme používat virtuální počítače s alespoň 8jádrovým procesorem. Virtuální počítače s novějšími generacemi hardwaru, jako jsou verze 4 a v5, můžou také přispět ke zlepšení výkonu. Mějte na paměti, že latence vytváření a škálování se může lišit v závislosti na SKU virtuálních počítačů, které používáte.

Použití vyhrazených fondů systémových uzlů

Pro škálování výkonu a spolehlivosti doporučujeme použít vyhrazený fond systémových uzlů. Při této konfiguraci si vyhrazený fond systémových uzlů vyhrazuje místo pro důležité systémové prostředky, jako jsou démony operačního systému. Vaše úloha aplikace se pak může spustit ve fondu uzlů uživatele, aby se zvýšila dostupnost akocatovatelných prostředků pro vaši aplikaci. Tato konfigurace také pomáhá zmírnit riziko konkurence prostředků mezi systémem a aplikací.

Operace vytváření

Zkontrolujte rozšíření a doplňky, které jste povolili při vytváření zřizování. Rozšíření a doplňky můžou přidat latenci k celkové době trvání operací vytváření. Pokud rozšíření nebo doplněk nepotřebujete, doporučujeme ho odebrat, aby se zlepšila latence vytváření.

Zóny dostupnosti můžete použít také k zajištění vyšší úrovně dostupnosti, která chrání před potenciálními selháními hardwaru nebo událostmi plánované údržby. Clustery AKS distribuují prostředky napříč logickými oddíly základní infrastruktury Azure. Zóny dostupnosti fyzicky odděluje uzly od jiných uzlů, aby se zajistilo, že jedno selhání nemá vliv na dostupnost vaší aplikace. Zóny dostupnosti jsou dostupné jenom v určitých oblastech. Další informace najdete v tématu Zóny dostupnosti v Azure.

Server rozhraní API Kubernetes

Operace LIST a WATCH

Kubernetes používá operace LIST a WATCH k interakci se serverem rozhraní API Kubernetes a monitoruje informace o prostředcích clusteru. Tyto operace jsou zásadní pro to, jak Kubernetes provádí správu prostředků.

Operace LIST načte seznam prostředků, které odpovídají určitým kritériím, například všechny pody v určitém oboru názvů nebo všechny služby v clusteru. Tato operace je užitečná, když chcete získat přehled o prostředcích clusteru nebo potřebujete operátorovat více prostředků najednou.

Operace LIST může načítat velké objemy dat, zejména ve velkých clusterech s více prostředky. Mějte na paměti, že provádění nevázaných nebo častých volání LIST výrazně zatěžuje server rozhraní API a může dobu odezvy zavřít.

Operace WATCH provádí monitorování prostředků v reálném čase. Když nastavíte watch na prostředku, server rozhraní API vám pošle aktualizace vždy, když dojde ke změnám daného prostředku. To je důležité pro kontrolery, jako je například kontroler ReplicaSet, který spoléhá na watch, aby zachoval požadovaný stav prostředků.

Mějte na paměti, že sledování příliš velkého množství proměnlivých prostředků nebo vytváření příliš velkého počtu souběžných požadavků WATCH může zahltit server rozhraní API a způsobit nadměrnou spotřebu prostředků.

Pokud se chcete vyhnout potenciálním problémům a zajistit stabilitu řídicí roviny Kubernetes, můžete použít následující strategie:

Kvóty prostředků

Implementujte kvóty prostředků, abyste omezili počet prostředků, které můžou být uvedené nebo sledované konkrétním uživatelem nebo oborem názvů, aby se zabránilo nadměrným voláním.

Priorita a nestrannost rozhraní API

Kubernetes zavedl koncept priority a spravedlnosti rozhraní API (APF) pro stanovení priorit a správu požadavků rozhraní API. APF v Kubernetes můžete použít k ochraně serveru rozhraní API clusteru a snížení počtu HTTP 429 Too Many Requests odpovědí, které klientské aplikace vidí.

Vlastní prostředek Klíčové funkce
PriorityLevelConfigurations • Definujte různé úrovně priority pro požadavky rozhraní API.
• Určuje jedinečný název a přiřadí celočíselnou hodnotu představující úroveň priority. Vyšší úrovně priority mají nižší celočíselné hodnoty, což znamená, že jsou důležitější.
• Může použít více kategorií k kategorizaci požadavků do různých úrovní priority na základě jejich důležitosti.
• Umožňuje určit, zda mají být požadavky na konkrétní úrovni priority předmětem omezení četnosti.
FlowSchemas • Definujte, jak se mají požadavky rozhraní API směrovat na různé úrovně priority na základě atributů požadavků.
• Zadejte pravidla, která odpovídají požadavkům na základě kritérií, jako jsou skupiny rozhraní API, verze a prostředky.
• Pokud požadavek odpovídá danému pravidlu, požadavek se směruje na úroveň priority zadanou v přidružené prioritě PriorityLevelConfiguration.
• Lze použít k nastavení pořadí vyhodnocení, pokud více FlowSchemas odpovídá požadavku, aby určitá pravidla měli přednost.

Konfigurace rozhraní API pomocí PriorityLevelConfigurations a FlowSchemas umožňuje stanovení priorit kritických požadavků rozhraní API oproti méně důležitým požadavkům. Tím se zajistí, že základní operace nezpožďují zpoždění nebo nezpožďují kvůli žádostem s nižší prioritou.

Optimalizace popisků a selektorů

Při použití operací LIST optimalizujte selektory popisků, abyste zúžili rozsah prostředků, na které chcete dotazovat, aby se snížil objem vrácených dat a zatížení serveru rozhraní API.

Operace VYTVOŘENÍ a AKTUALIZACE Kubernetes odkazují na akce, které spravují a upravují prostředky clusteru.

Operace CREATE a UPDATE

Operace CREATE vytvoří nové prostředky v clusteru Kubernetes, jako jsou pody, služby, nasazení, mapy konfigurace a tajné kódy. Během operace CREATE klient, například kubectl kontroler, odešle požadavek na server rozhraní API Kubernetes, aby vytvořil nový prostředek. Server rozhraní API požadavek ověří, zajistí dodržování všech zásad kontroleru přístupu a pak vytvoří prostředek v požadovaném stavu clusteru.

Operace UPDATE upravuje existující prostředky v clusteru Kubernetes, včetně změn specifikací prostředků, jako je počet replik, image kontejnerů, proměnné prostředí nebo popisky. Během operace UPDATE klient odešle požadavek na server rozhraní API za účelem aktualizace existujícího prostředku. Server rozhraní API požadavek ověří, použije změny v definici prostředku a aktualizuje prostředek clusteru.

Operace CREATE a UPDATE můžou ovlivnit výkon serveru rozhraní API Kubernetes za následujících podmínek:

  • Vysoká souběžnost: Když více uživatelů nebo aplikací vytváří souběžné požadavky CREATE nebo UPDATE, může vést k nárůstu počtu požadavků rozhraní API přicházejících na server současně. To může tížit kapacitu zpracování serveru rozhraní API a způsobit problémy s výkonem.
  • Komplexní definice prostředků: Definice prostředků, které jsou příliš složité nebo zahrnují více vnořených objektů, můžou zvýšit dobu potřebnou k ověření a zpracování požadavků CREATE a UPDATE serveru rozhraní API, což může vést ke snížení výkonu.
  • Ověřování prostředků a řízení přístupu: Kubernetes vynucuje různé zásady řízení přístupu a kontroly ověřování u příchozích požadavků CREATE a UPDATE. Velké definice prostředků, jako jsou například rozsáhlé poznámky nebo konfigurace, můžou vyžadovat více času zpracování.
  • Vlastní kontrolery: Vlastní kontrolery, které sledují změny v prostředcích, jako jsou nasazení nebo kontrolery StatefulSet, můžou při škálování nebo zavádění změn generovat velký počet aktualizací. Tyto aktualizace můžou zatížit prostředky serveru rozhraní API.

Další informace najdete v tématu Řešení potíží se serverem rozhraní API a dalšími problémy v AKS.

Výkon roviny dat

Rovina dat Kubernetes zodpovídá za správu síťového provozu mezi kontejnery a službami. Problémy s rovinou dat můžou vést k pomalé době odezvy, snížení výkonu a výpadku aplikace. Je důležité pečlivě monitorovat a optimalizovat konfigurace roviny dat, jako je latence sítě, přidělování prostředků, hustota kontejnerů a zásady sítě, aby se zajistilo bezproblémové a efektivní spouštění kontejnerizovaných aplikací.

Typy úložiště

AKS doporučuje a ve výchozím nastavení používá dočasné disky s operačním systémem. Dočasné disky s operačním systémem se vytvářejí v místním úložišti virtuálního počítače a neukládají se do vzdáleného úložiště Azure, jako jsou spravované disky operačního systému. Mají rychlejší opakované načítání a spouštění, což umožňuje rychlejší operace clusteru a poskytují nižší latenci čtení a zápisu na disku s operačním systémem uzlů agenta AKS. Dočasné disky s operačním systémem fungují dobře pro bezstavové úlohy, kdy jsou aplikace odolné vůči selhání jednotlivých virtuálních počítačů, ale ne času nasazení virtuálního počítače nebo jednotlivých instancí opětovného vytváření virtuálních počítačů. Dočasné disky s operačním systémem podporují jenom určité skladové položky virtuálních počítačů, takže je potřeba zajistit, aby byla požadovaná generace a velikost skladové položky kompatibilní. Další informace najdete v tématu Dočasné disky s operačním systémem ve službě Azure Kubernetes Service (AKS).

Pokud vaše úloha nemůže používat dočasné disky s operačním systémem, AKS ve výchozím nastavení používá disky SSD úrovně Premium. Pokud disky SSD úrovně Premium nejsou kompatibilní s vaší úlohou, AKS ve výchozím nastavení používá disky SSD úrovně Standard. V současné době je jediným dostupným typem disku s operačním systémem HDD úrovně Standard. Další informace najdete v tématu Možnosti úložiště ve službě Azure Kubernetes Service (AKS).

Následující tabulka obsahuje rozpis navrhovaných případů použití disků s operačním systémem podporovaných v AKS:

Typ disku operačního systému Klíčové funkce Navrhované případy použití
Disky OS s kratší platností • Rychlejší opětovné načítání a spouštění.
• Nižší latence čtení a zápisu na disku s operačním systémem uzlů agenta AKS.
• Vysoký výkon a dostupnost.		 • Náročné podnikové úlohy, jako jsou SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite atd.
• Bezstavové produkční úlohy, které vyžadují vysokou dostupnost a nízkou latenci.
Disky SSD úrovně Premium • Konzistentní výkon a nízká latence.
• Vysoká dostupnost.		 • Náročné podnikové úlohy, jako jsou SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite atd.
• Vstupně-výstupní úlohy (V/V) náročné na podnikové úlohy.
Disky SSD úrovně Standard • Konzistentní výkon.
• Lepší dostupnost a latence oproti diskům HDD úrovně Standard.		 • Webové servery.
• Aplikační servery s nízkým vstupem a výstupem za sekundu (IOPS).
• Mírně používané podnikové aplikace.
• Úlohy vývoje/testování.
Disky HDD úrovně Standard • Nízké náklady.
• Vykazuje proměnlivost výkonu a latence.		 • Úložiště záloh.
• Velkokapacitní úložiště s méně častým přístupem.

IOPS a propustnost

Vstupně-výstupní operace za sekundu (IOPS) odkazuje na počet operací čtení a zápisu, které může disk provést za sekundu. Propustnost označuje množství dat, která je možné přenést v daném časovém období.

Disky operačního systému zodpovídají za ukládání operačního systému a souvisejících souborů a za spouštění aplikací zodpovídají virtuální počítače. Při výběru virtuálního počítače se ujistěte, že velikost a výkon disku s operačním systémem a skladové položky virtuálního počítače nemají velký rozdíl. Nesrovnalosti ve velikosti nebo výkonu můžou způsobit problémy s výkonem a kolize prostředků. Pokud je například disk s operačním systémem výrazně menší než virtuální počítače, může omezit množství místa dostupného pro data aplikací a způsobit, že systém nevyčerpá místo na disku. Pokud má disk s operačním systémem nižší výkon než virtuální počítače, může se stát kritickým bodem a omezit celkový výkon systému. Ujistěte se, že je velikost a výkon vyváženy, aby se zajistil optimální výkon v Kubernetes.

Pomocí následujících kroků můžete monitorovat IOPS a měřiče šířky pásma na discích s operačním systémem na webu Azure Portal:

  1. Přejděte na Azure Portal.
  2. Vyhledejte škálovací sady virtuálních počítačů a vyberte škálovací sadu virtuálních počítačů.
  3. V oblasti Monitorování vyberte Metriky.

Dočasné disky s operačním systémem můžou vaší aplikaci poskytovat dynamické IOPS a propustnost, zatímco spravované disky mají omezené IOPS a propustnost. Další informace najdete v tématu Dočasné disky s operačním systémem pro virtuální počítače Azure.

Azure Premium SSD v2 je navržený pro podnikové úlohy náročné na vstupně-výstupní operace, které vyžadují latence disků s nižšími milisekundami a vysokou IOPS a propustnost za nízkou cenu. Je vhodný pro širokou škálu úloh, jako jsou SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, velké objemy dat a analýzy, hry a další. Tento typ disku je aktuálně k dispozici pro trvalé svazky s nejvyšším výkonem.

Plánování podů

Prostředky paměti a procesoru přidělené virtuálnímu počítači mají přímý vliv na výkon podů spuštěných na virtuálním počítači. Při vytváření podu je přiřazeno určité množství paměti a prostředků procesoru, které se používají ke spuštění aplikace. Pokud virtuální počítač nemá k dispozici dostatek paměti nebo prostředků procesoru, může způsobit zpomalení nebo dokonce chybové ukončení podů. Pokud má virtuální počítač k dispozici příliš mnoho prostředků paměti nebo procesoru, může způsobit neefektivní spouštění podů, plýtvání prostředky a zvýšení nákladů. Doporučujeme monitorovat celkové požadavky na pody napříč úlohami s celkovými prostředky s možností přidělování, abyste dosáhli nejlepší předvídatelnosti a výkonu. Můžete také nastavit maximální počet podů na uzel na základě plánování kapacity pomocí --max-pods.