Osvědčené postupy pro výkon a škálování velkých úloh v 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 small až střední úlohy najdete v tématu Performance a osvědčené postupy škálování pro malé až střední úlohy v Azure Kubernetes Service (AKS).

Pro většinu produkčních úloh AKS začněte s AKS Automatic. AKS Automatic je doporučené výchozí nastavení připravené pro produkční prostředí v AKS a poskytuje předem nakonfigurované výchozí hodnoty osvědčených postupů pro škálování, zabezpečení, sítě, monitorování a upgrady. Pokyny pro ladění ve velkém měřítku uvedené v tomto článku se stále vztahují jak na AKS Automatic, tak na AKS Standard, pokud je provozujete ve velkém měřítku.

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 se 100 uzly a tisíci pody nebo CRD objekty může být považován 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 následujících tématech:

  • Pokyny k režimu clusteru AKS pro velké úlohy
  • Škálování uzlů
  • Škálovatelnost řídicí roviny AKS a Kubernetes
  • Osvědčené postupy klienta Kubernetes, včetně zpomalování, sledování a stránkování.
  • Omezování rozhraní API a omezení platformy Azure.
  • Omezení funkcí
  • Osvědčené postupy pro sítě

Pokyny k režimu AKS pro velké úlohy

AKS podporuje dva režimy clusteru:

  • Automatická služba AKS: Doporučený výchozí bod pro většinu produkčních úloh Snižuje provozní režii tím, že poskytuje výchozí nastavení spravované platformy pro škálování, zabezpečení, sítě, monitorování a upgrady.
  • AKS Standard: Nejlepší, když potřebujete explicitní kontrolu nad topologií clusteru, sítěmi, chováním automatického škálování nebo orchestrací upgradu.

Pokyny k výkonu a škálování ve velkém měřítku v tomto článku platí pro oba režimy clusteru. AKS Automatic přebírá větší část správy výchozího nastavení platformy, ale neodstraňuje nutnost rozumět zatížení řídicí roviny, chování klientů, omezení propustnosti, limitům sítě a rezervě pro upgrade.

Škálování 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í uzlů:

  • Při spouštění clusterů AKS ve velkém měřítku použijte automatické škálování clusteru nebo automatické zřizování uzlů (NAP), kdykoli je to možné, abyste zajistili dynamické škálování uzlů na základě poptávky po výpočetních prostředcích.
  • AKS Automatic je doporučeným výchozím bodem pro většinu produkčních úloh, ale velké clustery v obou režimech clusteru stále vyžadují pečlivé škálování uzlů, dávkové plánování a ověřování řídicí roviny.
  • 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. Mezi operacemi navýšení kapacity by měla být čekací doba dvě až pět minut, aby se zabránilo omezení rozhraní API Azure.
  • Pro fondy systémových uzlů použijte SKU Standard_D16ds_v5 nebo ekvivalentní VM SKU pro jádra/paměť s dočasnými disky operačního systému, abyste zajistili dostatečné výpočetní prostředky pro kontejnerové 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ů.

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

V Kubernetes spravuje všechny objekty spuštěné v clusteru řídicí rovina, kterou spravuje 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.

Tyto limity řídicí roviny a vzorce použití rozhraní API platí pro AKS Automatic i AKS Standard. AKS Automatic snižuje provozní režii, ale řídicí rovina má stále omezenou kapacitu a při provozu ve velkém rozsahu stále vyžaduje, aby se úlohy chovaly efektivně.

Kubernetes má vícerozměrný rámec škálování, přičemž každý typ prostředku představuje dimenzi, a ne všechny prostředky jsou nákladově stejné. Například Secrets často sledují více controllerů a podů, z nichž každý provádí počáteční volání LIST pro synchronizaci stavu. Vzhledem k tomu, že tajemství jsou obvykle velká a často aktualizovaná, ukládají větší zatížení na řídicí rovinu než méně často sledované prostředky.

Čí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 obnovování podů (mutací podů za sekundu) může řídicí rovina podporovat.

AKS podporuje tři cenové úrovně řídicí roviny v rámci základního SKU: Free, Standard a Premium. Další informace najdete v tématu Cenové úrovně Free, Standard a Premium pro správu clusteru AKS.

Důležité

Pro produkční nebo škálované úlohy použijte cenovou úroveň Standard nebo Premium. 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ů vede překročení limitu škálování ke snížení výkonu, ale nezpůsobí okamžité přepnutí clusteru při selhání. Pokud chcete spravovat zatížení řídicí roviny Kubernetes, zvažte škálování v šaržích až do 10–20 % aktuálního měřítka. Například u clusteru s 5 000 uzly, škálování probíhá v přírůstcích po 500 až 1 000 uzlech. I když AKS automaticky škáluje řídicí rovinu, neděje se to okamžitě.

