Nejčastější dotazy k AKS

Tento článek obsahuje odpovědi na některé z nejběžnějších otázek k Azure Kubernetes Service (AKS).

Technická podpora

Nabízí AKS smlouvu o úrovni služeb?

AKS poskytuje záruky smlouvy o úrovni služeb (SLA) v cenové vrstvě Standard s funkcí SLA pro provozní dostupnost.

Co je podpora platformy a co zahrnuje?

Podpora platformy je plán redukované podpory pro clustery s nepodporovanými n-3 verzemi. Podpora platformy zahrnuje pouze podporu infrastruktury Azure.

Další informace najdete v zásadách podpory platformy.

Upgraduje AKS automaticky nepodporované clustery?

Ano, AKS zahájí automatické upgrady pro nepodporované clustery. Když se cluster ve verzi n-3 (kde n je nejnovější podporovaná podverze AKS, která je obecně dostupná) chystá přejít na n-4, AKS cluster automaticky upgraduje na n-2, aby zůstal v zásadách podpory AKS.

Další informace najdete v tématu Podporované verze Kubernetes, časové intervaly plánované údržby a automatické upgrady.

Mohou se na agentní uzly AKS vztahovat slevy za rezervace Azure?

Uzly agenta AKS se účtují jako standardní virtuální počítače Azure. Pokud jste si zakoupili rezervace Azure pro velikost virtuálního počítače, kterou používáte v AKS, se tyto slevy použijí automaticky.

Operace

Můžu v AKS spouštět kontejnery Windows Server?

Ano, AKS podporuje Windows Server kontejnery. Další informace najdete v Windows Server nejčastějších dotazech k AKS.

Jaké operační systémy Linux (OS) jsou podporovány v AKS?

AKS podporuje čtyři hlavní operační systémy Linux, včetně Ubuntu Linuxu, Azure Linux, Azure Linux OS Guard a Flatcar Container Linux pro AKS. Při zadávání --os-type Linux během vytváření fondu uzlů nebo vytváření clusteru je výchozím operačním systémem Ubuntu Linux.

Jaké verze operačních systémů (OS) jsou podporovány v AKS?

Při použití --os-sku Ubuntu se ve výchozím nastavení v AKS používá Ubuntu 22.04 na verzích Kubernetes 1.25-1.34. AKS ve výchozím nastavení používá Ubuntu 24.04 ve verzi Kubernetes 1.35 nebo novější. Při použití --os-sku AzureLinux AKS ve verzi Kubernetes 1.32 nebo novější standardně používá Azure Linux 3.0. V některých scénářích, jako jsou fondy uzlů s podporou FIPS, se výchozí verze operačního systému může lišit. Další informace najdete v obrázcích uzlů .

Mohu přesunout nebo migrovat cluster mezi tenanty Azure?

Ne. Přesun clusteru AKS mezi tenanty není v tuto chvíli podporován.

Můžu přesunout nebo migrovat cluster mezi předplatnými?

Ne. Přesun clusteru AKS mezi předplatnými se v současné době nepodporuje.

Můžu přesunout nebo migrovat cluster do jiné virtuální sítě?

Ne. Přesun clusteru AKS do jiné virtuální sítě se v současné době nepodporuje.

Můžu přesunout cluster AKS nebo prostředky infrastruktury AKS do jiných skupin prostředků nebo je přejmenovat?

Ne. Přesun nebo přejmenování clusteru AKS a přidružených prostředků se nepodporuje.

Můžu cluster po odstranění obnovit?

Ne. Po odstranění clusteru nemůžete cluster obnovit. Když cluster odstraníte, odstraní se také skupina prostředků uzlu a všechny její prostředky.

Pokud chcete zachovat některý z vašich prostředků, před odstraněním clusteru je přesuňte do jiné skupiny prostředků. Pokud chcete chránit před náhodným odstraněním, můžete uzamknout spravovanou skupinu prostředků AKS, která je hostitelem prostředků clusteru, pomocí uzamčení skupiny prostředků Node.

Můžu škálovat cluster AKS na nulu?

Můžete úplně zastavit běžící cluster AKS nebo škálovat či autoskalovat všechny nebo konkrétní fondy uzlů na nulu.

Pooly systémových uzlů není možné přímo škálovat na nulu.

Můžu k ručnímu škálování použít rozhraní API škálovací sady virtuálních počítačů?

Ne. Operace škálování, které používají rozhraní API škálovací sady virtuálních počítačů, se nepodporují. Můžete použít rozhraní API AKS (az aks scale).

Můžu škálovací sady virtuálních počítačů použít k ručnímu škálování na nula uzlů?

Ne. Operace škálování, které používají rozhraní API škálovací sady virtuálních počítačů, se nepodporují. Rozhraní API AKS můžete použít ke škálování uzlových fondů, které nejsou systémové, na nulu nebo k zastavení vašeho clusteru.

Můžu zastavit nebo uvolnit všechny virtuální počítače?

Ne. Tato konfigurace není podporovaná. Místo toho zastavte klastr .

Proč se pomocí AKS vytvářejí dvě skupiny prostředků?

AKS vychází z mnoha prostředků infrastruktury Azure, včetně škálovacích sad virtuálních počítačů, virtuálních sítí a spravovaných disků. Díky těmto integracím můžete použít řadu základních funkcí platformy Azure v rámci spravovaného prostředí Kubernetes, které poskytuje AKS. Můžete například použít většinu typů virtuálních počítačů Azure přímo s AKS a rezervace Azure můžete využít k automatickému získání slev na tyto prostředky.

Pokud chcete tuto architekturu povolit, každé nasazení AKS zahrnuje dvě skupiny prostředků:

1. Vytvoříte první skupinu prostředků. Tato skupina obsahuje pouze zdroj služby Kubernetes. Poskytovatel prostředků AKS během nasazování automaticky vytvoří druhou skupinu prostředků. Příkladem druhé skupiny prostředků je MC_myResourceGroup_myAKSCluster_eastus. Informace o tom, jak zadat název této druhé skupiny prostředků, najdete v další části.
2. Druhá skupina prostředků označovaná jako skupina prostředků uzlu obsahuje všechny prostředky infrastruktury přidružené ke clusteru. Mezi tyto prostředky patří virtuální počítače uzlů Kubernetes, virtuální sítě a úložiště. Ve výchozím nastavení má skupina prostředků uzlu název ve tvaru MC_myResourceGroup_myAKSCluster_eastus. AKS automaticky odstraní skupinu prostředků uzlu při každém odstranění clusteru. Tuto skupinu prostředků použijte pouze pro prostředky, které sdílejí životní cyklus clusteru.

