Sdílet prostřednictvím

Možnosti škálování pro aplikace ve službě Azure Kubernetes Service (AKS)

Při spouštění aplikací ve službě Azure Kubernetes Service (AKS) možná budete muset aktivně zvýšit nebo snížit množství výpočetních prostředků ve vašem clusteru. Když změníte počet instancí aplikací, které máte, možná budete muset změnit počet základních uzlů Kubernetes. Možná budete také muset zřídit velký počet dalších instancí aplikace.

Tento článek představuje základní koncepty škálování aplikací AKS, včetně ručního škálování podů nebo uzlů, použití horizontálního automatického škálování podů, použití automatického škálování clusteru a integrace se službou Azure Container Instances (ACI).

Ruční škálování podů nebo uzlů

Repliky nebo pody a uzly můžete ručně škálovat a otestovat, jak vaše aplikace reaguje na změnu dostupných prostředků a stavu. Ruční škálování prostředků umožňuje definovat nastavené množství prostředků, které se mají použít, například počet uzlů, aby se zachovaly pevné náklady. Pokud chcete ručně škálovat, definujete počet replik nebo uzlů. Rozhraní API Kubernetes pak naplánuje vytvoření dalších podů nebo odpojení uzlů na základě počtu těchto replik nebo uzlů.

Při zmenšení počtu uzlů volá rozhraní API Kubernetes příslušné rozhraní API Azure Compute navázané na typ výpočtu používaný vaším clusterem. Například u clusterů založených na škálovacích sadách virtuálních počítačů určuje rozhraní API služby Virtual Machine Scale Sets, které uzly se mají odebrat. Další informace o tom, jak jsou uzly vybrány pro odebrání vertikálního snížení kapacity, najdete v nejčastějších dotazech ke škálovacím sadám virtuálních počítačů.

Pokud chcete začít s ručním škálováním uzlů, podívejte se na ručně škálovací uzly v clusteru AKS. Pokud chcete počet podů škálovat ručně, přečtěte si příkaz kubectl scale.

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

Kubernetes pomocí horizontálního automatického škálování podů (HPA) monitoruje poptávku po prostředcích a automaticky škáluje počet podů. Ve výchozím nastavení HPA kontroluje rozhraní API metrik každých 15 sekund, zda nejsou požadované změny v počtu replik, zatímco rozhraní API metrik přejímá data z Kubeletu každých 60 sekund. V důsledku toho se HPA aktualizuje každých 60 sekund. Pokud se vyžadují změny, počet replik se odpovídajícím způsobem škáluje. HPA funguje s clustery AKS, které mají nasazený server metrik pro Kubernetes verze 1.8 a vyšší.

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

Při konfiguraci HPA pro dané nasazení definujete minimální a maximální počet replik, které se dají spustit. Definujete také metriku pro monitorování a základ rozhodnutí o škálování, například využití procesoru.

Pokud chcete začít s horizontálním automatickým škálováním podů v AKS, přečtěte si téma Automatické škálování podů v AKS.

Snížení kapacity událostí škálování

Vzhledem k tomu, že HPA se efektivně aktualizuje každých 60 sekund, předchozí škálovací události se nemusí úspěšně dokončit, než je provedena další kontrola. Toto chování může způsobit, že HPA změní počet replik před předchozí událostí škálování může přijímat úlohy aplikace a požadavky na prostředky, aby se odpovídajícím způsobem upravily.

Pokud chcete minimalizovat události závodu, nastaví se hodnota zpoždění. Tato hodnota definuje, jak dlouho musí HPA čekat po události škálování před aktivací jiné události škálování. Toto chování umožňuje, aby se nový počet replik projevil a rozhraní API metrik odráželo distribuovanou úlohu. U událostí vertikálního navýšení kapacity pro Kubernetes 1.12 není žádné zpoždění. Výchozí zpoždění událostí snížení kapacity je však 5 minut.

Automatické škálování clusteru

Aby bylo potřeba reagovat na měnící se požadavky podů, automatické škálování clusteru Kubernetes upraví počet uzlů na základě požadovaných výpočetních prostředků ve fondu uzlů. Ve výchozím nastavení automatické škálování clusteru kontroluje server rozhraní API metrik každých 10 sekund, aby se všechny požadované změny v počtu uzlů změnily. Pokud automatické škálování clusteru zjistí, že se vyžaduje změna, počet uzlů v clusteru AKS se odpovídajícím způsobem zvýší nebo sníží. Automatické škálování clusteru funguje s clustery AKS s podporou RBAC Kubernetes, na kterých běží Kubernetes 1.10.x nebo vyšší.

