Nejčastější dotazy ohledně služby Azure Kubernetes Service (AKS)

Tento článek se zabývá nejčastějšími dotazy týkajícími se Azure Kubernetes Service (AKS).

Které oblasti Azure v současné době poskytují AKS?

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

Můžu rozšířit cluster AKS napříč oblastmi?

No. Clustery AKS jsou regionální prostředky a nemůžou přesahovat 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 cluster AKS rozprostřít mezi zóny dostupnosti?

Ano. Cluster AKS můžete nasadit do jedné nebo více zón dostupnosti v oblastech, které je podporují.

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

Ano. Existují dvě možnosti omezení přístupu k serveru API:

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

Používají se aktualizace zabezpečení na uzly agenta AKS?

Opravy AKS CVE, které mají každý týden "opravu dodavatele". CVE bez opravy čeká na opravu dodavatele, než ji lze napravit. Image AKS se automaticky aktualizují během 30 dnů a doporučuje, aby zákazník použil aktualizovanou image uzlu v pravidelných intervalech, aby se zajistilo, že jsou všechny nejnovější opravy oprav a opravy operačního systému použity a aktuální:

Jaký je limit velikosti image kontejneru v AKS?

AKS nenastavuje omezení velikosti image kontejneru. Je však důležité pochopit, že čím větší je image, tím vyšší je poptávka po paměti. To 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á, protože v oblasti Terabyte (TBs) nemusí být kubelet schopná ji z registru kontejneru načíst do uzlu kvůli nedostatku místa na disku.

Uzly Windows Serveru

U uzlů Windows Serveru se služba Windows Update nespustí automaticky a použije nejnovější aktualizace. V pravidelných plánech kolem cyklu vydání služba Windows Update a vlastního procesu ověřování byste měli provést upgrade clusteru a fondů 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.

Cílí na AKS bezpečnostní hrozby, o které by měli zákazníci 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 for Containers. Následující bezpečnostní hrozba souvisí s AKS a Kubernetes, o které by měli zákazníci vědět:

Jak spravovaná řídicí rovina komunikuje s mými uzly?

AKS používá zabezpečenou tunelovou komunikaci, která umožňuje komunikaci rozhraní API-server a jednotlivých uzlů i v samostatných virtuálních sítích. Tunel je zabezpečený prostřednictvím šifrování TLS. Aktuální hlavní tunel, který používá AKS , je Konnectivity, dříve označovaný jako apiserver-network-proxy. Ověřte, že všechna síťová pravidla dodržují požadovaná síťová pravidla a plně kvalifikované názvy domén Azure.

Proč jsou v AKS vytvořeny 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 tomu můžete v rámci spravovaného prostředí Kubernetes poskytovaného AKS použít řadu základních funkcí platformy Azure. Například většina typů virtuálních počítačů Azure se dá použít přímo s AKS a rezervacemi Azure, které můžou automaticky přijímat 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, takže by se měla používat jenom pro prostředky, které sdílejí životní cyklus clusteru.

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

Ano. Ve výchozím nastavení služba AKS pojmenuje skupinu prostředků uzlu MC_resourcegroupname_clustername_location, ale můžete také zadat vlastní název.

Pokud chcete zadat vlastní název skupiny prostředků, nainstalujte rozšíření Azure CLI verze 0.3.2 nebo novější verze aks-preview. Při vytváření clusteru AKS pomocí příkazu 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 Manager, můžete název skupiny prostředků definovat pomocí vlastnosti nodeResourceGroup.

  • Sekundární skupina prostředků se automaticky vytvoří poskytovatelem prostředků Azure ve vašem vlastním předplatném.
  • Název vlastní skupiny prostředků můžete zadat jenom 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é skupiny prostředků uzlu.
  • Po vytvoření clusteru změňte název skupiny prostředků uzlu.
  • Zadejte názvy spravovaných prostředků v rámci skupiny prostředků uzlu.
  • Upravte nebo odstraňte značky spravovaných prostředků Azure ve skupině prostředků uzlu. (Další informace najdete v další části.)

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