Poznámka:

Úprava jakéhokoli prostředku ve skupině prostředků uzlu v clusteru AKS je nepodporovaná akce a způsobí selhání operací clusteru. Můžete zabránit změnám ve zdrojové skupině uzlů. Zablokujte uživatelům úpravu prostředků , které cluster AKS spravuje.

Můžu pro skupinu prostředků uzlu AKS použít vlastní název?

Ve výchozím nastavení AKS pojmenuje skupinu prostředků pro uzly MC_resourcegroupname_clustername_location, ale můžete zadat vlastní název.

Pokud chcete zadat vlastní název skupiny prostředků, nainstalujte rozšíření Azure CLI aks-preview ve verzi 0.3.2 nebo novější. Při vytváření clusteru AKS pomocí az aks create příkazu použijte --node-resource-group parametr a zadejte název skupiny prostředků. Pokud k nasazení clusteru AKS použijete šablonu Azure Resource Manager, můžete název skupiny prostředků definovat pomocí vlastnosti nodeResourceGroup.

• Poskytovatel prostředků Azure automaticky vytvoří sekundární skupinu prostředků.
• Název vlastní skupiny prostředků můžete zadat pouze při vytváření clusteru.

Při práci se skupinou prostředků uzlu nemůžete:

• Zadejte existující skupinu prostředků pro skupinu prostředků uzlu.
• Zadejte jiné předplatné pro skupinu prostředků uzlu.
• Po vytvoření clusteru změňte název skupiny prostředků uzlu.
• Zadejte názvy spravovaných prostředků ve skupině prostředků uzlu.
• Upravte nebo odstraňte Azure-vytvořené značky spravovaných prostředků v rámci skupiny prostředků uzlu.

Můžu upravit značky a další vlastnosti prostředků AKS v uzlové skupině prostředků?

Pokud upravíte nebo odstraníte značky vytvořené službou Azure a další vlastnosti prostředků ve skupině prostředků pro uzly, možná dojde k neočekávaným chybám při škálování a upgradu. AKS umožňuje vytvářet a upravovat vlastní značky vytvořené koncovými uživateli a tyto značky můžete přidat při vytváření fondu uzlů. Možná budete chtít vytvořit nebo upravit vlastní značky, například pro přiřazení obchodní jednotky nebo nákladového střediska. Další možností je použít zásady a upravit značky přímo prostřednictvím samotného prostředku AKS – konkrétně prostřednictvím clusteru a fondů uzlů.

Značky vytvořené Azure jsou určeny pro odpovídající služby Azure a měli byste je vždy akceptovat. Pro AKS jsou k dispozici značky aks-managed a k8s-azure. Úprava značek vytvořených Azure na prostředcích ve skupině prostředků uzlu v clusteru AKS je nepodporovaná akce, která přeruší SLO (cíle úrovně služeb).

Poznámka:

V minulosti byl název značky Owner vyhrazen pro AKS kvůli správě veřejné IP adresy, která je přiřazena na front-endovou IP adresu v rámci vyrovnávače zátěže. Služby teď používají předponu aks-managed . U starších prostředků nepoužívejte zásady Azure k použití názvu značky Owner. Pokud ne, všechny prostředky vašeho nasazení a operací aktualizace clusteru AKS se přeruší. Toto omezení se nevztahuje na nově vytvořené prostředky.

Proč se v clusteru zobrazují verze Helm spravované předponou aks a proč se jejich počet revizí stále zvyšuje?

AKS používá Helm k doručování komponent do clusteru. Můžete bezpečně ignorovat verze Helm s předponou aks-managed. Průběžné zvyšování revizí těchto verzí Helmu je očekávané a bezpečné.

Kvóty, limity a dostupnost oblastí

Které Azure oblasti aktuálně poskytují AKS?

Úplný seznam dostupných oblastí najdete v tématu Oblasti a dostupnost AKS.

Můžu cluster AKS rozšířit mezi oblasti?

Ne. Clustery AKS jsou regionální prostředky a nemůžou zahrnovat oblasti. Pokyny k vytvoření architektury, která zahrnuje více oblastí, najdete v osvědčených postupech pro provozní kontinuitu a zotavení po havárii.

Můžu rozdělit klastr AKS mezi zóny dostupnosti?

Ano, cluster AKS můžete nasadit napříč jednou nebo více zónami dostupnosti v oblastech, které je podporují.

Můžu mít v jednom clusteru různé velikosti virtuálních počítačů?

Ano, v clusteru AKS můžete použít různé velikosti VM tím, že vytvoříte více uzlových fondů.

Jaký je limit velikosti image kontejneru v AKS?

AKS nenastavuje omezení velikosti image kontejneru. Čím je ale obrázek větší, tím vyšší je poptávka po paměti. Větší velikost může potenciálně překročit limity prostředků nebo celkovou dostupnou paměť pracovních uzlů. Ve výchozím nastavení je paměť pro velikost virtuálního počítače Standard_DS2_v2 pro cluster AKS nastavená na 7 GiB.

Pokud je image kontejneru příliš velká, například v rozsahu terabajtu (TB), kubelet ji nemusí kvůli nedostatku místa na disku načíst z registru kontejneru do uzlu.

U uzlů Windows Server se služba Windows Update nespustí automaticky a použije nejnovější aktualizace. V clusteru AKS byste měli provést upgrade clusteru i fondů uzlů Windows Server. Postupujte podle běžného plánu na základě cyklu vydávání služba Windows Update a vlastního procesu ověřování. Tento proces upgradu vytvoří uzly, na kterých běží nejnovější Windows Server image a opravy, a potom odebere starší uzly. Další informace o tomto procesu najdete v tématu Upgrade fondu uzlů v AKS.

Jsou image AKS nutné ke spuštění jako kořenové?

Následující obrazy mají funkční požadavky pro spuštění jako root a výjimky musí být podávány pro jakékoli zásady.

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Zabezpečení, přístup a identita

