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

Článek
11/08/2023

Tento článek se zabývá častými dotazy týkajícími se služby Azure Kubernetes Service (AKS).

Které oblasti Azure 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 rozšířit cluster 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 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 server rozhraní API tak, aby byl přístupný jenom z vaší virtuální sítě.

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, které mají každý týden "opravu dodavatele". CvEs bez opravy čekají na "opravu dodavatele" před 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.

Jaký je limit velikosti image kontejneru v AKS?

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.

Uzly Windows Serveru

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.

Existují bezpečnostní hrozby zaměřené 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 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).

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

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.

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

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. 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ů:

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.
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. Tento cluster byste měli použít jenom 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. Změny ve skupině prostředků uzlu můžete zabránit tím, že uživatelům zabráníte v úpravách prostředků spravovaných clusterem AKS.

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

Ano. Ve výchozím nastavení 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 aks-Preview verze 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 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. 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ř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). Další informace najdete v tématu Nabízí AKS smlouvu o úrovni služeb?

Poznámka:

V minulosti byl název značky Vlastník vyhrazen pro AKS ke správě veřejné IP adresy přiřazené na front-endové IP adrese nástroje pro vyrovnávání zatížení. 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 Vlastník. Jinak se všechny prostředky v nasazení a aktualizaci clusteru AKS přeruší. To neplatí pro nově vytvořené prostředky.

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
Ověření ověřeníWebhooku
ResourceQuota
PodNodeSelector
PodTolerationRestriction
ExtendedResourceToleration

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

Můžu v 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. 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.

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

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

Je služba Azure Key Vault integrovaná s AKS?

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.

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 v cenové úrovni Standard pomocí funkce SLA pro dobu provozu.

Cenová úroveň Free nemá přidruženou smlouvu o úrovni služeb, ale má cíl úrovně služeb 99,5 %. K přechodným problémům s připojením dochází v případě, že dojde k upgradu, uzlům, které nejsou v pořádku, údržbě platformy, aplikace zahltí server rozhraní API požadavky atd. Pro klíčové a produkční úlohy nebo pokud vaše úloha netoleruje restartování serveru API, doporučujeme použít úroveň Standard, která zahrnuje smlouvu SLA o 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 zakoupili rezervace Azure pro velikost virtuálního počítače, kterou používáte v AKS, automaticky se použijí tyto slevy.

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 se v současné době nepodporuje.

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řesun 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ří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.

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

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ůžu po odstranění clusteru obnovit?

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. Příkladem druhé skupiny prostředků je MC_myResourceGroup_myAKSCluster_eastus.

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.

Co je podpora platformy a co zahrnuje?

Podpora platformy je plán omezené podpory pro nepodporované clustery verze N-3. Podpora platformy zahrnuje pouze podporu infrastruktury Azure. Podpora platformy neobsahuje nic souvisejícího s následujícími funkcemi:

Funkce a komponenty Kubernetes
Vytvoření fondu clusteru nebo uzlů
Opravy hotfix
Opravy chyb
Opravy zabezpečení
Vyřazené komponenty

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

AKS spoléhá na vydané verze a opravy z Kubernetes, což je opensourcový projekt, který podporuje pouze posuvné okno tří podverzí. AKS může zaručit plnou podporu pouze v době, kdy jsou tyto verze obsluhovány v upstreamu. Vzhledem k tomu, že se neprodukují žádné další opravy, může AKS nechat tyto verze nepatchované nebo fork. Kvůli tomuto omezení podpora platformy nepodporuje nic od spoléhání na upstream kubernetes.

Upgraduje AKS automaticky nepodporované clustery?

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. Automatické upgradování clusteru podporovaného platformou na podporovanou verzi je ve výchozím nastavení povolené.

Například Kubernetes verze 1.25 upgraduje na verzi v1.26 během verze ga verze 1.29. Pokud chcete minimalizovat přerušení, nastavte časové intervaly údržby. Podrobnosti o kanálech automatického upgradu najdete v tématu automatického upgradu .

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

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

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 ve stavu selhání nebo jinak z clusteru.

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

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.

Spustil(a) jsem upgrade, ale teď jsou pody ve smyčce chybových ukončení a testy připravenosti selžou?

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

Cluster fungoval, ale najednou nejde zřídit loadbalancery, připojit pvcs atd.?

