Možnosti upgradu a doporučení pro clustery Azure Kubernetes Service (AKS)

Platí pro: ✔️ AKS Automatic ✔️ AKS Standard

Important

Aktualizace iniciované platformou AKS. Od 1. června 2027 AKS automaticky upgraduje všechny clustery, které zůstanou na nepodporované verzi Kubernetes po uplynutí 60denní doby odkladu podpory platformy . Upgrade iniciovaný platformou nedodržuje vaše okno údržby, nezastaví se kvůli používání zastaralého rozhraní API a může přepsat Pod Disruption Budget, který blokuje vyprazdnění uzlu, takže může dojít k narušení úloh. Před měsícem, ve kterém proběhne upgrade, nahraďte rozhraní API odebraná z cílové verze Kubernetes a aktualizujte nekompatibilní doplňky, které se spravují samostatně. Udržujte clustery v podporované verzi Kubernetes, abyste se vyhnuli upgradu iniciovaného platformou. Další informace najdete v tématu Příprava na upgrady iniciované platformou v AKS.

U většiny produkčních úloh je doporučeným výchozím prostředím clusteru služba AKS Automatic. Poskytuje výchozí hodnoty připravené pro operace životního cyklu clusteru a uzlů, včetně chování spravovaného upgradu, integrovaných ochranných opatření a snížení provozní režie.

AKS Standard zůstává k dispozici pro scénáře, ve kterých potřebujete hlubší ruční kontrolu nad mechanikou upgradu, volbami sítí nebo chováním fondu uzlů.

Tento článek poskytuje technický základ pro upgrady AKS tím, že pokrývá možnosti upgradu, běžné scénáře a doporučení pro AKS Automatic i AKS Standard.

Co tento článek popisuje

Tato technická referenční dokumentace se týká:

  • Proč je AKS Automatic doporučeným výchozím nastavením pro produkční prostředí pro většinu úloh.
  • Jak se chování upgradu liší mezi službou AKS Automatic a AKS Standard.
  • Ruční a automatizované cesty upgradu a kdy je vhodné je použít.
  • Běžné scénáře upgradu s konkrétními doporučeními
  • Techniky optimalizace pro výkon a minimální přerušení
  • Ověřovací procesy a kontroly před upgradem

Související pokyny:

Rychlá navigace

Vaše situace Doporučená cesta
Nová nebo stávající produkční úloha bez zvláštních požadavků na přizpůsobení Vytvoření automatického clusteru AKS
Produkční cluster se striktními vlastními mechanismy řízení upgradu Strategie upgradu produkčního prostředí
Databázové nebo stavové úlohy Vzory stavové zátěže
První upgrade AKS Standard Základní upgrade clusteru AKS
Více prostředí nebo provoz vozového parku Centrum scénářů pro upgrade
Fondy uzlů nebo uzly Windows v AKS Standard Upgrady fondu uzlů
Pouze konkrétní skupina uzlů Aktualizace jednoho uzlového fondu

Modernizace provozních modelů

Automatická funkce AKS je ve výchozím nastavení určená pro operaci připravenou pro produkční prostředí. Pro upgrady poskytuje služba AKS Automatic:

  • Skupiny uzlů spravovaného systému
  • Chování automatického upgradu clusteru s výchozími nastaveními spravovanými platformou
  • Chování při automatickém upgradu bitové kopie operačního systému uzlu s kadencí zaměřenou na zabezpečení
  • Integrované kontroly zastaralých rozhraní API Kubernetes
  • Podpora plánu plánované údržby

Použijte AKS Automatic, pokud chcete minimalizovat ruční koordinaci upgradů a udržet produkční clustery v souladu s podporovanými verzemi s menší námahou.

AKS Standard (rozšířený řídicí model)

AKS Standard poskytuje přímou kontrolu nad sekvencováním a laděním upgradu. Zvolíte a spravujete:

  • Konfigurace ručního nebo automatického upgradu
  • Výběr kanálu pro upgrade
  • Fond uzlů a chování navýšení.
  • Provozní postupy související s časovými obdobími údržby a rozpočty přerušení úloh

Použijte AKS Standard, pokud vaše prostředí vyžaduje přizpůsobení, které přesahuje automatické výchozí hodnoty AKS.

Aktualizace iniciované platformou

Na oba provozní modely se vztahují upgrady iniciované platformou. Pokud cluster zůstane na nepodporované verzi Kubernetes po uplynutí 60denní doby odkladu podpory platformy , AKS ho automaticky upgraduje na podporovanou verzi.