Můžu omezit, kdo má přístup k serveru rozhraní API Kubernetes?

Ano, existují dvě možnosti omezení přístupu k serveru rozhraní API:

• Pokud chcete zachovat veřejný koncový bod pro server rozhraní API, ale omezit přístup k sadě důvěryhodných rozsahů IP adres, použijte rozsahy IP autorizovaných serverů rozhraní API .
• Privátní cluster použijte, pokud chcete omezit, aby byl server rozhraní API přístupný jenom z vaší virtuální sítě.

Jsou na uzly agenta AKS aplikovány aktualizace zabezpečení?

AKS každý týden opravuje CVE, které mají opravu od dodavatele. CVE bez opravy čekají na opravu od dodavatele, než je lze vyřešit. Image AKS se automaticky aktualizují do 30 dnů. Doporučujeme použít aktualizovanou image uzlu v pravidelných intervalech, abyste měli jistotu, že se všechny nejnovější opravené image a opravy operačního systému použijí a budou aktuální. Tento úkol můžete provést:

• Ručně prostřednictvím portálu Azure nebo Azure CLI.
• Aktualizací vašeho clusteru AKS. Cluster upgraduje kabelon a vyprázdní uzly automaticky. Pak je online zprovozněn nový uzel s nejnovějším obrazem Ubuntu a opravenou verzí nebo menší verzí Kubernetes. Další informace najdete v tématu Upgrade clusteru AKS.
• Pomocí upgradu obrazu uzlu.

Existují bezpečnostní hrozby, které cílí na AKS, o které bych měl vědět?

Microsoft poskytuje pokyny pro další akce, které můžete provést k zabezpečení úloh prostřednictvím služeb, jako je Microsoft Defender pro kontejnery. Informace o bezpečnostní hrozbě související s AKS a Kubernetes najdete v tématu Nové rozsáhlé kampaně cílí na Kubeflow (8. června 2021).

Ukládá AKS nějaká zákaznická data mimo oblast clusteru?

Ne. Všechna data jsou uložená v oblasti clusteru.

Jak se můžu vyhnout pomalým problémům s nastavením vlastnictví oprávnění, když má svazek velké množství souborů?

Tradičně platí, že pokud je pod spuštěný jako ne-root uživatel (což by měl být), musíte zadat parametr fsGroup v kontextu zabezpečení podu, aby byl svazek čitelný a zapisovatelný pro pod. Další informace o tomto požadavku najdete v tématu Konfigurace kontextu zabezpečení pro pod nebo kontejner.

Vedlejším účinkem nastavení fsGroup je, že při každém připojení svazku musí Kubernetes používat příkazy chown() a chmod() rekurzivně pro všechny soubory a adresáře uvnitř svazku (s několika výjimkami). K tomuto scénáři dochází i v případě, že vlastnictví skupiny svazku už odpovídá požadovanému fsGroup parametru. Tato konfigurace může být nákladná pro větší svazky s velkým množstvím malých souborů, což může způsobit, že spuštění podu trvá dlouhou dobu. Tento scénář byl známým problémem před v1.20. Řešením je nastavit pod tak, aby běžel jako uživatel root.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Problém se vyřešil s Kubernetes verze 1.20. Další informace najdete v tématu Kubernetes 1.20: Podrobné řízení změn oprávnění svazků.

Sítě

Jak řídicí rovina spravovaného systému komunikuje s mými uzly?

AKS používá zabezpečený tunel pro komunikaci, aby umožnil komunikaci api-server a jednotlivých kubeletů uzlů, a to i v oddělených virtuálních sítích. Tunel je zabezpečený prostřednictvím vzájemného šifrování Transport Layer Security. Aktuální hlavní tunel, který AKS používá , je Konnectivity, dříve označovaný jako apiserver-network-proxy. Ověřte, že všechna pravidla sítě dodržují pravidla Azure požadovaná pravidla sítě a plně kvalifikované názvy domén (FQDN).

Můžou pody místo IP adresy clusteru používat plně kvalifikovaný název domény serveru API?

Ano, můžete přidat poznámku kubernetes.azure.com/set-kube-service-host-fqdn k podům a nastavit KUBERNETES_SERVICE_HOST proměnnou na název domény serveru ROZHRANÍ API místo IP adresy služby v clusteru. Tato úprava je užitečná v případech, kdy se výchozí přenos dat clusteru provádí přes bránu firewall vrstvy 7. Příkladem je použití Azure Firewall s pravidly aplikace.

Mohu nakonfigurovat skupiny zabezpečení sítě v AKS?

AKS u své podsítě nepoužije skupiny zabezpečení sítě (NSG) a neupravuje žádné skupiny zabezpečení sítě přidružené k této podsíti. AKS upravuje pouze nastavení NSG síťového rozhraní. Pokud používáte rozhraní Container Network Interface (CNI), musíte také zajistit, aby pravidla zabezpečení ve skupinách zabezpečení sítě (NSGs) umožňovala provoz mezi rozsahy beztřídního mezidoménového směrování (CIDR) pro uzly a pody. Pokud používáte kubenet, musíte také zajistit, aby pravidla zabezpečení v NSG umožňovala provoz mezi uzlem a CIDR podu. Další informace najdete v tématu Skupiny zabezpečení sítě.

Jak funguje synchronizace času v AKS?

Uzly AKS spouští službu chrony, která synchronizuje čas z místního hostitele. Kontejnery, které běží na podech, získají čas z uzlů AKS. Aplikace, které se otevřou uvnitř kontejneru, používají čas z kontejneru podu.

Doplňky, rozšíření a integrace

Můžu použít vlastní rozšíření virtuálních počítačů?

Ne. AKS je spravovaná služba. Manipulace s prostředky infrastruktury jako služby (IaaS) se nepodporuje. K instalaci vlastních komponent použijte rozhraní API a mechanismy Kubernetes. Pomocí daemonSets můžete například nainstalovat všechny požadované součásti.

Jaké kontrolery přístupu Kubernetes AKS podporuje? Dají se kontrolery přístupu přidat nebo odebrat?

AKS podporuje následující kontrolery přístupu:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

V současné době nemůžete změnit seznam kontrolerů přístupu v AKS.

Můžu na AKS používat webhooky přístupového kontroléru?

