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

Poznámka:

Tento článek se zaměřuje na obecné osvědčené postupy pro velké úlohy. Osvědčené postupy specifické pro malé až střední úlohy najdete v tématu Osvědčené postupy týkající se výkonu a škálování pro malé až střední ú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í.

Mějte na paměti, že velký je relativní termín. Kubernetes má multidimenzionální obálku škálování a obálka škálování pro vaši úlohu závisí na prostředcích, které používáte. Například cluster s 100 uzly a tisíci podů nebo identifikátory CRD můžou být považovány za velké. Cluster 1 000 uzlů s 1 000 pody a různými dalšími prostředky může být z hlediska řídicí roviny považován za malý. Nejlepším signálem pro škálování řídicí roviny Kubernetes je míra úspěšnosti a latence požadavků HTTP serveru API, protože se jedná o proxy server pro množství zatížení řídicí roviny.

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

• Škálovatelnost řídicí roviny AKS a Kubernetes
• Osvědčené postupy klienta Kubernetes, včetně zpětného odvrácení, kukátek a stránkování
• Omezení rozhraní Azure API a platformy
• Omezení funkcí
• Osvědčené postupy škálování sítí a fondů uzlů

Škálovatelnost řídicí roviny AKS a Kubernetes

V AKS se cluster skládá ze sady uzlů (fyzických nebo virtuálních počítačů), na kterých běží agenti Kubernetes, a spravuje je řídicí rovina Kubernetes hostovaná službou AKS. I když AKS optimalizuje řídicí rovinu Kubernetes a její komponenty pro zajištění škálovatelnosti a výkonu, stále je svázaná s limity upstreamového projektu.

Kubernetes má vícerozměrnou obálku škálování s každým typem prostředku představujícím dimenzi. Ne všechny prostředky jsou podobné. Hodinky se například běžně nastavují na tajné kódy , což vede k volání seznamu na server kube-api, který přidává náklady a nepřiměřeně vyšší zatížení řídicí roviny v porovnání s prostředky bez kukátek.

Řídicí rovina spravuje veškeré škálování prostředků v clusteru, takže čím více clusteru škálujete v rámci dané dimenze, tím méně můžete škálovat v rámci jiných dimenzí. Například spuštění stovek tisíc podů v clusteru AKS ovlivňuje, kolik četnosti změn podů (podů za sekundu) může řídicí rovina podporovat.

Velikost obálky je úměrná velikosti řídicí roviny Kubernetes. AKS podporuje tři úrovně řídicí roviny jako součást základní skladové položky: Úroveň Free, Standard a Premium. Další informace najdete v tématu Cenové úrovně Free, Standard a Premium pro správu clusteru AKS.

Důležité

Důrazně doporučujeme používat úroveň Standard nebo Premium pro produkční nebo škálované úlohy. AKS automaticky škáluje řídicí rovinu Kubernetes tak, aby podporovala následující omezení škálování:

• Až 5 000 uzlů na cluster AKS
• 200 000 podů na cluster AKS (s překrytím Azure CNI)

Ve většině případů překročení prahové hodnoty limitu škálování vede ke snížení výkonu, ale nezpůsobí okamžité převzetí služeb při selhání clusteru. Pokud chcete spravovat zatížení řídicí roviny Kubernetes, zvažte škálování v dávkách až 10–20 % aktuálního škálování. Například u 5 000 uzlů se škáluje v přírůstcích po 500 až 1 000 uzlech. I když AKS automaticky škáluje řídicí rovinu, nestane se to okamžitě.

K omezení konkrétních klientů a typů požadavků k ochraně řídicí roviny během vysoké četnosti změn a zatížení můžete využít rozhraní API Priority a Fairness (APF).

Klienti Kubernetes

Klienti Kubernetes jsou klienti aplikací, jako jsou operátoři nebo agenti monitorování, nasazení v clusteru Kubernetes, kteří potřebují komunikovat se serverem kube-api, aby mohli provádět operace čtení nebo ztlumení. Je důležité optimalizovat chování těchto klientů, aby se minimalizovalo zatížení, které přidávají na server kube-api a řídicí rovinu Kubernetes.

Přenosy a chování klientů serveru rozhraní API můžete analyzovat prostřednictvím protokolů auditu Kube. Další informace najdete v tématu Řešení potíží s řídicí rovinou Kubernetes.

Požadavky LIST můžou být nákladné. Při práci se seznamy, které můžou mít více než několik tisíc malých objektů nebo více než několik stovek velkých objektů, byste měli zvážit následující pokyny:

