Nejčastější dotazy k AKS

AKS poskytuje záruky sla v cenové úrovni Standard pomocí funkce SLA pro dobu provozu.

Podpora platformy je plán omezené podpory pro nepodporované clustery verze N-3. 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 GA) 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.

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

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, automaticky se použijí tyto slevy.

Ne, přesun clusteru AKS mezi tenanty se v současné době nepodporuje.

Ne, přesun clusteru AKS mezi předplatnými 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 ho nemůžete 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 hostující prostředky clusteru pomocí uzamčení skupiny prostředků Node.

Můžete úplně zastavit spuštěný cluster AKS nebo škálovat nebo automaticky škálovat všechny nebo konkrétní User fondy uzlů na nulu.

Fondy systémových uzlů nemůžete přímo škálovat na nulu.

Ne, operace škálování pomocí 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í pomocí rozhraní API škálovací sady virtuálních počítačů se nepodporují. Rozhraní API AKS můžete použít k škálování fondů nesystémových uzlů na nulu nebo zastavení clusteru .

Ne, nejedná se o podporovanou konfiguraci. Místo toho zastavte cluster .

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. Například většinu typů virtuálních počítačů Azure je možné použít přímo s AKS a rezervaceMi Azure, které můžou automaticky získávat slevy 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 prostředek 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, jako je MC_myResourceGroup_myAKSCluster_eastus. AKS automaticky odstraní skupinu prostředků uzlu při každém odstranění clusteru. Tuto skupinu prostředků byste měli použít jenom pro prostředky, které sdílejí životní cyklus clusteru.

Ve výchozím nastavení AKS pojmenuje skupinu prostředků uzlu 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 verze 0.3.2 nebo novější. Při vytváření clusteru AKS pomocí příkazu [az aks create][az-aks-create] použijte --node-resource-group parametr a zadejte název skupiny prostředků. Pokud k nasazení clusteru AKS použijete šablonu Azure Resource Manageru, 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 mějte na paměti, že 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 značky spravovaných prostředků vytvořené v Azure ve skupině prostředků uzlu.

Pokud upravíte nebo odstraníte značky vytvořené v Azure a další vlastnosti prostředku ve skupině prostředků uzlu, může dojít k neočekávaným chybám š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ů. Můžete chtít vytvořit nebo upravit vlastní značky, například přiřadit obchodní jednotku nebo nákladové středisko. Další možností je vytvořit zásady Azure s oborem pro spravovanou skupinu prostředků.

Značky vytvořené v Azure se vytvářejí pro příslušné služby Azure a měly by být vždy povolené. Pro AKS jsou k dispozici značky aks-managed a k8s-azure značky. Úprava všech značek vytvořených v Azure u prostředků ve skupině prostředků uzlu v clusteru AKS je nepodporovaná akce, která přeruší cíl na úrovni služby (SLO).

Ú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 virtuálních počítačů vytvořením více fondů uzlů.

AKS nenastavuje omezení velikosti image kontejneru. Je ale důležité pochopit, že čím větší je image, 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 Terabyte (TBS), kubelet ji nemusí kvůli nedostatku místa na disku načíst z registru kontejneru do uzlu.

U uzlů Windows Serveru se služba Windows Update nespustí automaticky a nainstaluje nejnovější aktualizace. V pravidelných plánech kolem cyklu vydávání verzí služba Windows Update a vlastního procesu ověřování byste měli provést upgrade v clusteru a fondech uzlů Windows Serveru v clusteru AKS. Tento proces upgradu vytvoří uzly, na kterých běží nejnovější image a opravy Windows Serveru, a pak odebere starší uzly. Další informace o tomto procesu najdete v tématu Upgrade fondu uzlů v AKS.

Následující image mají funkční požadavky na "Spustit jako kořenový" a výjimky musí být zařadovány pro všechny 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 server rozhraní API tak, aby byl přístupný jenom z vaší virtuální sítě.

Opravy AKS, které mají každý týden "opravu dodavatele". CvEs bez opravy čekají na "opravu dodavatele" před jejich nápravou. Image AKS se automaticky aktualizují během 30 dnů. Doporučujeme použít aktualizovanou image uzlu v pravidelných intervalech, abyste měli jistotu, že se všechny nejnovější opravy oprav a opravy operačního systému použijí a budou aktuální. Můžete to provést pomocí jedné z následujících metod:

• Ručně prostřednictvím webu Azure Portal nebo Azure CLI.
• Upgradem clusteru AKS Cluster upgraduje uzly cordon a vyprázdnění automaticky a pak přenese nový uzel do režimu online s nejnovější imagí Ubuntu a novou verzí opravy nebo podverzní verzí Kubernetes. Další informace najdete v tématu Upgrade clusteru AKS.
• Pomocí upgradu image 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 for Containers. Následující bezpečnostní hrozba souvisí s AKS a Kubernetes, o které byste měli vědět:

• Nové rozsáhlé kampaně cílí na Kubeflow (8. června 2021).

Ne, všechna data se ukládají v oblasti clusteru.

Tradičně platí, že pokud pod běží jako uživatel, který není v kořenovém adresáři (který byste měli), musíte zadat fsGroup vnitřní kontext zabezpečení podu, aby byl svazek čitelný a zapisovatelný podem. Tento požadavek je podrobněji popsaný tady.