Upgrady iniciované platformou nedodržují časové období údržby a nespouštějí kontrolu zastaralých rozhraní API. Udržování clusteru v podporované verzi je jediným způsobem, jak udržet plnou kontrolu nad načasováním a chováním upgradu. Další informace najdete v tématu Jak se vyhnout upgradům iniciovaným platformou.

Možnosti upgradu

Provedení ručních upgradů

Platí primárně pro AKS Standard nebo pro specializované provozní pracovní postupy.

Ruční upgrady umožňují řídit, kdy se cluster upgraduje na novou verzi Kubernetes. Tyto upgrady jsou užitečné pro testování, postupné zavedení a přijetí cílových verzí.

Konfigurace automatických upgradů

U AKS Standard pomáhají automatické upgrady udržovat clustery v podporovaných verzích a přitom zachovat kontrolu nad zásadami a plánováním. Automatizace upgradu a mantinely v AKS jsou již součástí výchozího provozního modelu.

Zvláštní úvahy pro fondy uzlů, které zahrnují více zón dostupnosti

AKS používá ve fondech uzlů vyrovnávání mezi zónami v režimu best-effort. Během nárůstu upgradu jsou předem neznámé zóny pro uzly s náhlým nárůstem ve škálovacích sadách virtuálních počítačů, což může dočasně způsobit nevyváženou konfiguraci zón. AKS po upgradu odstraní přídavné uzly a obnoví původní rovnováhu zóny.

Pokud chcete zachovat vyvážení zón, nastavte nárůst na násobek tří uzlů. Trvalé nároky na objem, které používají místně redundantní disky úložiště Azure, jsou vázány na zónu a mohou způsobit výpadky, pokud jsou rozšiřující uzly v jiné zóně. Pomocí rozpočtu na přerušení podu (PDB) udržujte vysokou dostupnost během vyprázdnění.

Optimalizace upgradů za účelem zlepšení výkonu a minimalizace přerušení

Zkombinujte plánované okno údržby, maximální navýšení, PDB, časový limit pro vyprázdnění uzlu a dobu stabilizace uzlu, abyste zvýšili pravděpodobnost úspěšných aktualizací s minimálním narušením provozu.

AKS automatické

V AKS Automatic je chování při upgradu na úrovni platformy předem nakonfigurováno. Zaměřte se na optimalizaci odolnosti úloh a připravenosti kapacity:

  • Ověřte rozpočty přerušení podů a počty replik.
  • Zajistěte kvótu a kapacitu podsítě pro očekávaný růst.
  • Nastavte plány plánované údržby odpovídající obdobím s nízkým provozem.
  • Monitorujte události upgradu a připravenost kritických úloh.

AKS Standard

V AKS Standard vylaďte ovládací prvky upgradu přímo:

Nastavení aktualizace Jak se používají další uzly Očekávané chování
maxSurge=5, maxUnavailable=0 5 uzlů pro zvládání přepětí Pro vylepšení je urychleno pět uzlů.
maxSurge=5, maxUnavailable=0 0–4 přepětí uzlů Upgrade selže kvůli nedostatečným uzlům přepětí.
maxSurge=0, maxUnavailable=5 N/A Pro upgrade se vyprázdní pět existujících uzlů.

Poznámka:

Před upgradem zkontrolujte zásadní změny rozhraní API a projděte si poznámky k verzi AKS , abyste se vyhnuli přerušení.

Před upgradem na Kubernetes 1.37 ověřte LocalDNS a vlastní DNS.

Počínaje verzí Kubernetes 1.37 AKS ve výchozím nastavení nastaví standardní fond uzlů AKS, který nemá explicitně nastavený profil LocalDNS, do režimu Preferred a povolí LocalDNS, když fond uzlů projde kontrolami kompatibility. Tato změna ovlivňuje cestu DNS pro úlohy a může odhalit stávající vlastní konfigurace DNS nebo firewallu, které podporují UDP na portu 53, ale nepodporují TCP na portu 53.

Před upgradem fondu uzlů na Kubernetes 1.37 nebo novějším:

  1. Zkontrolujte, jestli má fond uzlů explicitní profil LocalDNS.

  2. Otestujte vlastní server DNS virtuální sítě z uzlu AKS přes UDP i TCP.

    dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

  3. Ověřte, že NSG, brány firewall, síťová virtuální zařízení a trasy povolují port 53 pro protokoly UDP i TCP.

  4. Nejprve upgradujte neprodukční fond uzlů a monitorujte chyby CoreDNS a LocalDNS.

  5. Pokud cesta DNS není připravená pro LocalDNS, explicitně ji nakonfigurujte mode jako Disabled před upgradem.

Pokyny ke konfiguraci a odhlášení najdete v tématu Konfigurace localDNS v AKS.