Pokud upravíte nebo odstraníte značky vytvořené v Azure a další vlastnosti prostředků ve skupině prostředků uzlu, můžete získat neočekávané výsledky, jako je škálování a upgrade chyb. 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. Toho lze dosáhnout také vytvořením zásad Azure s oborem ve spravované skupině prostředků.

Úprava značek vytvořených v Azure u prostředků ve skupině prostředků uzlu v clusteru AKS je však nepodporovaná akce, která narušuje cíl na úrovni služby (SLO). Další informace najdete v tématu Nabízí AKS smlouvu o úrovni služeb?

Jaké kontrolery přístupu Kubernetes podporuje AKS? Je možné přidat nebo odebrat kontrolery přístupu?

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

  • Obor názvůLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultStorageClass
  • DefaultTolerationSeconds
  • MutatingAdmissionWebhook
  • Ověření ověřováníWebhooku
  • ResourceQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • ExtendedResourceToleration

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

Můžu ve službě AKS používat webhooky kontroleru přístupu?

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. Například přidáním následujícího příkazu do konfigurace webhooku:

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

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

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

Aby bylo možné chránit stabilitu systému a zabránit tomu, aby vlastní kontrolery přístupu ovlivnily interní služby v systému kube-system, má AKS vynucování 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-systemu.

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

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

Je Azure Key Vault integrovaná s AKS?

Zprostředkovatel azure Key Vault pro ovladač CSI služby Secrets Store poskytuje nativní integraci Azure Key Vault do AKS.

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

Ano, kontejnery Windows Serveru jsou k dispozici v AKS. Pokud chcete spustit kontejnery Windows Serveru v AKS, vytvoříte fond uzlů, na kterém běží Windows Server jako hostovaný operační systém. Kontejnery Windows Serveru můžou používat jenom Windows Server 2019. Pokud chcete začít, přečtěte si téma Vytvoření clusteru AKS s fondem uzlů Windows Serveru.

Podpora Windows Serveru pro fond uzlů zahrnuje určitá omezení, která jsou součástí nadřazeného Windows Serveru v projektu Kubernetes. Další informace o těchto omezeních najdete v tématu Kontejnery Windows Serveru v omezeních AKS.

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

AKS poskytuje záruky SLA jako volitelnou funkci se smlouvou SLA o provozu.

Bezplatná skladová položka nabízená ve výchozím nastavení nemá přidruženou smlouvu o úrovni služeb, ale má cíl úrovně služeb 99,5 %. Přechodné problémy s připojením jsou pozorovány v případě, že došlo k upgradu, nedodržovaným uzlům, údržbě platformy nebo aplikaci zahltí server API požadavky atd. Pokud vaše úloha netoleruje restartování api Serveru, doporučujeme použít smlouvu SLA o době provozu.

Můžu uplatnit slevy za rezervace Azure na uzly agenta AKS?

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

Můžu přesunout nebo migrovat cluster mezi tenanty Azure?

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

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

Přesun clusterů mezi předplatnými je momentálně nepodporovaný.

Můžu přesunout clustery AKS z aktuálního předplatného Azure do jiného?

Přesun clusteru AKS a přidružených prostředků mezi předplatnými Azure se nepodporuje.

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

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

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 v případě, že zákazníci přinesou vlastní skupinu prostředků nebo provádějí odstranění úloh napříč skupinami prostředků, může trvat déle nebo selžou. Pokud máte problém s odstraněním, pečlivě zkontrolujte, že nemáte zámky v RG, že se všechny prostředky mimo RG oddělují od skupiny RG atd.

Pokud mám pody nebo nasazení ve stavu NodeLost nebo Neznámý, můžu cluster stále upgradovat?

Můžete, ale AKS to nedoporučuje. Upgrady by se měly provést, když 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 vypnem, můžu provést upgrade?

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

Spustil(a) jsem odstranění clusteru, ale zobrazí se chyba [Errno 11001] getaddrinfo failed

Nejčastěji je to způsobeno tím, že uživatelé, kteří mají jednu nebo více skupin zabezpečení sítě (NSG), stále používají a přidruží ke clusteru. Odeberte je a zkuste odstranění znovu.