Pokud chcete ověřit, jestli se řídicí rovina škálovala, vyhledejte konfigurační mapu large-cluster-control-plane-scaling-status.

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

Aspekty škálování a řízení Kubernetes

Klienti Kubernetes jsou komponenty aplikací, jako jsou operátoři nebo agenti monitorování, které běží v clusteru a komunikují se serverem kube-api za účelem čtení nebo úprav prostředků. Je důležité optimalizovat, jak se tito klienti chovají, aby snížili zatížení, které umístí na server kube-api a řídicí rovinu Kubernetes.

AKS Automatic neodebere potřebu efektivního chování klienta; Velké clustery stále potřebují vzory založené na hodinkách, stránkování, backoff a omezený provoz LIST.

Počet žádostí aktivně zpracovávaných serverem rozhraní API v libovolném okamžiku je určen příznaky --max-requests-inflight a --max-mutating-requests-inflight. AKS pro tyto příznaky používá výchozí hodnoty 400 a 200 požadavků, což umožňuje odeslání celkem 600 požadavků v daném okamžiku. Když škálujeme server rozhraní API na větší velikosti, odpovídajícím způsobem zvýšíme i příchozí požadavky.

Dva typy objektů Kubernetes, PriorityLevelConfiguration a FlowSchema (APF) určují, jak server rozhraní API rozděluje celkovou kapacitu požadavků mezi typy požadavků. AKS používá výchozí konfiguraci.

Každá PriorityLevelConfiguration má přiřazený podíl z celkového povoleného počtu požadavků. Pokud chcete zobrazit objekty PriorityLevelConfiguration v clusteru a jejich přidělené sdílené složky žádostí, spusťte následující příkaz.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema mapuje požadavky API serveru na PriorityLevelConfiguration. Pokud několik objektů FlowSchema odpovídá požadavku, server rozhraní API vybere objekt s nejnižší prioritou shody.

Mapování FlowSchemas na PriorityLevelConfigurations lze zobrazit pomocí tohoto příkazu:

kubectl get flowschemas

Pokud chcete ověřit, jestli se některé požadavky kvůli APF zahazují, spusťte následující příkaz:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Osvědčené postupy pro klienta Kubernetes

Volání LIST vystavená neoptimalizovanými klienty jsou často jedním z největších faktorů, které omezují škálovatelnost clusteru. 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í na etcd a API serveru primárně závisí na velikosti odpovědi. Tyto pokyny platí, jestli klient vydává malý počet požadavků LIST pro velké objekty nebo velký počet požadavků LIST pro menší objekty.

Použití informátorů

  • Pokud váš kód potřebuje udržovat aktualizovaný seznam objektů v paměti, můžete pomocí informátoru z knihovny klienta získat výhody sledování změn prostředků na základě událostí místo dotazování na změny. Toto je nejlepší přístup, jak se vyhnout neoptimalizovaným a opakovaným seznamům.

Použijte mezipaměť serveru API

Slouží resourceVersion=0 k vrácení výsledků z mezipaměti serveru rozhraní API. To může zabránit načtení objektů z atd., což snižuje zatížení atd., ale nepodporuje stránkování.

/api/v1/namespaces/default/pods?resourceVersion=0

Efektivní využití rozhraní API Kubernetes

Pokud je to možné, doporučujeme použít argument kukátku. Bez argumentů je standardním chováním vypsat objekty. Příklad:

/api/v1/namespaces/default/pods?watch=true

Pomocí sledování s resourceVersion nastavením, aby se použila nejnovější známá hodnota přijatá z předchozího seznamu nebo sledování. To se zpracovává automaticky v client-go. Ověřte ale, jestli používáte klienta Kubernetes v jiných jazycích.

/api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

Pokud kontrolery nebo operátoři musí používat volání LIST, měli by se vyhnout dotazování prostředků na úrovni clusteru bez selektorů popisků nebo polí, zejména ve velkých clusterech. Následující příklady ukazují optimalizovaná a neoptimalizovaná volání LIST.

  • Optimalizovaný seznam:

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running

  • Neoptimalizovaný SEZNAM:

    /api/v1/pods

Pomocí stránkování omezte velikost odpovědí LIST v případě, že klient musí načíst data z etcd. Následující příklad používá argument limitu k omezení odpovědi na 100 objektů.

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