Ano, webhooky kontroleru přístupu můžete použít v AKS. Doporučujeme vyloučit interní obory názvů AKS, které jsou označené popiskem control-plane . Příklad:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS zajišťuje firewall pro odchozí provoz serveru API, takže vaše webhooky pro kontrolu přístupu musí být dostupné zevnitř clusteru.

Může webhooky kontroleru přístupu ovlivnit kube-systém a interní obory názvů AKS?

Aby AKS chránila stabilitu systému a zabránila tomu, aby vlastní kontrolery pro přijetí ovlivnily interní služby v kube-system oboru názvů, má AKS vynucovač přístupu, který automaticky vylučuje kube-system a interní obory názvů AKS. Tato služba zajišťuje, že vlastní kontrolery přístupu nemají vliv na služby spuštěné v kube-system.

Pokud máte kritický případ použití pro nasazení něčeho na kube-system (nedoporučuje se) na podporu vašeho vlastního admission webhooku, můžete přidat následující popisek nebo poznámku, aby jej mechanismus povolení ignoroval.

• Označit: "admissions.enforcer/disabled": "true"
• Anotace: "admissions.enforcer/disabled": true

Je Azure Key Vault integrovaná s AKS?

Poskytovatel Azure Key Vault pro ovladač Secrets Store CSI zajišťuje nativní integraci Azure Key Vault do AKS.

Můžu s nasazeními v AKS používat kryptografické knihovny FIPS?

Uzly, které jsou povolené pomocí standardu FIPS (Federal Information Processing Standards), se teď podporují ve fondech uzlů založených na Linuxu. Další informace najdete v Přidejte fond uzlů podporující FIPS.

Jak se aktualizují doplňky AKS?

Všechny opravy, včetně opravy zabezpečení, se automaticky aplikují na cluster AKS. Pokud je k dispozici nová verze, při aktualizaci clusteru se aktualizuje cokoli většího než oprava, například hlavní nebo vedlejší verze (které mohou obsahovat zásadní změny nasazených objektů). Informace o tom, kdy je k dispozici nová verze, najdete v poznámky k verzi AKS.

Jaký je účel rozšíření AKS pro Linux, které vidím nainstalované na instancích škálovacích sad virtuálních počítačů s Linuxem?

Rozšíření AKS pro Linux je rozšíření Azure virtuálních počítačů, které instaluje a konfiguruje monitorovací nástroje na pracovní uzly Kubernetes. Rozšíření se nainstaluje na všechny nové a existující linuxové uzly. Konfiguruje následující monitorovací nástroje:

• Exportér uzlů: Shromažďuje hardwarovou telemetrii z virtuálního počítače a zpřístupňuje ji pomocí koncového bodu metrik. Pak může monitorovací nástroj, jako je Například Prometheus, tyto metriky ošrotovat.
• Detektor problémů uzlů: Cílem je zviditelnit různé problémy uzlů pro výše postavené vrstvy ve správě clusteru. Je to jednotka systemd, která běží na každém uzlu, detekuje problémy uzlů a hlásí je serveru rozhraní API clusteru pomocí Events a NodeConditions.
• ig: Je opensourcová architektura s technologií eBPF pro ladění a sledování systémů Linux a Kubernetes. Poskytuje sadu nástrojů (nebo miniaplikací), které shromažďují relevantní informace, které můžou uživatelé použít k identifikaci příčiny problémů s výkonem, chybových ukončení nebo jiných anomálií. Pozoruhodné je, že její nezávislost na Kubernetes umožňuje uživatelům používat ji také pro ladění problémů s řídicí rovinou.

Tyto nástroje pomáhají zajistit pozorovatelnost řady problémů souvisejících se stavem uzlu, například:

• Problémy s démonem infrastruktury: Služba NTP nefunguje
• Problémy s hardwarem: Chybný procesor, paměť nebo disk
• Problémy s jádrem: Zablokování jádra, poškozený systém souborů
• Problémy s kontejnerovým runtime: Nereagující démon runtime

Rozšíření nevyžaduje dodatečný odchozí přístup k žádným adresám URL, IP adresám ani portům nad rámec zdokumentovaných požadavků na výchozí přenos dat AKS. Nevyžaduje žádná zvláštní oprávnění udělená v Azure. Používá kubeconfig k připojení k serveru rozhraní API a odesílání shromážděných monitorovacích dat.

Řešení problémů s clustery

Proč odstranění clusteru trvá tak dlouho?

Většina clusterů se odstraní na žádost uživatele. V některých případech, zejména tam, kde přinášíte vlastní skupinu prostředků nebo provádíte úkoly napříč skupinami prostředků, může odstranění trvat déle, nebo dokonce selhat. Pokud máte problém s odstraněním, důkladně zkontrolujte, že nemáte zámky na skupině prostředků. Také se ujistěte, že všechny prostředky mimo skupinu prostředků se oddělují od skupiny prostředků.

Proč vytvoření nebo aktualizace clusteru trvá tak dlouho?

Pokud máte problémy s vytvářením a aktualizací clusterů, ujistěte se, že nemáte přiřazené zásady ani omezení služeb, které by mohly vašemu clusteru AKS blokovat správu prostředků, jako jsou virtuální počítače, nástroje pro vyrovnávání zatížení nebo značky.

Pokud mám pody nebo nasazení ve stavu "NodeLost" nebo "Neznámý", mohu stále upgradovat cluster?

Můžete, ale nedoporučujeme to. Aktualizace proveďte, pokud je stav clusteru známý a v pořádku.

Pokud mám cluster s jedním nebo více uzly ve stavu Není v pořádku nebo je vypnutý, můžu provést upgrade?

Ne. Před upgradem odstraňte nebo odeberte všechny uzly, které jsou ve stavu selhání nebo jinak, z clusteru.

Pokusil(a) jsem se odstranit cluster, ale zobrazuje se mi chyba [Errno 11001] getaddrinfo selhala.

K této chybě nejčastěji dochází v případě, že používáte jednu nebo více skupin zabezpečení sítě, které jsou stále přidružené ke clusteru. Odeberte je a zkuste cluster znovu odstranit.

Spustil(a) jsem upgrade, ale teď jsou poddy v chybových smyčkách a zkoušky připravenosti selhávají.