Automatické škálování clusteru Kubernetes

Automatické škálování clusteru se obvykle používá společně s horizontálním automatickým škálováním podů. V kombinaci se horizontální automatické škálování podů zvýší nebo sníží počet podů na základě poptávky aplikace a automatické škálování clusteru upraví počet uzlů tak, aby spouštět více podů.

Pokud chcete začít s automatickým škálováním clusteru v AKS, přečtěte si téma Automatické škálování clusteru v AKS.

Horizontální navýšení kapacity událostí

Pokud uzel nemá dostatek výpočetních prostředků ke spuštění požadovaného podu, nemůže tento pod projít procesem plánování. Pod nejde spustit, pokud není ve fondu uzlů k dispozici více výpočetních prostředků.

Když si automatické škálování clusteru všimne podů, které nejde naplánovat kvůli omezením prostředků fondu uzlů, zvýší se počet uzlů ve fondu uzlů, aby poskytoval další výpočetní prostředky. Pokud jsou uzly úspěšně nasazené a dostupné pro použití ve fondu uzlů, jsou pody naplánované tak, aby na nich běžely.

Pokud vaše aplikace potřebuje rychle škálovat, některé pody mohou zůstat ve stavu čekání na plánování, dokud nebudou nasazeny další uzly automatickým škálováním clusteru, které mohou přijmout plánované pody. U aplikací s vysokými požadavky na nárůst kapacity můžete škálovat s virtuálními uzly a službou Azure Container Instances.

Škálování v událostech

Automatické škálování clusteru také monitoruje stav plánování podů pro uzly, které nedávno nepřijaly nové žádosti o plánování. Tento scénář označuje, že fond uzlů má více výpočetních prostředků, než je potřeba, a počet uzlů je možné snížit. Ve výchozím nastavení jsou uzly, které již nejsou potřeba déle než 10 minut, naplánovány k odstranění. V takovém případě jsou pody naplánované tak, aby běžely na jiných uzlech ve fondu uzlů a automatické škálování clusteru snižuje počet uzlů.

Při automatickém škálování clusteru může dojít k nějakému přerušení, protože pody jsou naplánované na různých uzlech, když automatické škálování clusteru sníží počet uzlů. Pokud chcete minimalizovat přerušení, vyhněte se aplikacím, které používají jednu instanci podu.

Automatické škálování řízené událostmi Kubernetes (KEDA)

Automatické škálování řízené událostmi Kubernetes (KEDA) je opensourcová komponenta pro automatické škálování úloh řízené událostmi. Škáluje úlohy dynamicky na základě počtu přijatých událostí. KEDA rozšiřuje Kubernetes o vlastní definici prostředků (CRD), označovanou jako ScaledObject, a popisuje, jak by se aplikace měly škálovat v reakci na konkrétní provoz.

Škálování KEDA je užitečné ve scénářích, kdy úlohy přijímají nárůsty provozu nebo zpracovávají velké objemy dat. KEDA se liší od "Horizontal Pod Autoscaler" (HPA), protože KEDA je řízena událostmi a škáluje se na základě počtu událostí, zatímco HPA se řídí metrikami vycházejícími z využití prostředků (například procesoru a paměti).

Pokud chcete začít s doplňkem KEDA v AKS, podívejte se na přehled KEDA.

Automatické zřizování uzlů

Automatické zřizování uzlů (PREVIEW) (NAP) používá opensourcový projekt Karpenter, který automaticky nasazuje, konfiguruje a spravuje Karpenter ve vašem clusteru AKS. NAP dynamicky zřizuje uzly na základě čekajících požadavků na prostředky podů; automaticky vybere optimální SKU a množství virtuálních počítačů, aby splnily poptávku v reálném čase.

Architektura NAP přebírá předdefinovaný seznam skladových položek virtuálních počítačů jako výchozí bod k rozhodnutí, která skladová položka je nejvhodnější pro nevyřízené úlohy. Aby uživatelé mohli přesněji řídit, můžou definovat horní limity prostředků používaných fondem uzlů a preferencemi místa, kde mají být úlohy naplánovány, pokud existuje více fondů uzlů.