Spustil(a) jsem upgrade, ale teď jsou pody ve smyčce chyb a testy připravenosti selžou?

Ověřte, že vypršela platnost instančního objektu. Viz: Instanční objekt AKS a přihlašovací údaje pro aktualizaci AKS

Můj cluster fungoval, ale najednou nejde zřídit LoadBalancers, připojit pvcs atd.?

Ověřte, že vypršela platnost instančního objektu. Viz: Instanční objekt AKS a přihlašovací údaje pro aktualizaci AKS

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

Můžete zcela zastavit spuštěný cluster AKS a ušetřit tak příslušné náklady na výpočetní prostředky. Kromě toho se můžete také rozhodnout škálovat nebo automaticky škálovat všechny nebo konkrétní User fondy uzlů na 0 a udržovat pouze potřebnou konfiguraci clusteru. Fondy systémových uzlů nemůžete škálovat přímo 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í pomocí rozhraní API škálovací sady virtuálních počítačů se nepodporují. Použijte 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 nuly uzlů?

Ne, operace škálování pomocí rozhraní API škálovací sady virtuálních počítačů se nepodporují. Pomocí rozhraní API AKS můžete škálovat na nulové fondy uzlů jiného systému nebo místo toho zastavit cluster .

Můžu zastavit nebo zrušit přidělení všech virtuálních počítačů?

I když má AKS mechanismy odolnosti, aby vydržely takovou konfiguraci a obnovily se z ní, nejedná se o podporovanou konfiguraci. Místo toho zastavte cluster .

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

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

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

Funkce umožňující ukládání zákaznických dat v jedné oblasti je aktuálně dostupná pouze v oblasti Jihovýchodní Asie (Singapur) oblasti Asie Tichomoří a Brazílie –jih (Sao Paulo State) v oblasti Brazílie Geo. Pro všechny ostatní oblasti se zákaznická data ukládají do geografické oblasti.

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

Následující image mají funkční požadavky na "Spustit jako kořenový" a výjimky musí být zařaová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

Co je transparentní režim Azure CNI a režim mostu?

Počínaje verzí 1.2.0 azure CNI nastaví transparentní režim jako výchozí pro nasazení jednoklientského linuxového CNI. Transparentní režim nahrazuje režim mostu. V této části probereme další informace o rozdílech v obou režimech a o tom, jaké jsou výhody/omezení použití transparentního režimu v Azure CNI.

Režim mostu

Jak název naznačuje, režim mostu Azure CNI v "just in time" fashion, vytvoří most L2 s názvem "azure0". Všechna rozhraní páru podů veth na straně hostitele budou připojena k tomuto mostu. Takže Pod-Pod komunikaci v rámci virtuálního počítače a zbývající provoz prochází tímto mostem. Příslušný most je virtuální zařízení vrstvy 2, které samostatně nemůže přijímat ani přenášet cokoli, pokud s ním nevážete jedno nebo více skutečných zařízení. Z tohoto důvodu se musí eth0 virtuálního počítače s Linuxem převést na podřízený most azure0. Tím se v rámci virtuálního počítače s Linuxem vytvoří složitá síťová topologie a jako příznak CNI se musely postarat o další síťové funkce, jako je aktualizace serveru DNS atd.

Topologie režimu mostu

Níže je příklad toho, jak nastavení trasy ip vypadá v režimu mostu. Bez ohledu na to, kolik podů uzel má, budou existovat pouze dvě trasy. První z nich říká, že veškerý provoz mimo místní provoz v Azure0 přejde do výchozí brány podsítě prostřednictvím rozhraní s ip "src 10.240.0.4" (což je primární IP adresa uzlu) a druhý říká "10.20.x.x" prostor podu jádru, aby se rozhodlo jádro.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Transparentní režim