Ověřte, že nevyprš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 úplně 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 také můžete rozhodnout škálovat nebo automaticky škálovat všechny nebo konkrétní User fondy uzlů na 0 a zachovat pouze potřebnou konfiguraci clusteru.

Fondy systémových uzlů nemůžete 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í pomocí rozhraní API škálovací sady virtuálních počítačů se nepodporují. Použijte rozhraní API AKS (az aks scale).

Můžu pomocí škálovacích sad virtuálních počítačů ručně škálovat na nula 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 nula nesystémových fondů uzlů nebo místo toho cluster zastavit .

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

I když má AKS mechanismy odolnosti, které odolují takové konfiguraci a obnovují 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 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.

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

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

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

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

Co je transparentní režim Azure CNI vs. režim přemísťování?

Počínaje verzí 1.2.0 azure CNI nastaví transparentní režim jako výchozí pro nasazení jednoklientské linuxové CNI. Transparentní režim nahrazuje režim mostu. V následujících částech režimu přemostění a transparentního režimu probereme další informace o rozdílech mezi oběma režimy a výhodami a omezeními transparentního režimu v Azure CNI.

Režim mostu

Režim mostu Azure CNI vytvoří most L2 s názvem "azure0" způsobem "just in time". Všechna rozhraní páru podů veth na straně hostitele jsou připojena k tomuto mostu. Komunikace pod-Pod uvnitř virtuálního počítače a zbývající provoz procházejí tímto mostem. Most je virtuální zařízení vrstvy 2, které samostatně nemůže přijímat ani přenášet nic, pokud k němu 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, který v rámci virtuálního počítače s Linuxem vytvoří složitou síťovou topologii. Jako příznak musel CNI zpracovávat další síťové funkce, jako jsou aktualizace serveru DNS.

Bridge mode topology

Následující příklad ukazuje, jak nastavení trasy IP vypadá v režimu mostu. Bez ohledu na to, kolik podů uzel má, existují pouze dvě trasy. První trasa říká, že provoz (s výjimkou místního prostředí v Azure0) přejde do výchozí brány podsítě prostřednictvím rozhraní src 10.240.0.4, což je primární IP adresa uzlu. Druhý z nich ří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 používá jednoduchý 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 přístup ke změně vlastností sítě s Linuxem pomáhá snížit složité problémy s případnými případy, se kterými se clustery můžou setkat s režimem Přemostit. 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 je prostřednictvím ip tras, které přidal CNI. Komunikace typu Pod-to-Pod je v podstatě přes pravidla směrování vrstvy 3 a L3 směrovací provoz podů.

Transparent mode topology

Následující příklad ukazuje nastavení trasy IP transparentního režimu. Každé rozhraní podu získá připojenou statickou trasu, takže provoz s IP adresou dest, protože pod se odesílá přímo do rozhraní páru na straně veth hostitele 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 zmírnění stavu conntrack paralelního časování DNS a zabránění problémům s latencí 5 sekund DNS bez nutnosti nastavit místní DNS uzlu (kvůli 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 přemostitku je, že Azure CNI nemůže dál aktualizovat vlastní server DNS seznam uživatelů přidávaných do virtuální sítě nebo síťové karty. Výsledkem tohoto scénáře je, že CNI vyzvedne pouze první instanci seznamu serverů DNS. Tento problém je vyřešen v transparentním režimu, protože CNI nemění žádné vlastnosti eth0. Další informace najdete tady.
Poskytuje lepší zpracování provozu UDP a omezení rizik pro povodňové bouře UDP v případě vypršení časového limitu protokolu ARP. Pokud most v režimu přemostice nezná adresu MAC cílového podu při komunikaci mezi pody virtuálního počítače, má záměrně za následek bouři paketu na všechny porty. Tento problém je vyřešený v transparentním režimu, protože v cestě nejsou žádná zařízení L2. Další informace najdete tady.
Transparentní režim funguje lépe při komunikaci mezi pody virtuálního počítače z hlediska propustnosti a latence v porovnání s režimem přemostění.

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

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ý v tomto článku.

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.

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

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.

Můžu nakonfigurovat skupiny zabezpečení sítě s využitím 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í 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ě.

Jak funguje synchronizace času v AKS?

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.

Jak se aktualizují doplňky AKS?

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.

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

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