Škálování a ochrana řídicí roviny

Kubernetes má vícerozměrný rozsah, kde každý typ prostředku představuje dimenzi. Ne všechny prostředky jsou podobné. Například objekty typu "watch" jsou běžně založeny na tajemství, což vede k volání seznamů na kube-apiserveru, který přidává náklady a nepřiměřeně vyšší zatížení řídicí roviny ve srovnání s prostředky bez "watch".

Ří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, jakou míru změn podů (mutací podů za sekundu) může řídicí rovina podporovat. Projděte si osvědčené postupy.

AKS automaticky škáluje komponenty řídicí roviny na základě klíčových signálů, jako je celkový počet jader v clusteru a procesoru nebo zatížení paměti na součástech řídicí roviny.

Pokud chcete ověřit, jestli se řídicí rovina navýšila, zkontrolujte ConfigMap s názvem 'large-cluster-control-plane-scaling-status'.

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

Ochrana řídicí roviny

Pokud automatické škálování serveru rozhraní API nestabilizuje jeho výkon ve scénářích s vysokým zatížením, nasadí AKS spravovanou ochranu serveru rozhraní API. Tato ochrana funguje jako mechanismus posledního řešení, který chrání server rozhraní API omezením nesystémových požadavků klientů a brání tomu, aby řídicí rovina úplně nereaguje. Systémová důležitá volání serveru rozhraní API ze součástí, jako je kubelet, budou dál normálně fungovat.

Pokud chcete ověřit, jestli byla aplikována ochrana spravovaného rozhraní API serveru, zkontrolujte přítomnost FlowSchema a PriorityLevelConfiguration pro aks-managed-apiserver-guard.

kubectl get flowschemas
kubectl get prioritylevelconfigurations

Informace o řešení potíží se serverem rozhraní API a etcd najdete, pokud byly v clusteru použity FlowSchema a PriorityLevelConfiguration a "aks-managed-apiserver-guard" pro rychlou nápravu.

Rozšíření do služby Azure Container Instances (ACI)

Pokud chcete rychle škálovat cluster AKS, můžete se integrovat se službou Azure Container Instances (ACI). Kubernetes má integrované komponenty pro škálování počtu replik a uzlů. Pokud ale vaše aplikace potřebuje rychle škálovat, horizontální automatické škálování podů může naplánovat více podů, než jaké stávající výpočetní prostředky ve fondu uzlů můžou podporovat. Pokud je nakonfigurovaný, tento scénář by pak aktivoval automatické škálování clusteru , aby nasadil více uzlů ve fondu uzlů, ale může trvat několik minut, než se tyto uzly úspěšně zřídí a umožní plánovači Kubernetes spouštět pody.

Nárazové škálování Kubernetes na ACI

ACI umožňuje rychle nasadit instance kontejnerů bez dalších režijních nákladů na infrastrukturu. Když se připojíte pomocí AKS, ACI se stane zabezpečeným logickým rozšířením clusteru AKS. Komponenta virtuálních uzlů, která je založená na virtuálním Kubeletu, je nainstalovaná ve vašem clusteru AKS, který představuje ACI jako virtuální uzel Kubernetes. Kubernetes pak může plánovat pody, které běží jako instance ACI prostřednictvím virtuálních uzlů, ne jako pody na uzlech virtuálních počítačů přímo v clusteru AKS.

Aplikace nevyžaduje žádné úpravy použití virtuálních uzlů. Vaše nasazení se můžou škálovat napříč AKS a ACI a bez zpoždění, protože automatické škálování clusteru nasazuje nové uzly v clusteru AKS.

Virtuální uzly se nasazují do jiné podsítě ve stejné virtuální síti jako cluster AKS. Tato konfigurace virtuální sítě zabezpečuje provoz mezi ACI a AKS. Podobně jako cluster AKS je instance ACI zabezpečeným logickým výpočetním prostředkem izolovaným od ostatních uživatelů.

Další kroky

Pokud chcete začít se škálováním aplikací, projděte si následující zdroje informací:

Další informace o základních konceptech Kubernetes a AKS najdete v následujících článcích:

  • Last updated on