Vedlejším účinkem nastavení fsGroup je, že při každém připojení svazku musí Kubernetes rekurzivně chown() a chmod() všechny soubory a adresáře uvnitř svazku (s několika výjimkami uvedenými níže). K tomuto scénáři dochází i v případě, že vlastnictví skupiny svazku již odpovídá požadovanému fsGroup. U větších svazků s velkým množstvím malých souborů může být nákladné, 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 a alternativním řešením je nastavit pod spustit jako kořen:

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

Tento problém je vyřešený v Kubernetes verze 1.20. Další informace najdete v tématu Kubernetes 1.20: Podrobné řízení změn oprávnění svazku.

AKS používá zabezpečenou komunikaci tunelu, která umožňuje komunikaci mezi api-serverem a jednotlivými uzly kubelety i v samostatných virtuálních sítích. Tunel je zabezpečený prostřednictvím šifrování mTLS. Aktuální hlavní tunel používaný službou AKS je Konnectivity, dříve označovaný jako apiserver-network-proxy. Ověřte, že všechna pravidla sítě dodržují požadovaná pravidla sítě a plně kvalifikované názvy domén Azure.

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. To je užitečné v případech, kdy se výchozí přenos dat clusteru provádí přes bránu firewall vrstvy 7, například při použití služby Azure Firewall s pravidly aplikací.

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í skupin zabezpečení sítě v síťových rozhraních. Pokud používáte CNI, musíte také zajistit, aby pravidla zabezpečení v NSG umožňovala provoz mezi rozsahy CIDR uzlu a podu. 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á načítá čas z místního hostitele. Kontejnery běžící na podech získají čas z uzlů AKS. Aplikace spuštěné uvnitř kontejneru používají čas z kontejneru podu.

Ne, AKS je spravovaná služba a manipulace s prostředky IaaS není podporována. K instalaci vlastních komponent použijte rozhraní API a mechanismy Kubernetes. K instalaci požadovaných komponent použijte například daemonSets.

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

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• Ověření ověřeníWebhooku
• 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 řídicí roviny . Příklad:

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

AKS firewalluje výchozí přenos dat serveru rozhraní API, takže webhooky kontroleru přístupu musí být přístupné z clusteru.

Kvůli ochraně stability systému a zabránění kontroleru vlastních přístupů v ovlivnění interních služeb v systému kube-system má AKS obor názvů Vynucení přístupu, který automaticky vylučuje kube-systém 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) v podpoře vašeho vlastního webhooku přístupu, můžete přidat následující popisek nebo poznámku, aby ho nástroj Accesss Enforcer ignoroval.

Popisek: "admissions.enforcer/disabled": "true" nebo poznámka: "admissions.enforcer/disabled": true

Zprostředkovatel služby Azure Key Vault pro ovladač CSI úložiště tajných kódů poskytuje nativní integraci služby Azure Key Vault do AKS.

Uzly s podporou FIPS se teď podporují ve fondech uzlů založených na Linuxu. Další informace najdete v tématu Přidání fondu uzlů s podporou FIPS.

Všechny opravy, včetně opravy zabezpečení, se automaticky aplikují na cluster AKS. Při aktualizaci clusteru, pokud je k dispozici nová verze, se aktualizuje cokoli, co je větší než oprava, například změny hlavní verze nebo podverze (které můžou mít zásadní změny nasazených objektů). Informace o dostupnosti nové verze najdete v poznámkách k verzi AKS.

Rozšíření AKS pro Linux je rozšíření virtuálního počítače Azure, 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 monitorovací nástroj, jako je Například Prometheus, dokáže tyto metriky ošrotovat.
• Detektor problémů uzlu: Cílem je zviditelnit různé problémy uzlů v nadřazených vrstvách v zásobníku pro správu clusteru. Je to systémová jednotka, která běží na jednotlivých uzlech, detekuje problémy s uzly a hlásí je serveru rozhraní API clusteru pomocí událostí a nodeConditions.
• ig: Opensourcová architektura s technologií eBPF pro ladění a sledování systémů Linux a Kubernetes. Poskytuje sadu nástrojů (nebo miniaplikací) určených ke shromažďování relevantních informací, což uživatelům umožňuje identifikovat příčinu problémů s výkonem, chybových ukončení nebo jiných anomálií. Zejména její nezávislost na Kubernetes umožňuje uživatelům používat ji také pro ladění problémů s rovinou řízení.

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

• Problémy s procesem démon 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 modulem runtime kontejneru: Nereagující proces démon modulu runtime

Rozšíření nevyžaduje další 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 pro připojení k serveru rozhraní API k odesílání shromážděných dat monitorování.

Většina clusterů se odstraní na žádost uživatele. V některých případech, zejména v případech, kdy přineste vlastní skupinu prostředků nebo provádíte úlohy napříč skupinami prostředků, může odstranění trvat déle nebo dokonce selhat. Pokud máte problém s odstraněním, pečlivě zkontrolujte, že ve skupině prostředků nemáte zámky, že všechny prostředky mimo RG se oddělí od skupiny prostředků a tak dále.

Pokud máte problémy s operacemi vytváření a aktualizace clusteru, ujistěte se, že nemáte přiřazené zásady nebo 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í, značky atd.

Můžete, ale nedoporučujeme to. Pokud je stav clusteru známý a v pořádku, měli byste provést aktualizace.

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

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

Ověřte, že nevypršela platnost instančního objektu. Viz přihlašovací údaje instančního objektu AKS a aktualizace AKS.

Ověřte, že nevypršela platnost instančního objektu. Viz přihlašovací údaje instančního objektu AKS a aktualizace AKS.