• Vezměte v úvahu počet objektů (CRS), které očekáváte, že při definování nového typu prostředku (CRD) nakonec existují .
• Zatížení etcd a serveru rozhraní API primárně závisí na počtu objektů, které existují, ne na počtu vrácených objektů. I když k filtrování seznamu používáte selektor polí a načítáte jenom malý počet výsledků, platí tyto pokyny. Jedinou výjimkou je načtení jednoho objektu .metadata.name
• Pokud je to možné , vyhněte se opakovaným voláním LIST, pokud váš kód potřebuje udržovat aktualizovaný seznam objektů v paměti. Místo toho zvažte použití tříd Informer poskytovaných ve většině knihoven Kubernetes. Informátoři automaticky kombinují funkce LIST a WATCH, aby efektivně udržovaly kolekci v paměti.
• Zvažte, jestli potřebujete silnou konzistenci , pokud informátoři nevyhovují vašim potřebám. Potřebujete zobrazit nejnovější data až do přesného okamžiku v čase, kdy jste dotaz vydali? Pokud ne, nastavte ResourceVersion=0. To způsobí, že mezipaměť serveru rozhraní API bude obsluhovat vaši žádost místo atd.
• Pokud nemůžete použít informátory nebo mezipaměť serveru API, přečtěte si velké seznamy v blocích dat.
• Vyhněte se výpisu častěji, než je potřeba. Pokud nemůžete použít informátory, zvažte, jak často vaše aplikace obsahuje seznam prostředků. Po přečtení posledního objektu ve velkém seznamu se okamžitě dotazujte na stejný seznam. Měli byste chvíli počkat.
• Zvažte počet spuštěných instancí klientské aplikace. Existuje velký rozdíl mezi tím, že jeden kontroler vypisuje objekty a pody na každém uzlu dělá totéž. Pokud plánujete mít více instancí klientské aplikace, které pravidelně uvádějí velký počet objektů, vaše řešení se nebude škálovat na velké clustery.

Omezování rozhraní Azure API a platformy

Zatížení cloudové aplikace se může v průběhu času lišit na základě faktorů, jako je počet aktivních uživatelů nebo typy akcí, které uživatelé provádějí. Pokud požadavky na zpracování systému překračují kapacitu dostupných prostředků, může být systém přetížen a trpí nízkým výkonem a selháním.

Pokud chcete zpracovávat různé velikosti zatížení v cloudové aplikaci, můžete aplikaci povolit, aby používala prostředky až do zadaného limitu, a po dosažení limitu je pak omezit. V Azure dochází k omezování na dvou úrovních. Azure Resource Manager (ARM) omezuje požadavky na předplatné a tenanta. Pokud je žádost v rámci limitů omezování předplatného a tenanta, ARM žádost směruje poskytovateli prostředků. Poskytovatel prostředků pak použije limity omezování přizpůsobené jeho operacím. Další informace najdete v tématu Žádosti o omezování ARM.

Správa omezování v AKS

Limity rozhraní Azure API se obvykle definují na úrovni kombinace předplatného a oblasti. Například všichni klienti v rámci předplatného v dané oblasti sdílejí limity rozhraní API pro dané rozhraní Azure API, jako jsou rozhraní PUT API služby Virtual Machine Scale Sets. Každý cluster AKS má několik klientů vlastněných AKS, jako je poskytovatel cloudu nebo automatické škálování clusteru, nebo klienti vlastnění zákazníkem, jako je Datadog nebo self-hosted Prometheus, které volají rozhraní API Azure. Při spouštění více clusterů AKS v rámci předplatného v dané oblasti sdílejí všechny klienty AKS vlastněné zákazníky v rámci clusterů společnou sadu limitů rozhraní API. Počet clusterů, které můžete nasadit v oblasti předplatného, je proto funkcí počtu nasazených klientů, jejich vzorců volání a celkového škálování a elasticity clusterů.

Mějte na paměti výše uvedené skutečnosti, že zákazníci obvykle můžou nasazovat clustery v rozsahu 20–40 malých až středně škálovaných clusterů na oblast předplatného. Škálování předplatného můžete maximalizovat pomocí následujících osvědčených postupů:

Clustery Kubernetes vždy upgradujte na nejnovější verzi. Novější verze obsahují mnoho vylepšení, která řeší problémy s výkonem a omezováním. Pokud používáte upgradovanou verzi Kubernetes a stále dochází k omezování kvůli skutečnému zatížení nebo počtu klientů v předplatném, můžete vyzkoušet následující možnosti:

• Analýza chyb pomocí AKS – Diagnostika a řešení problémů: K analýze chyb, identitě původní příčiny a získání doporučení k řešení můžete použít AKS – Diagnostika a řešení problémů .
  • Zvyšte interval kontroly automatického škálování clusteru: Pokud diagnostické sestavy ukazují, že bylo zjištěno omezování automatického škálování clusteru, můžete interval kontroly zvýšit, abyste snížili počet volání škálovacích sad virtuálních počítačů z automatického škálování clusteru.
  • Překonfigurujte aplikace třetích stran tak, aby mohly provádět méně volání: Pokud filtrujete podle uživatelských agentů diagnostiku četnosti požadavků a omezíte podrobnosti a zjistíte, že aplikace třetí strany, například monitorovací aplikace, provádí velký počet požadavků GET, můžete změnit nastavení těchto aplikací tak, aby se snížila frekvence volání GET. Ujistěte se, že klienti aplikací při volání rozhraní API Azure používají exponenciální zpochybnění.
• Rozdělte clustery do různých předplatných nebo oblastí: Pokud máte velký počet clusterů a fondů uzlů, které používají škálovací sady virtuálních počítačů, můžete je rozdělit do různých předplatných nebo oblastí v rámci stejného předplatného. Většina omezení rozhraní API Azure se sdílí na úrovni oblasti předplatného, takže clustery můžete přesunout nebo škálovat do různých předplatných nebo oblastí, abyste se odblokovali při omezování rozhraní Azure API. Tato možnost je užitečná hlavně v případě, že očekáváte, že clustery budou mít vysokou aktivitu. Pro tato omezení neexistují žádné obecné pokyny. Pokud chcete konkrétní pokyny, můžete vytvořit lístek podpory.

Monitorování metrik a protokolů řídicí roviny AKS

Monitorování metrik řídicí roviny ve velkých clusterech AKS je zásadní pro zajištění stability a výkonu úloh Kubernetes. Tyto metriky poskytují přehled o stavu a chování důležitých komponent, jako je server ROZHRANÍ API atd., správce kontroleru a plánovač. V rozsáhlých prostředích, kde jsou běžné kolize prostředků a objemy volání rozhraní API, pomáhá monitorování metrik řídicí roviny identifikovat kritické body, detekovat anomálie a optimalizovat využití prostředků. Díky analýze těchto metrik můžou operátoři aktivně řešit problémy, jako je latence serveru API, vysoké atd., nebo nadměrné využití prostředků roviny řízení, zajištění efektivní operace clusteru a minimalizace výpadků.

Azure Monitor nabízí komplexní metriky a protokoly o stavu řídicí roviny prostřednictvím spravovaných prometheus a nastavení diagnostiky Azure.

• Seznam výstrah pro konfiguraci stavu řídicí roviny najdete v tématu Osvědčené postupy pro monitorování roviny řízení AKS.
• Pokud chcete získat seznam uživatelských agentů s nejvyšší latencí, můžete použít protokoly řídicí roviny nebo nastavení diagnostiky.

Omezení funkce

Při škálování clusterů AKS na větší škálovací body mějte na paměti následující omezení funkcí:

• AKS podporuje vertikální navýšení kapacity až 5 000 uzlů ve výchozím nastavení pro všechny clustery úrovně Standard nebo LTS. AKS škáluje řídicí rovinu clusteru za běhu na základě velikosti clusteru a využití prostředků serveru API. Pokud nemůžete vertikálně navýšit kapacitu na podporovaný limit, povolte metriky řídicí roviny (Preview) se spravovanou službou Azure Monitor pro Prometheus a monitorujte řídicí rovinu. Pokud chcete pomoct s řešením potíží s výkonem nebo spolehlivostí škálování, projděte si následující zdroje informací:
  • Průvodce odstraňováním potíží s AKS ve velkém měřítku
  • Řešení potíží s řídicí rovinou Kubernetes

Poznámka:

Během operace škálování řídicí roviny můžete zaznamenat zvýšenou latenci serveru API nebo vypršení časového limitu až po dobu 15 minut. Pokud máte i nadále problémy se škálováním na podporovaný limit, otevřete lístek podpory.

• Azure Network Policy Manager (Azure npm) podporuje pouze 250 uzlů.
• Některé metriky uzlů AKS, včetně využití disku uzlu, využití procesoru nebo paměti uzlu a in/out sítě, nebudou po vertikálním navýšení kapacity řídicí roviny dostupné v metrikách platformy azure monitoru. Pokud chcete ověřit, jestli se vaše řídicí rovina vertikálně navýšit, vyhledejte mapu configmap control-plane-scale-status.

kubectl describe configmap control-plane-scaling-status -n kube-system