Ověřte, že nevypršela platnost vašeho služebního principálu. Další informace najdete v tématu principál služby AKS a aktualizace přihlašovacích údajů AKS.

Můj cluster fungoval, ale najednou nemůžu zřídit vyrovnávače zatížení ani připojit trvalé požadavky na svazek.

Ověřte, že nevypršela platnost služebního účtu. Další informace najdete v tématu hlavní služba AKS a aktualizace přihlašovacích údajů AKS.

Vyřazení a znehodnocení

Které verze operačního systému Linux jsou v AKS zastaralé?

Od 17. března 2027 Azure Kubernetes Service (AKS) už nepodporuje nebo poskytuje aktualizace zabezpečení Ubuntu 20.04. Odstraní se všechny existující image uzlů a nebudete moct škálovat žádné fondy uzlů se systémem Ubuntu 20.04. Přesuňte se na podporovanou verzi Ubuntu aktualizací poolů uzlů na Kubernetes verze 1.35+. Další informace o tomto vyřazení najdete v problému na GitHubu o vyřazení a v oznámení o vyřazení aktualizací Azure. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS.

Které verze operačního systému Windows jsou v AKS zastaralé?

Od 1. března 2026 už Azure Kubernetes Service (AKS) nepodporuje fondy uzlů Windows Server 2019. Fondy uzlů, na kterých běží Kubernetes verze 1.33 nebo novější, nemůžou používat Windows Server 2019. Od 1. dubna 2027 AKS odstraní všechny existující obrazy uzlů pro Windows Server 2019, což znamená, že operace škálování budou selhávat. Další informace o tomto vyřazení najdete v problému na GitHubu o vyřazení a v oznámení o vyřazení aktualizací Azure. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS. Od 15. března 2027 už Azure Kubernetes Service (AKS) nepodporuje fondy uzlů Windows Server 2022. Fondy uzlů, na kterých běží Kubernetes verze 1.36 nebo novější, nemůžou používat Windows Server 2022. Od 1. dubna 2028 AKS odstraní všechny existující obrazy uzlů pro Windows Server 2022, což znamená, že operace škálování selžou. Další informace o tomto vyřazení najdete v problému na GitHubu o vyřazení a v oznámení o vyřazení aktualizací Azure. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS.

Tento článek obsahuje odpovědi na některé z nejběžnějších otázek k Azure Kubernetes Service (AKS).

AKS poskytuje záruky smlouvy o úrovni služeb (SLA) v cenové vrstvě Standard s funkcí SLA pro provozní dostupnost.

Podpora platformy je plán redukované podpory pro clustery s nepodporovanými n-3 verzemi. Podpora platformy zahrnuje pouze podporu infrastruktury Azure.

Další informace najdete v zásadách podpory platformy.

Ano, AKS zahájí automatické upgrady pro nepodporované clustery. Když se cluster ve verzi n-3 (kde n je nejnovější podporovaná podverze AKS, která je obecně dostupná) chystá přejít na n-4, AKS cluster automaticky upgraduje na n-2, aby zůstal v zásadách podpory AKS.

Další informace najdete v tématu Podporované verze Kubernetes, časové intervaly plánované údržby a automatické upgrady.

Uzly agenta AKS se účtují jako standardní virtuální počítače Azure. Pokud jste si zakoupili rezervace Azure pro velikost virtuálního počítače, kterou používáte v AKS, se tyto slevy použijí automaticky.

Ano, AKS podporuje Windows Server kontejnery. Další informace najdete v Windows Server nejčastějších dotazech k AKS.

AKS podporuje čtyři hlavní operační systémy Linux, včetně Ubuntu Linuxu, Azure Linux, Azure Linux OS Guard a Flatcar Container Linux pro AKS. Při zadávání --os-type Linux během vytváření fondu uzlů nebo vytváření clusteru je výchozím operačním systémem Ubuntu Linux.

Při použití --os-sku Ubuntu se ve výchozím nastavení v AKS používá Ubuntu 22.04 na verzích Kubernetes 1.25-1.34. AKS ve výchozím nastavení používá Ubuntu 24.04 ve verzi Kubernetes 1.35 nebo novější. Při použití --os-sku AzureLinux AKS ve verzi Kubernetes 1.32 nebo novější standardně používá Azure Linux 3.0. V některých scénářích, jako jsou fondy uzlů s podporou FIPS, se výchozí verze operačního systému může lišit. Další informace najdete v obrázcích uzlů .

Ne. Přesun clusteru AKS mezi tenanty není v tuto chvíli podporován.

Ne. Přesun clusteru AKS mezi předplatnými se v současné době nepodporuje.

Ne. Přesun clusteru AKS do jiné virtuální sítě se v současné době nepodporuje.

Ne. Přesun nebo přejmenování clusteru AKS a přidružených prostředků se nepodporuje.

Ne. Po odstranění clusteru nemůžete cluster obnovit. Když cluster odstraníte, odstraní se také skupina prostředků uzlu a všechny její prostředky.

Pokud chcete zachovat některý z vašich prostředků, před odstraněním clusteru je přesuňte do jiné skupiny prostředků. Pokud chcete chránit před náhodným odstraněním, můžete uzamknout spravovanou skupinu prostředků AKS, která je hostitelem prostředků clusteru, pomocí uzamčení skupiny prostředků Node.

Můžete úplně zastavit běžící cluster AKS nebo škálovat či autoskalovat všechny nebo konkrétní fondy uzlů na nulu.

Pooly systémových uzlů není možné přímo škálovat na nulu.

Ne. Operace škálování, které používají rozhraní API škálovací sady virtuálních počítačů, se nepodporují. Můžete použít rozhraní API AKS (az aks scale).

Ne. Operace škálování, které používají rozhraní API škálovací sady virtuálních počítačů, se nepodporují. Rozhraní API AKS můžete použít ke škálování uzlových fondů, které nejsou systémové, na nulu nebo k zastavení vašeho clusteru.

Ne. Tato konfigurace není podporovaná. Místo toho zastavte klastr .

AKS vychází z mnoha prostředků infrastruktury Azure, včetně škálovacích sad virtuálních počítačů, virtuálních sítí a spravovaných disků. Díky těmto integracím můžete použít řadu základních funkcí platformy Azure v rámci spravovaného prostředí Kubernetes, které poskytuje AKS. Můžete například použít většinu typů virtuálních počítačů Azure přímo s AKS a rezervace Azure můžete využít k automatickému získání slev na tyto prostředky.