Ověření použitá v procesu upgradu

AKS provádí ověření před upgradem, aby se zajistil stav clusteru:

  • Zásadní změny rozhraní API: Detekuje zastaralá rozhraní API.
  • Verze upgradu Kubernetes: Zajišťuje platnou cestu pro upgrade.
  • Konfigurace PDB: Kontroluje chybně nakonfigurované soubory PDB (například maxUnavailable=0).
  • Kvóta: Zajišťuje dostatečnou kvótu pro uzly zátěže.
  • Podsíť: Ověřuje dostatečné IP adresy.
  • Certifikáty/služební identity: Detekuje vypršené přihlašovací údaje.
  • Kontrola zámků spravovaných prostředků: Kontroluje zámky prostředků použité u skupiny prostředků spravovaného clusteru.

Tyto kontroly platí pro AKS. V AKS Automatic jsou integrované do spravované cesty upgradu; ve službě AKS Standard jsou součástí vašeho provozního pracovního postupu.

Poznámka:

Upgrady iniciované platformou obcházejí ověřování nekompatibilních změn rozhraní API a ověřování PDB, aby se upgrade mohl dokončit. Spusťte tyto kontroly sami a vyřešte všechny problémy před měsícem, ve kterém je pro váš cluster naplánován upgrade iniciovaný platformou.

Běžné scénáře upgradu a doporučení

Scénář 1: Omezení kapacity

Pokud je cluster omezený podle úrovně produktu nebo regionální kapacity, upgrady můžou selhat, když není možné zřídit přepětí uzlů. Tato situace je běžná u specializovaných úrovní produktů (jako jsou uzly GPU) nebo v oblastech s omezenými prostředky. Chyby, jako například SKUNotAvailable, AllocationFailed nebo OverconstrainedAllocationRequest mohou nastat, pokud hodnota maxSurge je nastavena příliš vysoko pro dostupnou kapacitu.

Automatické navádění AKS

  • Udržujte časová období plánované údržby.
  • Před očekávanými obdobími upgradu ověřte kvótu předplatného a rezervu kapacity podsítě.
  • Udržujte rozpočty škálování a přerušení úloh v souladu s časovými obdobími údržby.

Pokyny pro AKS Standard

Scénář 2: Selhání vyprázdnění uzlů a soubory PDB

Upgrady vyžadují vyprázdnění uzlů (vyřazení podů). Evikce mohou selhat, když jsou pody pomalu ukončovány nebo striktní rozpočty narušení podů (PDB) blokují odstranění podů.

Příklad chyby:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Automatické navádění AKS

  • Strategii PDB a replikace považujte za primární mechanismy pro zajištění spolehlivosti.
  • Před uvedením do produkčního prostředí ověřte rozpočty přerušení v přípravném prostředí.
  • Udržujte kritické úlohy nastavené tak, aby bylo postupné vyprazdňování úspěšné.

Pokyny pro AKS Standard

Možnost 1: Vynucení upgradu, obejití omezení PDB

Výstraha

Vynucený upgrade obchází omezení PDB (Pod Disruption Budget) a může způsobit výpadek služby tím, že současně odpojí všechny pody. Před použitím této možnosti se nejprve pokuste opravit chybné konfigurace PDB (zkontrolujte nastavení PDB minAvailable/maxUnavailable, zajistěte dostatečné repliky podů, ověřte, že PDB neblokují všechny evikce).

Vynucený upgrade používejte jenom v případě, že soubory PDB brání kritickým upgradům a nelze je vyřešit. Tato akce přepíše ochranu PDB a může potenciálně způsobit nedostupnost kompletní služby během upgradu.

Požadavky: Azure CLI verze 2.79.0 nebo a novější nebo rozhraní API AKS verze 2025-09-01 nebo novější

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Poznámka:

  • Parametr upgrade-override-until definuje, kdy skončí obcházení ověřování (musí to být budoucí datum a čas).
  • Pokud není zadáno, ve výchozím nastavení se okno nastaví na tři dny od aktuálního času.
  • Označuje Z časové pásmo UTC/GMT.

Výstraha

Pokud je povolený vynucený upgrade, má přednost před všemi ostatními konfiguracemi vyprázdnění. Nastavení chování nevyprázdnitelného uzlu (možnost 2) se nepoužijí, pokud je aktivní vynucená aktualizace.

Možnost 2: Řešení uzlů, které nelze vyprázdnit, při dodržení PDB

Pomocí tohoto konzervativního přístupu můžete respektovat soubory PDB a zároveň zabránit selháním upgradu.