Pokud chcete, aby funkce LIST pokračovala v vracení všech objektů podů v příkladu výše, použijte argument continue s limitem.

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

Pokud se kubectl využívá, --chunk-size můžete argument použít přímo u stránkovaných odpovědí.

kubectl get pods -n default --chunk-size=100

Pokud kontroléry nebo operátoři používají aktualizace leasingu pro volbu vedoucího, ujistěte se, že jsou odolné vůči přechodným problémům s připojením tím, že vyladíte leaseDuration, renewDeadline a retryPeriod tak, aby byly optimální pro vaše úlohy. Pro kontrolery Kubernetes, které používají volbu lídra klienta, použijte následující vzorec:

lease_duration > renew_deadline > retry_period

Daemonsets

  • Existuje významný rozdíl mezi jedním kontrolerem, který vyjmenovává objekty, a DaemonSetem spuštěným na každém uzlu, který vykonává totéž. Pokud více instancí klientské aplikace pravidelně vypisuje velký počet objektů, řešení nebude ve velkých clusterech správně škálovat.

  • V clusterech s tisíci uzlů může vytvoření nové sady daemonSet, aktualizace daemonSet nebo zvýšení počtu uzlů vést k vysokému zatížení v řídicí rovině. Pokud pody DaemonSet při spuštění vydávají nákladné požadavky na server API, mohou způsobit zvýšené využití prostředků na řídicí rovině kvůli velkému počtu konkurentních požadavků.

  • Pomocí strategie RollingUpdate postupně zavádět nové pody DaemonSet. Při aktualizaci šablony DaemonSet nahradí kontroler staré pody novými řízeným způsobem. Pokud strategie kumulativní aktualizace není explicitně nakonfigurovaná, Kubernetes ve výchozím nastavení vytvoří RollingUpdate s hodnotou maxUnavailable jako 1, maxSurge jako 0 a minReadySeconds jako 0s. Podívejte se na následující příklad.

      minReadySeconds: 30
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1

  • Strategie RollingUpdate se vztahuje pouze na existující pody DaemonSet. Neomezuje vliv přidávání nových uzlů, které vytváří další pody DaemonSet nebo nasazuje zcela nové daemonSety.

  • Chcete-li zabránit DaemonSets v souběžném vydávání požadavků LIST na server API během spouštění po horizontálním navýšení kapacity uzlů nebo nasazení nových DaemonSets, implementujte v vstupním bodu kontejneru náhodné zpoždění spuštění a nakonfigurujte odpovídající zásady exponenciálního zpoždění a opakování pro odpovědi 5xx nebo 429, aby se zabránilo opakovanému odesílání velkých požadavků LIST.

      spec:
    template:
      spec:
        containers:
        - name: my-daemonset-container
          image: <image>
          command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]

Poznámka:

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.

optimalizace etcd

  • Ponechte celkovou velikost atd. malá a nepoužívejte ji jako databázi pro obecné účely. AKS ve výchozím nastavení poskytuje 8 GB úložiště etcd, ale větší etcd databáze zvyšují čas defragmentace, což může vést k problémům s výkonem čtení a zápisu. Větší databáze etcd mohou také zvýšit pravděpodobnost problémů se spolehlivostí API serveru a etcd, pokud neoptimalizovaný klient často načítá velký počet objektů z etcd. Pokud velikost databáze etcd překročí 2 GB, zvažte použití níže uvedených technik redukce velikosti objektů.
  • Pokud chcete zmenšit velikosti specifikací podů, přesuňte proměnné prostředí ze specifikací podů do objektů ConfigMap.
  • Rozdělte velké tajné kódy nebo objekty ConfigMap na menší a lépe spravovatelné části.
  • Pokud je to možné, uložte tajné kódy v Azure Key Vault místo tajných kódů Kubernetes, abyste snížili počet tajných kódů uložených v atd..
  • Vyčištění nepoužívaných objektů
    • Odstraňte zastaralé úlohy a dokončené pody. Použijte ttlSecondsAfterFinished u úloh, takže dokončené objekty jsou odebrány automaticky.
    • Ujistěte se, že kontrolery nastavují ownerReferences. Díky tomu může garbage collection Kubernetes automaticky odebrat závislé objekty při odstranění nadřazeného zdroje.
    • Omezte historii CronJob nastavením hodnot successfulJobsHistoryLimit a failedJobsHistoryLimit, abyste zachovali pouze malý počet dokončených záznamů úloh.
    • Snižte historii zavedení nasazení. Staré sady replik se také ukládají jako objekty rozhraní API. Výchozí hodnota je 10.
  • Redukujte historii revizí Helmu pomocí argumentu --history-max . Ve velkých clusterech ji ponechte nižší než 5.

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 API server, etcd, řadič řídícího modulu a plánovač. V rozsáhlých prostředích, kde je běžné kontendování prostředků a velké objemy volání rozhraní API, pomáhá monitorování metrik řídicí úrovně 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ý počet objektů etcd, nebo nadměrné využití prostředků roviny řízení, čímž zajišťují efektivní provoz clusteru a minimalizují výpadky.

