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

Poznámka:

Tento článek se zaměřuje na obecné osvědčené postupy pro malé až střední úlohy. Nejlepší postupy pro specifické velké zátěže najdete v nejlepších postupech pro výkon a škálování velkých zátěží v 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:

  • 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ů
  • Úvahy o úložišti a síťování pro výkon datové roviny.

Důležité

Počínaje 30. listopadu 2025 Azure Kubernetes Service (AKS) už nepodporuje a neposkytuje aktualizace zabezpečení pro Azure Linux 2.0. Image uzlu Azure Linux 2.0 je zmrazen na verzi 202512.06.0. Od 31. března 2026 se image uzlů odeberou a nebudete moct škálovat fondy uzlů. Migrace na podporovanou verzi Azure Linuxu provedením aktualizací fondů uzlů na podporovanou verzi Kubernetes nebo migrací na osSku AzureLinux3. Další informace najdete v problému GitHub o vyřazení a oznámení o vyřazení Azure aktualizací. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS.

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álovatelnost 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.

Upozornění

Neměli byste používat VPA ve spojení s HPA na stejných metrikách procesoru nebo paměti. Tato kombinace může vést ke konfliktům, protože oba automatické škálovače se 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 škálováním nahoru a nasazová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í.

Přidělení nadbytečných zdrojů

Předimenzování je strategie, která pomáhá zmírnit riziko zatížení aplikace tím, že zajišťuje 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% rezervu pro zachování bezpečnostní rezervy. Pokud očekáváte průměrnou míru růstu provozu o 40 %, můžete zvážit předimenzování o 50 %, podle vzorce:

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

Efektivní metoda nadsazení zahrnuje použití pozastavovacích podů. Pody, které lze pozastavit, jsou nasazení s nízkou prioritou, která se dají snadno nahradit nasazením 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 prostor, pauzovací pody jsou odebrány a přeplánovány na jiném uzlu nebo na novém uzlu, aby vyhověly 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ů.

Obrázky uzlů

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

Použijte nejnovější verzi image uzlu, abyste zajistili, že máte nejnovější opravy zabezpečení a opravy chyb.

Použití nejnovější verze obrazu uzlu zajistí nejlepší výkon. AKS dodává vylepšení výkonu v týdenních verzích imagí. Nejnovější obrazy daemonsetu jsou uložené v mezipaměti na nejnovějším VHD obraze, což poskytuje výhody v podobě nižší latence při zřizování a inicializaci 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 kontejnerů Azure Linux v AKS používá nativní image AKS a poskytuje jednotné prostředí pro vývoj na Linuxu. 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ů. V základní vrstvě má jádro zabezpečené společností Microsoft optimalizované pro Azure. Tento obraz je ideální pro úlohy citlivé na výkon a platformní inženýry nebo operátory, kteří spravují sady 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á Microsoft, Canonical a komunitou Ubuntu a pomůže vám 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žijte vyhrazené pooly 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 zatížení aplikace pak může běžet ve fondu uzlů pro uživatele, aby se zvýšila dostupnost alokovatelných prostředků pro vaši aplikaci. Tato konfigurace také pomáhá zmírnit riziko konkurence prostředků mezi systémem a aplikací.

Vytvořit operace

Zkontrolujte rozšíření a doplňky, které jste povolili během procesu 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 pro prostředek, API server vám pošle aktualizace při změnách tohoto prostředku. To je důležité pro kontrolery, jako je například kontroler ReplicaSet, který spoléhá na WATCH, aby udržoval 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í zdroj 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ší.
* Lze použít více 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é PrioritLevelConfiguration.
* Lze použít k nastavení pořadí vyhodnocení, pokud více FlowSchemas odpovídá požadavku, aby se zajistilo, že určitá pravidla mají 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 netrpí nedostatkem prostředků ani se 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 v Kubernetes zahrnují akce, které spravují a upravují prostředky clusteru.

Operace vytvoření a aktualizace

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 Azure úložiště, jako jsou spravované disky operačního systému. Mají rychlejší přeinstalaci a dobu 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ů agentů AKS. Dočasné disky s operačním systémem fungují dobře pro bezstavové úlohy, kde jsou aplikace odolné vůči selhání jednotlivých virtuálních počítačů, ale ne vůči času nasazení nebo přeinstalaci jednotlivých instancí 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 v 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ě v 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í
Efemérní OS disky * Rychlejší opakované načítání a spouštění.
* Nižší latence čtení a zápisu na systémovém disku agentových uzlů 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.
SSD disky pro OS ú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.
* Podnikové úlohy náročné na vstupně-výstupní operace (I/O).
Standardní SSD disky pro OS * 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í
Standardní HDD * Nízké náklady.
* Vykazuje proměnlivost výkonu a latence.		 * Úložiště záloh.
* Velkokapacitní úložiště s málo č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 operačního systému na portálu Azure:

  1. Přejděte na portál Azure.
  2. Vyhledejte škálovací sady virtuálních počítačů a vyberte svou š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 operačního systému pro virtuální počítače Azure.

Azure Premium SSD v2 je určená pro podnikové úlohy náročné na IO operace, které vyžadují latenci disků pod jednu milisekundu 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ší. Aktuálně je tento typ disku nejvýkonnější volbou, která je k dispozici pro trvalé svazky.

Výkon rozlišení DNS

Latence překladu DNS přímo ovlivňuje dobu odezvy aplikací, zejména u architektur s mikroslužbami, kde si služby často navzájem rozpoznávají své názvy. Povolte LocalDNS ve fondech uzlů k nasazení DNS proxy pro jednotlivé uzly, která překládá dotazy lokálně a snižuje počet síťových skoků, čímž omezuje tlak na conntrack tabulky. LocalDNS také podporuje zastaralé odpovědi uložené v mezipaměti během výpadků upstreamu DNS, což pomáhá udržovat připojení k úlohám. Další informace najdete v tématu Řešení DNS v AKS.

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 dojít ke zpomalení nebo dokonce ke zhroucení 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říč vašimi úlohami ve srovnání s celkovými přidělitelnými prostředky pro nejlepší předvídatelnost plánování a výkon. Můžete také nastavit maximální počet podů na uzel na základě plánování kapacity pomocí --max-pods.

  • Last updated on