Pokud chcete tuto architekturu povolit, každé nasazení AKS zahrnuje dvě skupiny prostředků:

1. Vytvoříte první skupinu prostředků. Tato skupina obsahuje pouze zdroj služby Kubernetes. Poskytovatel prostředků AKS během nasazování automaticky vytvoří druhou skupinu prostředků. Příkladem druhé skupiny prostředků je MC_myResourceGroup_myAKSCluster_eastus. Informace o tom, jak zadat název této druhé skupiny prostředků, najdete v další části.
2. Druhá skupina prostředků označovaná jako skupina prostředků uzlu obsahuje všechny prostředky infrastruktury přidružené ke clusteru. Mezi tyto prostředky patří virtuální počítače uzlů Kubernetes, virtuální sítě a úložiště. Ve výchozím nastavení má skupina prostředků uzlu název ve tvaru MC_myResourceGroup_myAKSCluster_eastus. AKS automaticky odstraní skupinu prostředků uzlu při každém odstranění clusteru. Tuto skupinu prostředků použijte pouze pro prostředky, které sdílejí životní cyklus clusteru.

Poznámka:

Úprava jakéhokoli prostředku ve skupině prostředků uzlu v clusteru AKS je nepodporovaná akce a způsobí selhání operací clusteru. Můžete zabránit změnám ve zdrojové skupině uzlů. Zablokujte uživatelům úpravu prostředků , které cluster AKS spravuje.

Ve výchozím nastavení AKS pojmenuje skupinu prostředků pro uzly MC_resourcegroupname_clustername_location, ale můžete zadat vlastní název.

Pokud chcete zadat vlastní název skupiny prostředků, nainstalujte rozšíření Azure CLI aks-preview ve verzi 0.3.2 nebo novější. Při vytváření clusteru AKS pomocí az aks create příkazu použijte --node-resource-group parametr a zadejte název skupiny prostředků. Pokud k nasazení clusteru AKS použijete šablonu Azure Resource Manager, můžete název skupiny prostředků definovat pomocí vlastnosti nodeResourceGroup.

• Poskytovatel prostředků Azure automaticky vytvoří sekundární skupinu prostředků.
• Název vlastní skupiny prostředků můžete zadat pouze při vytváření clusteru.

Při práci se skupinou prostředků uzlu nemůžete:

• Zadejte existující skupinu prostředků pro skupinu prostředků uzlu.
• Zadejte jiné předplatné pro skupinu prostředků uzlu.
• Po vytvoření clusteru změňte název skupiny prostředků uzlu.
• Zadejte názvy spravovaných prostředků ve skupině prostředků uzlu.
• Upravte nebo odstraňte Azure-vytvořené značky spravovaných prostředků v rámci skupiny prostředků uzlu.

Pokud upravíte nebo odstraníte značky vytvořené službou Azure a další vlastnosti prostředků ve skupině prostředků pro uzly, možná dojde k neočekávaným chybám při škálování a upgradu. AKS umožňuje vytvářet a upravovat vlastní značky vytvořené koncovými uživateli a tyto značky můžete přidat při vytváření fondu uzlů. Možná budete chtít vytvořit nebo upravit vlastní značky, například pro přiřazení obchodní jednotky nebo nákladového střediska. Další možností je použít zásady a upravit značky přímo prostřednictvím samotného prostředku AKS – konkrétně prostřednictvím clusteru a fondů uzlů.

Značky vytvořené Azure jsou určeny pro odpovídající služby Azure a měli byste je vždy akceptovat. Pro AKS jsou k dispozici značky aks-managed a k8s-azure. Úprava značek vytvořených Azure na prostředcích ve skupině prostředků uzlu v clusteru AKS je nepodporovaná akce, která přeruší SLO (cíle úrovně služeb).

Poznámka:

V minulosti byl název značky Owner vyhrazen pro AKS kvůli správě veřejné IP adresy, která je přiřazena na front-endovou IP adresu v rámci vyrovnávače zátěže. Služby teď používají předponu aks-managed . U starších prostředků nepoužívejte zásady Azure k použití názvu značky Owner. Pokud ne, všechny prostředky vašeho nasazení a operací aktualizace clusteru AKS se přeruší. Toto omezení se nevztahuje na nově vytvořené prostředky.

AKS používá Helm k doručování komponent do clusteru. Můžete bezpečně ignorovat verze Helm s předponou aks-managed. Průběžné zvyšování revizí těchto verzí Helmu je očekávané a bezpečné.

Úplný seznam dostupných oblastí najdete v tématu Oblasti a dostupnost AKS.

Ne. Clustery AKS jsou regionální prostředky a nemůžou zahrnovat oblasti. Pokyny k vytvoření architektury, která zahrnuje více oblastí, najdete v osvědčených postupech pro provozní kontinuitu a zotavení po havárii.

Ano, cluster AKS můžete nasadit napříč jednou nebo více zónami dostupnosti v oblastech, které je podporují.

Ano, v clusteru AKS můžete použít různé velikosti VM tím, že vytvoříte více uzlových fondů.

AKS nenastavuje omezení velikosti image kontejneru. Čím je ale obrázek větší, tím vyšší je poptávka po paměti. Větší velikost může potenciálně překročit limity prostředků nebo celkovou dostupnou paměť pracovních uzlů. Ve výchozím nastavení je paměť pro velikost virtuálního počítače Standard_DS2_v2 pro cluster AKS nastavená na 7 GiB.

Pokud je image kontejneru příliš velká, například v rozsahu terabajtu (TB), kubelet ji nemusí kvůli nedostatku místa na disku načíst z registru kontejneru do uzlu.

U uzlů Windows Server se služba Windows Update nespustí automaticky a použije nejnovější aktualizace. V clusteru AKS byste měli provést upgrade clusteru i fondů uzlů Windows Server. Postupujte podle běžného plánu na základě cyklu vydávání služba Windows Update a vlastního procesu ověřování. Tento proces upgradu vytvoří uzly, na kterých běží nejnovější Windows Server image a opravy, a potom odebere starší uzly. Další informace o tomto procesu najdete v tématu Upgrade fondu uzlů v AKS.