AKS Automaticky snižuje provozní režii, ale přesto potřebujete stejný přehled o stavu řídicí roviny, latenci požadavků a tlaku, když je zatížení velké.

Azure Monitor nabízí komplexní metriky a protokoly o stavu řídicí roviny prostřednictvím Azure Managed Prometheus a nastavení Diagnostic.

Metriky platformy klíčové roviny řízení

AKS zpřístupňuje v Azure Monitor následující platformní metriky pro monitorování zdraví API serveru a etcd. Tyto metriky jsou dostupné bez povolení spravovaného Promethea a můžete je zobrazit přímo na portálu Azure v části Metriky pro váš cluster AKS.

Metriky serveru API:

Ukazatel Description
apiserver_cpu_usage_percentage Maximální procento využití CPU (na základě aktuálního limitu) používané podu serveru API napříč instancemi.
apiserver_memory_usage_percentage Maximální procento paměti (na základě aktuálního limitu) používané podem serveru API napříč instancemi
apiserver_current_inflight_requests (Preview) Maximální počet aktuálně aktivních požadavků ve zpracování na API serveru, podle typu požadavku.

Metriky Etcd:

Ukazatel Description
etcd_cpu_usage_percentage Maximální procento procesoru (na základě aktuálního limitu) používaného podem etcd napříč instancemi
etcd_memory_usage_percentage Maximální procento paměti (na základě aktuálního limitu) používaného podem etcd napříč instancemi
etcd_database_usage_percentage Maximální využití databáze etcd napříč instancemi. Pečlivě to monitorujte, abyste se vyhnuli překročení limitu úložiště atd.

Konzistentně monitorujte apiserver_cpu_usage_percentage a apiserver_memory_usage_percentage pro zjištění tlaku na prostředky na serveru rozhraní API. Pokud etcd_database_usage_percentage je konzistentně vyšší než 50%, projděte si část Optimalizace etcd a snižte velikost databáze. Úplný seznam dostupných metrik najdete v referenčních informacích k datům monitorování AKS.

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 roviny řízení (Preview) pomocí spravované služby Azure Monitor pro Prometheus pro monitorování roviny řízení. Pokud chcete pomoct s řešením potíží s výkonem nebo spolehlivostí škálování, projděte si následující zdroje informací:

    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 stále máte potíže se škálováním na podporovaný limit, otevřete žádost o podporu.

  • Azure Network Policy Manager (Azure npm) podporuje maximálně 250 uzlů.

  • Některé metriky uzlů AKS, včetně využití disku uzlu, využití procesoru/paměti uzlu a síťového provozu in/out, nebudou přístupné v metrikách platformy Azure Monitor po rozšíření řídicí roviny.

  • 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.

Azure rozhraní API a omezování 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.

AKS Automatic zjednodušuje provoz clusterů, ale ve velkém nasazení se stále uplatňují omezení předplatného Azure a limity omezování platformy.

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. Na Azure dochází ke škrcení na dvou úrovních. Azure Resource Manager (ARM) omezuje požadavky na předplatné a tenanta. Pokud žádost splňuje limity omezování pro předplatné a klienta, ARM ji 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 Požadavky na omezování ARM.

Správa omezení výkonu v AKS