Nakonfigurujte chování nevyprázdnitelného uzlu:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Možnosti chování:

  • Plánování (výchozí): Odstraní blokovaný uzel a navýší počet náhradních uzlů.
  • Cordon (doporučeno): Uzel Cordons a jeho označení jako kubernetes.azure.com/upgrade-status=Quarantined.

Maximální počet blokovaných uzlů:

  • Určuje, kolik uzlů, které se nepodařilo vyprázdnit, je tolerováno.
  • Vyžaduje, aby undrainable-node-behavior bylo nastaveno
  • Je-li maxSurge hodnota neurčena, použije se výchozí hodnota (obvykle 10%).
  • Podobně jako maximální nárůst výkonu platí, že pokud je vypočítaná hodnota vyšší než počet uzlů, které se mají upgradovat v aktuální operaci, použije se místo toho počet zbývajících uzlů, které se mají upgradovat.
Příklad konfigurace s maximálním blokovanými uzly
az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5
Možnost 3: Automatická správa PDB (Preview)

Pomocí rozšíření pro automatickou správu PDB můžete proaktivně řešit operace vyprázdnění blokované zásadami PDB, aniž byste obcházeli ochrany PDB nebo museli ručně vyčistit uzly v karanténě. Automatická správa PDB rozpozná, když PDB blokuje vystěhování na uzlu označeném jako nedostupný pro plánování, a dočasně navýší počet replik nasazení tak, aby byl rozpočet narušení splněn. Po dokončení vyprázdnění se počet replik vrátí na původní hodnotu.

Automatická správa PDB může také automaticky vytvářet soubory PDB pro nasazení, která nemají jednu, a zajistit tak ochranu úloh během vyprázdnění upgradu. Podrobnosti o instalaci a konfiguraci najdete v tématu Správa rozpočtů přerušení podů automaticky během upgradů AKS.

Doporučení k zabránění selháním vyprázdnění
  • Nastavte maxUnavailable v souborech PDB, aby bylo možné vyřazení alespoň jednoho podu.
  • Zvýšení replik podů tak, aby splňovaly požadavky na rozpočet přerušení
  • Pokud úlohy potřebují více času, prodlužte časový limit vyprázdnění. (Výchozí hodnota je 30 minut.)
  • Automatická správa PDB slouží k automatizaci vytváření PDB a škálování replik během operací vyprázdnění.
  • Otestujte soubory PDB ve testovacím prostředí, monitorujte události upgradu a používejte modrá-zelená nasazení pro kritické úlohy. Další informace najdete v tématu Blue-green nasazení clusterů AKS.
Ověření neodvodnitelných uzlů

  • Blokované uzly nejsou naplánované pro pody a jsou označeny štítkem "kubernetes.azure.com/upgrade-status: Quarantined".

  • Pokud při upgradu dojde k selhání vyprázdnění uzlu, ověřte štítek kteréhokoliv blokovaného uzlu:

    kubectl get nodes --show-labels=true
Řešení nedrenážovatelných uzlů

  1. Odeberte zodpovědný soubor PDB:

    kubectl delete pdb <pdb-name>

  2. Odstraňte štítek kubernetes.azure.com/upgrade-status: Quarantined.

    kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-

  3. Volitelně můžete odstranit blokovaný uzel:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. Po dokončení tohoto kroku můžete uvést stav clusteru do souladu provedením libovolné aktualizace bez volitelných polí, jak je popsáno v az aks. Případně můžete fond uzlů škálovat na stejný počet uzlů jako počet upgradovaných uzlů. Tato akce zajistí, že se fond uzlů dostane k zamýšlené původní velikosti. AKS upřednostňuje odebrání blokovaných uzlů. Tento příkaz také obnoví stav zřizování clusteru do Succeeded. V následujícím příkladu 2 je celkový počet upgradovaných uzlů.

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

Scénář 3: Pomalé upgrady

Konzervativní nastavení nebo problémy na úrovni uzlu můžou zpozdit upgrady, což má vliv na vaši schopnost udržet si přehled o opravách a vylepšeních.

Mezi běžné příčiny pomalých upgradů patří:

Automatické navádění AKS

  • Udržujte plány údržby aktuální.
  • Monitorujte stav událostí upgradu a připravenost úloh.
  • Vyřešte problémy s blokováním souborů PDB nebo kapacity rychle, abyste se vyhnuli delší prodlevě.

Pokyny pro AKS Standard

  • Použijte maxSurge=33%, maxUnavailable=1 pro produkční prostředí.
  • Použijte maxSurge=50%, maxUnavailable=2 pro vývoj/testování.
  • Oprava zabezpečení OS slouží k rychlému a cílenému opravení (vyhne se úplnému přeformátování uzlu).
  • Povolte --undrainable-node-behavior , abyste se vyhnuli blokování upgradu.