Transparentní režim přebírá přímý přístup k nastavení sítí s Linuxem. V tomto režimu Azure CNI nezmění žádné vlastnosti rozhraní eth0 na virtuálním počítači s Linuxem. Tento minimální přístup ke změně vlastností sítě Linuxu pomáhá snížit složité problémy s případy, se kterými se clustery můžou setkat s režimem Bridge. V transparentním režimu azure CNI vytvoří a přidá rozhraní páru podů veth na straně hostitele, která se přidají do hostitelské sítě. Komunikace pod-pod-pod virtuálního počítače probíhá prostřednictvím ip tras, které bude CNI přidávat. Komunikace pod-pod je v podstatě přes vrstvu 3 a provoz podů je směrován pravidly směrování L3.

Topologie transparentního režimu

Níže je příklad nastavení tras ip adres transparentního režimu, každé rozhraní podu získá statickou trasu připojenou tak, aby provoz s IP adresou dest, protože pod bude odeslán přímo do rozhraní páru hostitele veth podu.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Výhody transparentního režimu

  • Poskytuje omezení rizik pro conntrack paralelní stav rasy DNS a zabránění problémům s latencí 5 sekund DNS bez nutnosti nastavit místní DNS uzlu (z důvodů výkonu můžete stále používat místní DNS uzlu).
  • Eliminuje počáteční 5sekundový režim mostu CNI latence DNS kvůli nastavení mostu "just in time".
  • Jedním z rohových případů v režimu mostu je to, že Azure CNI nemůže aktualizovat vlastní server DNS seznam uživatelů přidávaných do virtuální sítě nebo síťové karty. Výsledkem je vyzvednutí pouze první instance seznamu serverů DNS. Vyřešeno v transparentním režimu, protože CNI nemění žádné vlastnosti eth0. Další informace najdete tady.
  • Poskytuje lepší zpracování provozu UDP a zmírnění rizik pro povodňové bouře UDP při vypršení časového limitu protokolu ARP. V režimu mostu, když most nezná adresu MAC cílového podu v komunikaci pod-pod-pod virtuálního počítače podle návrhu, výsledkem je storm paketu na všechny porty. Vyřešeno v transparentním režimu, protože v cestě nejsou žádná zařízení L2. Další informace najdete tady.
  • Transparentní režim funguje lépe v komunikaci pod-pod-pod v rámci virtuálního počítače z hlediska propustnosti a latence v porovnání s režimem mostu.

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

Tradičně pokud pod běží jako uživatel bez kořenového adresáře (který byste měli), musíte zadat fsGroup vnitřní kontext zabezpečení podu, aby mohl být svazek čitelný a zapisovatelný podem. Tento požadavek najdete podrobněji v tomto článku.

Ale jedním 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, které jsou uvedené níže. K tomu dochází i v případě, že vlastnictví skupiny svazku již odpovídá požadovanému fsGroupsvazku a může být nákladné pro větší svazky s velkým množstvím malých souborů, což způsobí, že spuštění podu trvá dlouhou dobu. Tento scénář byl známým problémem před verze 1.20 a alternativním řešením je nastavení spuštění podu jako kořenového adresáře:

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

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

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

Uzly s podporou FIPS jsou nyní podporovány ve fondech uzlů založených na Linuxu. Další informace najdete v tématu Přidání fondu uzlů s podporou FIPS.

Můžu nakonfigurovat skupiny zabezpečení sítě s AKS?

AKS nevztahuje skupiny zabezpečení sítě (NSG) na jeho podsíť a neupravuje žádnou skupinu zabezpečení sítě přidruženou k této podsíti. AKS upraví nastavení skupin zabezpečení sítě pouze v síťových rozhraních. Pokud používáte CNI, musíte také zajistit, aby pravidla zabezpečení v skupinách zabezpečení sítě umožňovala provoz mezi uzlem a rozsahy CIDR podů. Pokud používáte kubenet, musíte také zajistit, aby pravidla zabezpečení v skupinách zabezpečení sítě 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á načítá čas z místního hostitele, což zase synchronizuje čas s ntp.ubuntu.com. Kontejnery spuštěné na podech získají čas z uzlů AKS. Aplikace spouštěné v kontejneru používají čas od kontejneru podu.