Následující obrazy mají funkční požadavky pro spuštění jako root a výjimky musí být podávány pro jakékoli zásady.

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Ano, existují dvě možnosti omezení přístupu k serveru rozhraní API:

• Pokud chcete zachovat veřejný koncový bod pro server rozhraní API, ale omezit přístup k sadě důvěryhodných rozsahů IP adres, použijte rozsahy IP autorizovaných serverů rozhraní API .
• Privátní cluster použijte, pokud chcete omezit, aby byl server rozhraní API přístupný jenom z vaší virtuální sítě.

AKS každý týden opravuje CVE, které mají opravu od dodavatele. CVE bez opravy čekají na opravu od dodavatele, než je lze vyřešit. Image AKS se automaticky aktualizují do 30 dnů. Doporučujeme použít aktualizovanou image uzlu v pravidelných intervalech, abyste měli jistotu, že se všechny nejnovější opravené image a opravy operačního systému použijí a budou aktuální. Tento úkol můžete provést:

• Ručně prostřednictvím portálu Azure nebo Azure CLI.
• Aktualizací vašeho clusteru AKS. Cluster upgraduje kabelon a vyprázdní uzly automaticky. Pak je online zprovozněn nový uzel s nejnovějším obrazem Ubuntu a opravenou verzí nebo menší verzí Kubernetes. Další informace najdete v tématu Upgrade clusteru AKS.
• Pomocí upgradu obrazu uzlu.

Microsoft poskytuje pokyny pro další akce, které můžete provést k zabezpečení úloh prostřednictvím služeb, jako je Microsoft Defender pro kontejnery. Informace o bezpečnostní hrozbě související s AKS a Kubernetes najdete v tématu Nové rozsáhlé kampaně cílí na Kubeflow (8. června 2021).

Ne. Všechna data jsou uložená v oblasti clusteru.

Tradičně platí, že pokud je pod spuštěný jako ne-root uživatel (což by měl být), musíte zadat parametr fsGroup v kontextu zabezpečení podu, aby byl svazek čitelný a zapisovatelný pro pod. Další informace o tomto požadavku najdete v tématu Konfigurace kontextu zabezpečení pro pod nebo kontejner.

Vedlejším účinkem nastavení fsGroup je, že při každém připojení svazku musí Kubernetes používat příkazy chown() a chmod() rekurzivně pro všechny soubory a adresáře uvnitř svazku (s několika výjimkami). K tomuto scénáři dochází i v případě, že vlastnictví skupiny svazku už odpovídá požadovanému fsGroup parametru. Tato konfigurace může být nákladná pro větší svazky s velkým množstvím malých souborů, což může způsobit, že spuštění podu trvá dlouhou dobu. Tento scénář byl známým problémem před v1.20. Řešením je nastavit pod tak, aby běžel jako uživatel root.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Problém se vyřešil s Kubernetes verze 1.20. Další informace najdete v tématu Kubernetes 1.20: Podrobné řízení změn oprávnění svazků.

AKS používá zabezpečený tunel pro komunikaci, aby umožnil komunikaci api-server a jednotlivých kubeletů uzlů, a to i v oddělených virtuálních sítích. Tunel je zabezpečený prostřednictvím vzájemného šifrování Transport Layer Security. Aktuální hlavní tunel, který AKS používá , je Konnectivity, dříve označovaný jako apiserver-network-proxy. Ověřte, že všechna pravidla sítě dodržují pravidla Azure požadovaná pravidla sítě a plně kvalifikované názvy domén (FQDN).

Ano, můžete přidat poznámku kubernetes.azure.com/set-kube-service-host-fqdn k podům a nastavit KUBERNETES_SERVICE_HOST proměnnou na název domény serveru ROZHRANÍ API místo IP adresy služby v clusteru. Tato úprava je užitečná v případech, kdy se výchozí přenos dat clusteru provádí přes bránu firewall vrstvy 7. Příkladem je použití Azure Firewall s pravidly aplikace.

AKS u své podsítě nepoužije skupiny zabezpečení sítě (NSG) a neupravuje žádné skupiny zabezpečení sítě přidružené k této podsíti. AKS upravuje pouze nastavení NSG síťového rozhraní. Pokud používáte rozhraní Container Network Interface (CNI), musíte také zajistit, aby pravidla zabezpečení ve skupinách zabezpečení sítě (NSGs) umožňovala provoz mezi rozsahy beztřídního mezidoménového směrování (CIDR) pro uzly a pody. Pokud používáte kubenet, musíte také zajistit, aby pravidla zabezpečení v NSG umožňovala provoz mezi uzlem a CIDR podu. Další informace najdete v tématu Skupiny zabezpečení sítě.

Uzly AKS spouští službu chrony, která synchronizuje čas z místního hostitele. Kontejnery, které běží na podech, získají čas z uzlů AKS. Aplikace, které se otevřou uvnitř kontejneru, používají čas z kontejneru podu.

Ne. AKS je spravovaná služba. Manipulace s prostředky infrastruktury jako služby (IaaS) se nepodporuje. K instalaci vlastních komponent použijte rozhraní API a mechanismy Kubernetes. Pomocí daemonSets můžete například nainstalovat všechny požadované součásti.

AKS podporuje následující kontrolery přístupu:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

V současné době nemůžete změnit seznam kontrolerů přístupu v AKS.

Ano, webhooky kontroleru přístupu můžete použít v AKS. Doporučujeme vyloučit interní obory názvů AKS, které jsou označené popiskem control-plane . Příklad:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS zajišťuje firewall pro odchozí provoz serveru API, takže vaše webhooky pro kontrolu přístupu musí být dostupné zevnitř clusteru.

Aby AKS chránila stabilitu systému a zabránila tomu, aby vlastní kontrolery pro přijetí ovlivnily interní služby v kube-system oboru názvů, má AKS vynucovač přístupu, který automaticky vylučuje kube-system a interní obory názvů AKS. Tato služba zajišťuje, že vlastní kontrolery přístupu nemají vliv na služby spuštěné v kube-system.

Pokud máte kritický případ použití pro nasazení něčeho na kube-system (nedoporučuje se) na podporu vašeho vlastního admission webhooku, můžete přidat následující popisek nebo poznámku, aby jej mechanismus povolení ignoroval.