Scénář 4: Vyčerpání IP adres

Uzly se zvýšenou potřebou vyžadují více IP adres. Pokud je podsíť blízko své kapacity, může zřizování uzlů selhat (například Error: SubnetIsFull). Tento scénář je běžný s rozhraním Azure Container Networking Interface, vysokým maxPodsnebo velkým počtem uzlů.

Automatické navádění AKS

  • Před rozšířením produkčního prostředí ověřte plány podsítí a kapacitní plány.
  • Monitorujte využití sítě jako součást rutinních operací.

Pokyny pro AKS Standard

  • Ujistěte se, že vaše podsíť má dostatek IP adres pro všechny uzly, surge uzly a pod jednotky. Vzorec je Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

  • Uvolněte nepoužívané IP adresy nebo rozbalte podsíť (například z /24 na /22).

  • Snižte maxSurge, pokud rozšíření podsítě není možné.

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • Monitorování využití IP adres pomocí služby Azure Monitor nebo vlastních upozornění

  • Upravte maxPods pro každý uzel, vyčistěte osamocené IP adresy nástrojů pro vyrovnávání zatížení a naplánujte velikost podsítě pro clustery s vysokou škálovatelností.

Nejčastější dotazy

Mám pro produkční upgrady použít AKS Automatic nebo AKS Standard?

Pro většinu produkčních úloh použijte AKS Automaticky. Je navrženo jako výchozí volba připravená pro produkční nasazení, s řízeným procesem aktualizace a vestavěnými ochrannými mechanismy.

AKS Standard použijte, pokud potřebujete pokročilou ruční kontrolu nad sekvencováním upgradu, volbami infrastruktury nebo operacemi fondu uzlů.

Můžu k ověření použít opensourcové nástroje?

Ano. Mnoho opensourcových nástrojů se dobře integruje s procesy upgradu AKS:

  • Trivy: Bezpečnostní skenování pro image kontejnerů a konfigurace Kubernetes.
  • Sonobuoy: Testování shody Kubernetes a ověřování clusteru
  • kube-bench: Kontroly benchmarků zabezpečení podle standardů Centra pro internetovou bezpečnost.
  • Polaris: Ověření osvědčených postupů Kubernetes
  • kubectl-neat: Vyčistěte manifesty Kubernetes pro ověření.

Jak před upgradem ověřím kompatibilitu rozhraní API?

Pomocí nástrojů, jako je kubent, spusťte kontroly vyřazení:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Co znamená, že se upgrady AKS liší od jiných platforem Kubernetes?

AKS nabízí několik jedinečných výhod:

  • Spravované provozní postupy v AKS Automatic pro menší režii při upgradu
  • Nativní integrace Azure s Azure Traffic Managerem, Azure Load Balancerem a sítěmi
  • Azure Kubernetes Fleet Manager pro koordinované multiclusterové upgrady.
  • Automatická oprava image uzlu bez ruční správy uzlů
  • Integrované ověřování pro kvóty, sítě a přihlašovací údaje
  • Podpora Azure pro problémy související s upgradem

Volba cesty upgradu

Tento článek vám poskytl technický základ. Teď vyberte cestu založenou na scénáři.

Jste připravení provést?

Pokud máte... Pak přejděte na...
Produkční úlohy a žádná zvláštní omezení přizpůsobení Vytvoření automatického clusteru AKS
Produkční prostředí s pokročilými specifickými požadavky na upgrade Strategie upgradu produkčního prostředí
Databáze nebo stavové aplikace Vzory stavové zátěže
Více prostředí Centrum scénářů pro upgrade
Základní cluster AKS Standard Aktualizovat cluster AKS

Stále se rozhodujete?

Použijte centrum scénářů upgradu pro strukturovaného průvodce, který zohledňuje vaše:

  • Odolnost proti výpadkům
  • Složitost prostředí
  • Profil rizika
  • Omezení časové osy

Konečná doporučení

  • Používejte AKS Automatic pro většinu produkčních úloh.
  • Než začnete s upgradem, projděte si pokyny k opravám a upgradu AKS a projděte si osvědčené postupy a tipy pro plánování.
  • Vždy zkontrolujte zásadní změny rozhraní API a ověřte kompatibilitu vaší úlohy s cílovou verzí Kubernetes.
  • Otestujte nastavení upgradu (například maxSurge, maxUnavailablea soubory PDB) v přípravném prostředí, abyste minimalizovali provozní riziko.
  • V průběhu procesu monitorujte události upgradu a stav clusteru.
  • Poslední aktualizace v