Limity rozhraní API Azure se obvykle definují na úrovni kombinace předplatného a oblasti. Například všichni klienti ve stejném předplatném v určité oblasti sdílejí limity API pro konkrétní Azure API, například PUT API pro Virtual Machine Scale Sets. Každý cluster AKS má několik klientů ve vlastnictví AKS, jako je cloudový poskytovatel nebo automatizovaný škálovač clusteru, a klienty vlastněné zákazníky, jako je Datadog nebo self-hosted Prometheus, které volají rozhraní Azure API. 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 regulací. 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, identifikaci původní příčiny a získání doporučení k řešení můžete použít AKS – Diagnostika a řešení problémů .
    • Zvětšení intervalu 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ůžetezvětšit interval kontroly a tím snížit počet volání Virtual Machine Scale Sets z automatického škálování clusteru.
    • Překonfigurujte aplikace třetích stran, abyste omezili počet volání: Pokud filtrujete uživatelské agenty v diagnostice rychlosti požadavků a podrobností omezení a zjistíte, že aplikace třetí strany, například monitorovací aplikace, uskutečňuje velký počet požadavků GET, můžete změnit nastavení těchto aplikací, aby se snížila frekvence volání GET. Ujistěte se, že klienti aplikace používají při volání rozhraní API Azure exponenciální zpoždění.
  • Split clustery do různých předplatných nebo oblastí: Pokud máte velký počet clusterů a fondů uzlů, které používají Virtual Machine Scale Sets, 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 limitů rozhraní API Azure je sdílena na úrovni předplatného a oblasti, takže můžete přesouvat nebo škálovat své clustery do různých předplatných nebo oblastí, abyste se vyhnuli omezením 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.

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žijte spravované NAT pro odchozí přenos v rámci clusteru s alespoň dvěma veřejnými IP adresami na NAT Gateway. Další informace najdete v tématu Vytvoření spravované brány NAT pro cluster AKS.

  • AKS Automatic poskytuje výchozí nastavení spravovaných sítí, ale při škálování velkých úloh byste měli stále ověřovat odchozí cesty, chování DNS, limity nástroje pro vyrovnávání zatížení a topologii služeb.

  • Pokud používáte Azure Standard Load Balancer, použijte alespoň 2 odchozí veřejné IP adresy. Při plánování velkých clusterů zvažte také limity back-endových pravidel služby LoadBalancer. Azure Load Balancery úrovně Standard podporují až 10 000 konfigurací back-endových IP adres na front-endovou IP adresu. Každý typ: Služba LoadBalancer vytvoří jedno pravidlo vyrovnávání zatížení na vystavený port a přidruží všechny uzly clusteru k back-endovému fondu nástroje pro vyrovnávání zatížení. Například narazí na tento limit při vystavení 5 portů pro jednu službu na 2000 uzlech.

    1 service * 5 ports * 2000 nodes = 10000 backend IP configurations

  • Pomocí Azure CNI Overlay můžete škálovat až na 200 000 podů a 5 000 uzlů na clustru. Další informace najdete v tématu Konfigurace sítí Azure CNI Overlay v AKS.

  • Pokud vaše aplikace potřebuje přímou komunikaci mezi pody v rámci clusterů, použijte Azure CNI s dynamickým přidělováním IP adres a zvyšte kapacitu na až 50 000 aplikačních podů na cluster, přičemž každý pod bude mít jednu směrovatelnou IP adresu. Další informace najdete v tématu Konfigurování Azure sítí 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 (Network Policy Manager) podporuje maximálně 250 uzlů. Pokud chcete vynutit síťové zásady pro větší clustery, zvažte použití Azure CNI využívající cilium, která kombinuje robustní řídicí rovinu Azure CNI s rovinou dat Cilium, aby poskytovala vysoce výkonné sítě a zabezpečení.

  • Povolte LocalDNS ve fondech uzlů, abyste snížili latenci překladu DNS a ulehčili centrálním podům CoreDNS. Ve velkých clusterech s vysokým objemem dotazů DNS se může centralizované řešení DNS stát úzkým hrdlem. LocalDNS nasadí DNS proxy jako systemd službu na každý uzel, řeší dotazy lokálně, eliminuje conntrack tlak na tabulku a upgraduje připojení na protokol TCP, aby nedocházelo conntrack k závodním podmínkám. LocalDNS také podporuje obsluhu zastaralých odpovědí uložených v mezipaměti v případě nedostupnosti upstreamu DNS, což zvyšuje odolnost úloh během přechodných selhání. Další informace najdete v tématu Řešení DNS v AKS.

Aspekty upgradu clusteru a osvědčené postupy

AKS Automatic se za vás postará o větší část procesu upgradu, ale pokyny k maximálnímu navýšení a plánování kapacity v této části jsou stále důležité pro rozsáhlá zatížení, zejména při koordinaci výpadků a zajištění dostatečné kapacitní rezervy.

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

  • Když cluster dosáhne limitu 5 000 uzlů, zablokují se upgrady clusteru. Tento limit 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 10–20% kapacity fondu uzlů. 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 AKS najdete v tématu Upgrade clusteru AKS.

Související obsah

  • Poslední aktualizace v