• Označit: "admissions.enforcer/disabled": "true"
• Anotace: "admissions.enforcer/disabled": true

Poskytovatel Azure Key Vault pro ovladač Secrets Store CSI zajišťuje nativní integraci Azure Key Vault do AKS.

Uzly, které jsou povolené pomocí standardu FIPS (Federal Information Processing Standards), se teď podporují ve fondech uzlů založených na Linuxu. Další informace najdete v Přidejte fond uzlů podporující FIPS.

Všechny opravy, včetně opravy zabezpečení, se automaticky aplikují na cluster AKS. Pokud je k dispozici nová verze, při aktualizaci clusteru se aktualizuje cokoli většího než oprava, například hlavní nebo vedlejší verze (které mohou obsahovat zásadní změny nasazených objektů). Informace o tom, kdy je k dispozici nová verze, najdete v poznámky k verzi AKS.

Rozšíření AKS pro Linux je rozšíření Azure virtuálních počítačů, které instaluje a konfiguruje monitorovací nástroje na pracovní uzly Kubernetes. Rozšíření se nainstaluje na všechny nové a existující linuxové uzly. Konfiguruje následující monitorovací nástroje:

• Exportér uzlů: Shromažďuje hardwarovou telemetrii z virtuálního počítače a zpřístupňuje ji pomocí koncového bodu metrik. Pak může monitorovací nástroj, jako je Například Prometheus, tyto metriky ošrotovat.
• Detektor problémů uzlů: Cílem je zviditelnit různé problémy uzlů pro výše postavené vrstvy ve správě clusteru. Je to jednotka systemd, která běží na každém uzlu, detekuje problémy uzlů a hlásí je serveru rozhraní API clusteru pomocí Events a NodeConditions.
• ig: Je opensourcová architektura s technologií eBPF pro ladění a sledování systémů Linux a Kubernetes. Poskytuje sadu nástrojů (nebo miniaplikací), které shromažďují relevantní informace, které můžou uživatelé použít k identifikaci příčiny problémů s výkonem, chybových ukončení nebo jiných anomálií. Pozoruhodné je, že její nezávislost na Kubernetes umožňuje uživatelům používat ji také pro ladění problémů s řídicí rovinou.

Tyto nástroje pomáhají zajistit pozorovatelnost řady problémů souvisejících se stavem uzlu, například:

• Problémy s démonem infrastruktury: Služba NTP nefunguje
• Problémy s hardwarem: Chybný procesor, paměť nebo disk
• Problémy s jádrem: Zablokování jádra, poškozený systém souborů
• Problémy s kontejnerovým runtime: Nereagující démon runtime

Rozšíření nevyžaduje dodatečný odchozí přístup k žádným adresám URL, IP adresám ani portům nad rámec zdokumentovaných požadavků na výchozí přenos dat AKS. Nevyžaduje žádná zvláštní oprávnění udělená v Azure. Používá kubeconfig k připojení k serveru rozhraní API a odesílání shromážděných monitorovacích dat.

Většina clusterů se odstraní na žádost uživatele. V některých případech, zejména tam, kde přinášíte vlastní skupinu prostředků nebo provádíte úkoly napříč skupinami prostředků, může odstranění trvat déle, nebo dokonce selhat. Pokud máte problém s odstraněním, důkladně zkontrolujte, že nemáte zámky na skupině prostředků. Také se ujistěte, že všechny prostředky mimo skupinu prostředků se oddělují od skupiny prostředků.

Pokud máte problémy s vytvářením a aktualizací clusterů, ujistěte se, že nemáte přiřazené zásady ani omezení služeb, které by mohly vašemu clusteru AKS blokovat správu prostředků, jako jsou virtuální počítače, nástroje pro vyrovnávání zatížení nebo značky.

Můžete, ale nedoporučujeme to. Aktualizace proveďte, pokud je stav clusteru známý a v pořádku.

Ne. Před upgradem odstraňte nebo odeberte všechny uzly, které jsou ve stavu selhání nebo jinak, z clusteru.

K této chybě nejčastěji dochází v případě, že používáte jednu nebo více skupin zabezpečení sítě, které jsou stále přidružené ke clusteru. Odeberte je a zkuste cluster znovu odstranit.

Ověřte, že nevypršela platnost vašeho služebního principálu. Další informace najdete v tématu principál služby AKS a aktualizace přihlašovacích údajů AKS.

Ověřte, že nevypršela platnost služebního účtu. Další informace najdete v tématu hlavní služba AKS a aktualizace přihlašovacích údajů AKS.

Od 17. března 2027 Azure Kubernetes Service (AKS) už nepodporuje nebo poskytuje aktualizace zabezpečení Ubuntu 20.04. Odstraní se všechny existující image uzlů a nebudete moct škálovat žádné fondy uzlů se systémem Ubuntu 20.04. Přesuňte se na podporovanou verzi Ubuntu aktualizací poolů uzlů na Kubernetes verze 1.35+. Další informace o tomto vyřazení najdete v problému na GitHubu o vyřazení a v oznámení o vyřazení aktualizací Azure. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS.

Od 1. března 2026 už Azure Kubernetes Service (AKS) nepodporuje fondy uzlů Windows Server 2019. Fondy uzlů, na kterých běží Kubernetes verze 1.33 nebo novější, nemůžou používat Windows Server 2019. Od 1. dubna 2027 AKS odstraní všechny existující obrazy uzlů pro Windows Server 2019, což znamená, že operace škálování budou selhávat. Další informace o tomto vyřazení najdete v problému na GitHubu o vyřazení a v oznámení o vyřazení aktualizací Azure. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS. Od 15. března 2027 už Azure Kubernetes Service (AKS) nepodporuje fondy uzlů Windows Server 2022. Fondy uzlů, na kterých běží Kubernetes verze 1.36 nebo novější, nemůžou používat Windows Server 2022. Od 1. dubna 2028 AKS odstraní všechny existující obrazy uzlů pro Windows Server 2022, což znamená, že operace škálování selžou. Další informace o tomto vyřazení najdete v problému na GitHubu o vyřazení a v oznámení o vyřazení aktualizací Azure. Pokud chcete mít přehled o oznámeních a aktualizacích, sledujte poznámky k verzi AKS.