• U clusterů s více než 100 uzly nemůžete použít funkci Zastavit a Spustit. Další informace najdete v tématu Zastavení a spuštění clusteru AKS.

Sítě

Při škálování clusterů AKS na větší body škálování mějte na paměti následující osvědčené postupy pro sítě:

• Použití spravovaného překladu adres (NAT) pro výchozí přenos dat clusteru s alespoň dvěma veřejnými IP adresami ve službě NAT Gateway. Další informace najdete v tématu Vytvoření spravované brány NAT pro cluster AKS.
• Pomocí překrytí Azure CNI můžete vertikálně navýšit kapacitu až na 200 000 podů a 5 000 uzlů na cluster. Další informace najdete v tématu Konfigurace překryvných sítí Azure CNI v AKS.
• Pokud vaše aplikace potřebuje přímou komunikaci mezi pody mezi clustery, použijte Azure CNI s dynamickým přidělováním IP adres a vertikálním navýšením kapacity až 50 000 podů na cluster s jednou směrovatelnou IP adresou na pod. Další informace najdete v tématu Konfigurace sítí Azure CNI pro dynamické přidělování IP adres v AKS.
• Pokud používáte interní služby Kubernetes za interním nástrojem pro vyrovnávání zatížení, doporučujeme vytvořit interní nástroj pro vyrovnávání zatížení nebo službu nižší než 750 uzlů pro zajištění optimálního výkonu škálování a elasticity nástroje pro vyrovnávání zatížení.
• Azure npm podporuje pouze 250 uzlů. Pokud chcete vynutit síťové zásady pro větší clustery, zvažte použití Azure CNI využívajícího Cilium, který kombinuje robustní řídicí rovinu Azure CNI s rovinou dat Cilium, aby poskytovala vysoce výkonné sítě a zabezpečení.

Škálování fondu uzlů

Při škálování clusterů AKS na větší body škálování mějte na paměti následující osvědčené postupy škálování fondu uzlů:

• Pro fondy systémových uzlů použijte skladovou položku Standard_D16ds_v5 nebo ekvivalentní skladovou položku virtuálního počítače jádra/paměti s dočasnými disky operačního systému, které poskytují dostatek výpočetních prostředků pro pody kube-system.
• Vzhledem k tomu, že AKS má limit 1 000 uzlů na fond uzlů, doporučujeme vytvořit alespoň pět fondů uzlů uživatelů pro vertikální navýšení kapacity až na 5 000 uzlů.
• Při spouštění clusterů AKS ve velkém měřítku použijte automatické škálování clusteru, kdykoli je to možné, abyste zajistili dynamické škálování fondů uzlů na základě poptávky po výpočetních prostředcích. Další informace najdete v tématu Automatické škálování clusteru AKS podle požadavků aplikací.
• Pokud škálujete nad 1 000 uzlů a nepoužíváte automatické škálování clusteru, doporučujeme škálovat v dávkách po 500 až 700 uzlech najednou. Operace škálování by měly mít mezi operacemi vertikálního navýšení kapacity dvouminutovou až pětiminutovou dobu čekání, aby se zabránilo omezování rozhraní Azure API. Další informace najdete v tématu API Management: Ukládání do mezipaměti a zásady omezování.

Aspekty upgradu clusteru a osvědčené postupy

• Když cluster dosáhne limitu 5 000 uzlů, zablokují se upgrady clusteru. Tato omezení brání upgradu, protože není k dispozici kapacita uzlu k provádění kumulativních aktualizací v rámci limitu maximálního zvýšení počtu vlastností. Pokud máte cluster s tímto limitem, doporučujeme před pokusem o upgrade clusteru vertikálně snížit kapacitu clusteru pod 3 000 uzly. Tím zajistíte dodatečnou kapacitu pro četnost změn uzlů a minimalizujete zatížení řídicí roviny.
• Při upgradu clusterů s více než 500 uzly se doporučuje použít maximální konfiguraci nárůstu kapacity fondu uzlů o velikosti 10–20 %. AKS konfiguruje upgrady s výchozí hodnotou 10 % pro maximální nárůst. Maximální nastavení přepětí na fond uzlů můžete přizpůsobit, abyste umožnili kompromis mezi rychlostí upgradu a přerušením úloh. Když zvýšíte maximální nastavení nárůstu, proces upgradu se dokončí rychleji, ale během procesu upgradu může dojít k přerušení. Další informace naleznete v tématu Přizpůsobení upgradu nárůstu uzlu.
• Další informace o upgradu clusteru najdete v tématu Upgrade clusteru AKS.