Základní architektura pro cluster Azure Kubernetes Service (AKS)

Tento článek obsahuje doporučenou základní architekturu infrastruktury pro nasazení clusteru Azure Kubernetes Service (AKS). Využívá naše principy návrhu a je založen na osvědčených postupech architektury AKS z architektury Azure Well-Architected Framework. Tento článek vám pomůže při nasazení této obecné infrastruktury provést několik různých in interně jednotlivými skupinami, jako jsou sítě, zabezpečení a týmy identit.

Tato architektura se nezaměřuje na úlohu. Zaměřuje se na samotný cluster AKS. Tyto informace jsou minimálním doporučeným standardním plánem pro většinu clusterů AKS. Integruje se se službami Azure, které poskytují pozorovatelnost, poskytují topologii sítě, která podporuje víceregionální růst a zabezpečený provoz v clusteru.

Vaše obchodní požadavky ovlivňují cílovou architekturu a můžou se lišit mezi různými kontexty aplikace. Zvažte architekturu jako výchozí bod pro předprodukční a produkční fáze.

Kubernetes je výkonný ekosystém, který se rozšiřuje nad rámec technologií Azure a Microsoftu. Při nasazování clusteru AKS zodpovídáte za řadu rozhodnutí o tom, jak by se měl cluster navrhovat a provozovat. Spuštění clusteru AKS zahrnuje kombinaci uzavřených zdrojových komponent od různých dodavatelů, včetně Microsoftu; a opensourcové komponenty z ekosystému Kubernetes. Krajina se často mění a možná budete muset pravidelně znovu rozhodovat. Přijetím Kubernetes potvrzujete, že vaše úlohy potřebují své schopnosti a že tým úloh je připravený investovat průběžně.

Na GitHubu můžete použít implementaci této architektury : referenční implementace standardních hodnot AKS. Použijte ji jako alternativní výchozí bod a nakonfigurujte referenční architekturu na základě vašich potřeb.

Konfigurace sítě

Síťová topologie
Plánování IP adres
Nasazení prostředků příchozího přenosu dat

Výpočetní prostředky clusteru

Výpočty pro základní cluster
Referenční informace k imagím kontejneru
Správa zásad

Správa identit

Integrace ID Microsoft Entra pro cluster
Integrace ID Microsoft Entra pro úlohu

Zabezpečený tok dat

Zabezpečení toku sítě
Přidání správy tajných kódů

Kontinuita podnikových procesů

Škálovatelnost
Dostupnost clusteru a uzlu
Dostupnost a podpora více oblastí

Operace

Kanály CI/CD clusteru a úloh
Stav clusteru a metriky
Správa nákladů a generování sestav

Topologie sítě

Tato architektura používá hvězdicovou síťovou topologii. Nasaďte hvězdicové paprsky v samostatných virtuálních sítích, které jsou připojené prostřednictvím partnerského vztahu virtuálních sítí. Tato topologie má několik výhod. Tuto topologii použijte k:

• Povolte oddělenou správu. Zásady správného řízení můžete použít a dodržovat zásadu nejnižších oprávnění. Podporuje také koncept cílové zóny Azure s oddělením povinností.

• Minimalizujte přímé vystavení prostředků Azure veřejnému internetu.

• Poskytuje hvězdicové topologie. V budoucnu můžete rozšířit hvězdicové síťové topologie a zajistit izolaci úloh.

• Pomocí služby firewall webových aplikací můžete zkontrolovat tok provozu HTTP pro všechny webové aplikace.

• Poskytovat podporu pro úlohy, které zahrnují více předplatných.

• Rozšiřte architekturu. Pokud chcete vyhovět novým funkcím nebo úlohám, můžete místo přepracování topologie sítě přidat nové paprsky.

• Podpora sdílení prostředků, jako jsou brány firewall a zóny DNS (Domain Name System) napříč sítěmi

• Sladění s cílovou zónou Azure na podnikové úrovni

Stáhněte si soubor aplikace Visio s touto architekturou.

Další informace najdete v tématu Hvězdicová síťová topologie v Azure.

Další informace o změnách návrhu sítě zahrnutých v kontejnerech Windows v referenční architektuře standardních hodnot AKS najdete v tématu Kontejnery Windows v AKS.

Virtuální síť rozbočovače

Centrální virtuální síť je centrálním bodem připojení a pozorovatelnosti. V této architektuře centrum obsahuje:

• Azure Firewall s globálními zásadami brány firewall definovanými centrálními IT týmy za účelem vynucování zásad brány firewall pro celou organizaci
• Azure Bastion pro vzdálený přístup k virtuálním počítačům
• Podsíť brány pro připojení VPN.
• Azure Monitor pro pozorovatelnost sítě

V rámci sítě má architektura tři podsítě.

Podsíť pro hostování služby Azure Firewall

Azure Firewall je spravovaná služba brány firewall. Instance služby Azure Firewall zabezpečuje odchozí síťový provoz. Bez této vrstvy zabezpečení může provoz komunikovat se škodlivou službou, která není microsoftem, která by mohla exfiltrovat citlivá data úloh. Pomocí Azure Firewall Manageru centrálně nasaďte a nakonfigurujte několik instancí služby Azure Firewall a spravujte zásady služby Azure Firewall pro tento typ architektury virtuální sítě centra.

Podsíť pro hostování brány

Tato podsíť je zástupný symbol pro bránu VPN nebo bránu Azure ExpressRoute. Brána poskytuje připojení mezi směrovači ve vaší místní síti a virtuální sítí.

Podsíť pro hostování služby Azure Bastion

Tato podsíť je zástupný symbol pro Azure Bastion. Azure Bastion můžete použít k bezpečnému přístupu k prostředkům Azure bez vystavení prostředků na internetu. Tato podsíť je určená pouze pro správu a operace.

Paprsková virtuální síť

Paprsková virtuální síť obsahuje cluster AKS a další související prostředky. Paprsk má následující podsítě.

Podsíť pro hostování Aplikace Azure lication Gateway

Application Gateway je nástroj pro vyrovnávání zatížení webového provozu, který funguje ve vrstvě 7. Referenční implementace používá skladovou položku služby Application Gateway v2, která umožňuje bránu Firewall webových aplikací Azure. Firewall webových aplikací zabezpečuje příchozí provoz před běžnými webovými útoky, včetně robotů. Instance má veřejnou konfiguraci front-endové IP adresy, která přijímá požadavky uživatelů. Application Gateway podle návrhu vyžaduje vyhrazenou podsíť.

Podsíť pro hostování prostředků příchozího přenosu dat

Pro směrování a distribuci provozu je Traefik kontroler příchozího přenosu dat, který splňuje prostředky příchozího přenosu dat Kubernetes. V této podsíti existují interní nástroje pro vyrovnávání zatížení Azure. Další informace najdete v tématu Použití interního nástroje pro vyrovnávání zatížení s AKS.

Podsíť pro hostování uzlů clusteru

AKS udržuje dva fondy uzlů, což jsou samostatné skupiny uzlů. Fond systémových uzlů hostuje pody, na kterých běží základní clusterové služby. Fond uzlů uživatele spouští vaši úlohu a kontroler příchozího přenosu dat, který umožňuje příchozí komunikaci s úlohou.

Podsíť pro hostování koncových bodů služby Azure Private Link

Vytvořte připojení Private Link pro Azure Container Registry a Azure Key Vault , aby uživatelé mohli k těmto službám přistupovat prostřednictvím privátního koncového bodu v rámci paprskové virtuální sítě. Privátní koncové body nevyžadují vyhrazenou podsíť. Privátní koncové body můžete také umístit do virtuální sítě centra. V základní implementaci se koncové body nasadí do vyhrazené podsítě v rámci paprskové virtuální sítě. Tento přístup snižuje provoz, který prochází přes připojení peered sítě. Udržuje prostředky, které patří do clusteru ve stejné virtuální síti. Pomocí skupin zabezpečení sítě můžete také použít podrobná pravidla zabezpečení na úrovni podsítě.

Další informace najdete v tématu Možnosti nasazení služby Private Link.

Plánování IP adres

Stáhněte si soubor aplikace Visio s touto architekturou.

Tato referenční architektura používá více přístupů k sítím, které každý vyžaduje adresní prostor IP adres:

• Vaše virtuální síť Azure, která se používá pro prostředky, jako jsou uzly clusteru, privátní koncové body a Application Gateway.
• Cluster používá azure CNI Overlay, který přiděluje IP adresy podům ze samostatného adresního prostoru pro vaši virtuální síť Azure.

Adresní prostor IP adres virtuální sítě

Adresní prostor vaší virtuální sítě Azure by měl být dostatečně velký, aby mohl obsahovat všechny vaše podsítě. Účet pro všechny entity, které přijímají provoz. Kubernetes přiděluje těmto entitám IP adresy z adresního prostoru podsítě. Při plánování IP adres virtuální sítě Azure zvažte tyto body.

• Upgrady: Uzly aktualizace AKS pravidelně aktualizují, aby se zajistilo, že základní virtuální počítače jsou aktuální o funkcích zabezpečení a dalších systémových opravách. Během procesu upgradu vytvoří AKS uzel, který dočasně hostuje pody, zatímco uzel upgradu je oddálený a vyprázdněný. Tento dočasný uzel má přiřazenou IP adresu z podsítě clusteru. Ujistěte se, že máte dostatek adresního prostoru pro tyto dočasné IP adresy uzlu.

  V této architektuře se pody přidělují IP adresy z adresního prostoru překryvného podu Azure CNI, včetně během kumulativních aktualizací. Tento přístup snižuje celkový počet IP adres používaných z vaší virtuální sítě Azure v porovnání s jinými přístupy k sítím Kubernetes.

• Škálovatelnost: Vezměte v úvahu počet uzlů všech systémových a uživatelských uzlů a jejich maximální škálovatelnost. Předpokládejme, že chcete vertikálně na více instancí snížit kapacitu o 400 %. Potřebujete čtyřikrát počet adres pro všechny tyto uzly s horizontálním navýšením kapacity.

  Vzhledem k tomu, že tato architektura používá Azure CNI Overlay, škálovatelnost podů nemá vliv na adresní prostor vaší virtuální sítě.

• Adresy služby Private Link: Faktorujte adresy, které jsou potřeba pro komunikaci s jinými službami Azure přes Private Link. Tato architektura má přiřazené dvě adresy pro propojení se službou Container Registry a Key Vault.

• Rezervované IP adresy: Azure si vyhrazuje určité adresy pro své použití. Nelze jim přiřadit.

Předchozí seznam není vyčerpávající. Pokud váš návrh obsahuje další prostředky, které mají vliv na počet dostupných IP adres, pojmout tyto adresy.

Tato architektura je navržená pro jednu úlohu. V produkčním clusteru AKS vždy oddělte fond systémových uzlů od fondu uzlů uživatele. Při spouštění více úloh v clusteru můžete chtít izolovat fondy uzlů uživatele od sebe navzájem. Když to uděláte, výsledkem bude více podsítí, které jsou menší. Prostředek příchozího přenosu dat může být také složitější a v důsledku toho můžete potřebovat více kontrolerů příchozího přenosu dat, které vyžadují další IP adresy.

Adresní prostor IP adres podů

Azure CNI Překrytí přiřadí IP adresy podům pomocí vyhrazeného adresního prostoru, který je oddělený od adresního prostoru, který používáte ve virtuální síti. Použijte adresní prostor IP adres, který se nepřekrývá s vaší virtuální sítí ani s žádnými partnerskými virtuálními sítěmi. Pokud ale vytváříte více clusterů AKS, můžete bezpečně použít stejný adresní prostor podů v každém clusteru.

Každému uzlu je přiřazen adresní prostor /24 pro jeho pody, takže je důležité zajistit, aby adresní prostor podů byl dostatečně velký, aby umožňoval tolik bloků /24, kolik potřebujete pro počet uzlů v clusteru. Nezapomeňte zahrnout všechny dočasné uzly vytvořené během upgradů nebo operací se škálováním na více instancí. Pokud například pro rozsah CIDR použijete adresní prostor /16, cluster se může zvětšit na maximálně 250 uzlů.

Každý uzel podporuje až 250 podů a tento limit zahrnuje všechny pody, které se během upgradů dočasně vytvářejí.

Další informace najdete v doprovodných materiálech k plánování IP adres pro překrytí Azure CNI.

Další aspekty adresního prostoru IP adres

Kompletní sadu aspektů sítě pro tuto architekturu najdete v tématu Základní síťová topologie AKS. Informace týkající se plánování přidělování IP adres pro cluster AKS najdete v tématu Plánování přidělování IP adres clusteru.

Další informace o aspektech plánování IP adres zahrnutých v kontejnerech Windows v referenční architektuře standardních hodnot AKS najdete v tématu Kontejnery Windows v AKS.

Doplňky a funkce ve verzi Preview

Kubernetes a AKS se neustále vyvíjejí s rychlejšími cykly vydávání verzí než software pro místní prostředí. Tato základní architektura závisí na vybraných funkcích AKS ve verzi Preview a doplňcích AKS. Tady je rozdíl mezi těmito dvěma:

• Tým AKS popisuje funkce ve verzi Preview, které se dodávají a vylepšují , protože mnoho funkcí ve verzi Preview zůstává v tomto stavu jen několik měsíců před přechodem do fáze obecné dostupnosti (GA).

• Doplňky a rozšíření AKS poskytují další podporované funkce. AKS spravuje jejich instalaci, konfiguraci a životní cyklus.

Tato základní architektura nezahrnuje všechny funkce preview ani doplňky. Místo toho zahrnuje pouze ty, které přidávají významnou hodnotu do clusteru pro obecné účely. Vzhledem k tomu, že tyto funkce pocházejí z verze Preview, tato základní architektura se odpovídajícím způsobem reviduje. Existují některé další funkce preview nebo doplňky AKS, které můžete chtít vyhodnotit v předprodukčních clusterech. Tyto funkce můžou zlepšit zabezpečení, spravovatelnost nebo jiné požadavky. U doplňků jiných společností než Microsoft je nutné je nainstalovat a udržovat, včetně sledování dostupných verzí a instalace aktualizací po upgradu verze Kubernetes clusteru.

Referenční informace k imagím kontejneru

Kromě úlohy může cluster obsahovat několik dalších imagí, jako je kontroler příchozího přenosu dat. Některé z těchto imagí se můžou nacházet ve veřejných registrech. Tyto body zvažte při načítání imagí do clusteru.

• Ověřte cluster a stáhněte image.

• Pokud používáte veřejnou image, naimportujte do registru kontejneru odpovídající cíli na úrovni služby (SLO). Jinak může image podléhat neočekávaným problémům s dostupností. Pokud image není dostupná, když ji potřebujete, může to způsobit provozní problémy. Tady je několik výhod použití privátního registru kontejneru, jako je Azure Container Registry, místo veřejného registru:

  • Můžete blokovat neoprávněný přístup k vašim imagím.
  • Nemáte veřejné závislosti.
  • Přístup k protokolům vyžádané replikace imagí můžete získat přístup k monitorování aktivit a problémů s připojením ke třídění.
  • Můžete využít integrované prohledávání kontejnerů a dodržování předpisů image.

• Načítá image z autorizovaných registrů. Toto omezení můžete vynutit prostřednictvím služby Azure Policy. V této referenční implementaci cluster načítá pouze image z instance Container Registry, která se nasazuje.

Konfigurace výpočetních prostředků pro základní cluster

V AKS se každý fond uzlů mapuje na škálovací sadu virtuálních počítačů. Uzly jsou virtuální počítače v každém fondu uzlů. Pokud chcete minimalizovat náklady, zvažte použití menší velikosti virtuálního počítače pro fond systémových uzlů. Tato referenční implementace nasadí fond systémových uzlů se třemi DS2_v2 uzly. Tato velikost je dostatečná pro splnění očekávaného zatížení systémových podů. Disk s operačním systémem je 512 GB.

Pro fond uzlů uživatele je potřeba vzít v úvahu některé aspekty:

• Zvolte větší velikosti uzlů a zabalte maximální počet podů nastavených na uzlu. Velké uzly minimalizují nároky na služby, které běží na všech uzlech, jako je monitorování a protokolování.

• Pokud máte specifické požadavky na úlohy, vyberte příslušný typ virtuálního počítače. Můžete například potřebovat produkt optimalizovaný pro paměť pro některé úlohy nebo akcelerovaný produkt GPU pro jiné. Další informace najdete v tématu Velikosti virtuálních počítačů v Azure.

• Nasaďte aspoň dva uzly. Díky tomu má úloha model vysoké dostupnosti se dvěma replikami. Pomocí AKS můžete počet uzlů změnit bez opětovného vytvoření clusteru.

• Naplánujte skutečné velikosti uzlů pro vaši úlohu na základě požadavků určených týmem pro návrh. Na základě obchodních požadavků tato architektura používá DS4_v2 pro produkční úlohy. Pokud chcete snížit náklady, můžete velikost snížit na DS3_v2, což je minimální doporučení.

• Při plánování kapacity clusteru předpokládejme, že vaše úlohy spotřebovávají až 80 % každého uzlu. Zbývající 20 % je vyhrazeno pro služby AKS.

• Nastavte maximální počet podů na uzel na základě plánování kapacity. Pokud se pokoušíte vytvořit směrný plán kapacity, začněte hodnotou 30. Upravte danou hodnotu na základě požadavků úlohy, velikosti uzlu a omezení IP adres.

Výběr operačního systému

Většina clusterů AKS používá Linux jako operační systém pro fondy uzlů. V této referenční implementaci používáme Azure Linux, což je zjednodušená posílená distribuce Linuxu, která je vyladěná pro Azure. Pokud chcete, můžete použít jinou linuxovou distribuci, například Ubuntu, nebo pokud máte požadavky, které Azure Linux nemůže splnit.

AKS také podporuje fondy uzlů, na kterých běží operační systém Windows Server. Existují zvláštní požadavky na některé aspekty clusteru se systémem Windows. Další informace o architektuře fondu uzlů s Windows najdete v tématu Spouštění kontejnerů Windows v AKS.

Pokud máte úlohu složenou ze kombinace technologií, můžete použít různé operační systémy v různých fondech uzlů. Pokud ale pro úlohu nepotřebujete jiné operační systémy, doporučujeme použít pro všechny fondy uzlů úloh jeden operační systém.

Integrace ID Microsoft Entra pro cluster

Zabezpečení přístupu ke clusteru a z clusteru je důležité. Představte si ho z pohledu clusteru, když provádíte volby zabezpečení:

• Vnitřní přístup. Zvažte přístup AKS k komponentám Azure, jako je síťová infrastruktura, Container Registry a Key Vault. Autorizovat pouze prostředky, ke kterým má mít cluster povolený přístup.
• Přístup mimo přístup. Poskytněte identitám přístup ke clusteru Kubernetes. Autorizovat pouze externí entity, které mají povolený přístup k serveru rozhraní API Kubernetes a Azure Resource Manageru.

Přístup AKS k Azure

Existují dva způsoby správy přístupu AKS k Azure prostřednictvím ID Microsoft Entra: instanční objekty nebo spravované identity pro prostředky Azure.

Z těchto dvou metod správy přístupu AKS k Azure doporučujeme spravované identity. U instančních objektů musíte spravovat a obměňovat tajné kódy ručně nebo programově. Se spravovanými identitami spravuje a provádí ID Microsoft Entra ověřování a včasné obměny tajných kódů za vás.

Doporučujeme povolit a používat spravované identity , aby cluster mohl komunikovat s externími prostředky Azure prostřednictvím ID Microsoft Entra. I když integraci Microsoft Entra ID nepoužíváte okamžitě, můžete ji začlenit později.

Ve výchozím nastavení existují dvě primární identity, které cluster používá: identita clusteru a identita kubeletu. Komponenty řídicí roviny AKS používají identitu clusteru ke správě prostředků clusteru, včetně nástrojů pro vyrovnávání zatížení příchozího přenosu dat a veřejných IP adres spravovaných službou AKS. Identita kubelet se ověřuje ve službě Container Registry. Některé doplňky také podporují ověřování pomocí spravované identity.

Spravované identity byste měli použít, když cluster potřebuje načíst image z registru kontejneru. Tato akce vyžaduje, aby cluster získal přihlašovací údaje registru. Pokud spravovanou identitu nepoužíváte, můžete tyto informace uložit ve formě tajného objektu Kubernetes a použít imagePullSecrets k načtení tajného kódu. Tento přístup nedoporučujeme kvůli složitostem zabezpečení. Nejen že potřebujete předchozí znalosti tajného kódu, musíte ho také uložit v rámci kanálu DevOps. Dalším důvodem, proč tento přístup nedoporučujeme, je provozní režie při správě obměně tajného klíče. Místo toho udělte AcrPull přístup ke spravované identitě clusteru kubelet vašemu registru. Tento přístup se zabývá obavami.

V této architektuře cluster přistupuje k prostředkům Azure, které Microsoft Entra ID zabezpečuje, a cluster provádí operace, které podporují spravované identity. Přiřaďte řízení přístupu na základě role Azure (Azure RBAC) a oprávnění ke spravovaným identitám clusteru v závislosti na operacích, které cluster dělá. Cluster se ověří v Microsoft Entra ID a pak je povolený nebo odepřený přístup na základě přiřazených rolí. Tady je několik příkladů z této referenční implementace, kde jsou k clusteru přiřazeny předdefinované role Azure:

• Role Přispěvatel sítě Spravuje schopnost clusteru řídit paprskovou virtuální síť. S tímto přiřazením role může identita přiřazená systémem clusteru AKS pracovat s vyhrazenou podsítí pro službu kontroleru interního příchozího přenosu dat.

• Monitorování role vydavatele metrik Spravuje schopnost clusteru odesílat metriky do služby Azure Monitor.

• Role AcrPull Spravuje schopnost clusteru načíst image ze zadaných instancí služby Azure Container Registry.

Přístup ke clusteru

Integrace Microsoft Entra také zjednodušuje zabezpečení externího přístupu. Můžete například chtít použít kubectl. Jako počáteční krok můžete spuštěním az aks get-credentials příkazu získat přihlašovací údaje clusteru. Microsoft Entra ID ověřuje vaši identitu vůči rolím Azure, které mají povoleno získat přihlašovací údaje clusteru. Další informace najdete v tématu Dostupná oprávnění rolí clusteru.

AKS podporuje přístup Kubernetes pomocí ID Microsoft Entra dvěma způsoby. První je použití Microsoft Entra ID jako zprostředkovatele identity integrovaného s nativním systémem Kubernetes RBAC. Druhá metoda používá k řízení přístupu ke clusteru nativní Azure RBAC. Oba přístupy jsou podrobně popsané v následujících částech.

Přidružení RBAC Kubernetes k Microsoft Entra ID

Kubernetes podporuje RBAC prostřednictvím:

• Sada oprávnění, která definujete pomocí objektu Role nebo ClusterRole objektu pro oprávnění na úrovni clusteru.

• Vazby, které přiřazují uživatele a skupiny, kteří mají oprávnění k provádění akcí. Definujte vazby pomocí objektu nebo ClusterRoleBinding objektuRoleBinding.

Kubernetes má některé předdefinované role, jako je správce clusteru, úpravy a zobrazení. Tyto role svážete s uživateli a skupinami Microsoft Entra, aby bylo možné spravovat přístup pomocí podnikového adresáře. Další informace najdete v tématu Použití RBAC Kubernetes s integrací Microsoft Entra.

Nezapomeňte do kontrol přístupu Microsoft Entra zahrnout skupiny Microsoft Entra pro přístup ke clusteru a oboru názvů.

Použití Azure RBAC pro autorizaci Kubernetes

Místo použití nativního řízení ClusterRoleBindings přístupu na základě role Kubernetes a RoleBindings pro autorizaci s integrovaným ověřováním Microsoft Entra doporučujeme použít azure RBAC a přiřazení rolí Azure. Tento přístup vynucuje kontroly autorizace v clusteru. Tyto role můžete dokonce přiřadit v oborech skupiny pro správu, předplatného nebo skupiny prostředků. Všechny clustery v oboru pak dědí konzistentní sadu přiřazení rolí s ohledem na to, kdo má oprávnění pro přístup k objektům v clusteru Kubernetes.

Další informace najdete v tématu Azure RBAC pro autorizaci Kubernetes.

Místní účty

AKS podporuje nativní ověřování uživatelů Kubernetes. Tuto metodu nedoporučujeme používat k poskytování přístupu uživatelů ke clusterům. Tato metoda je založená na certifikátech a provádí se externě u vašeho primárního zprostředkovatele identity, což ztěžuje centralizované řízení přístupu uživatelů a zásady správného řízení. Vždy spravujte přístup ke clusteru pomocí ID Microsoft Entra a nakonfigurujte cluster tak, aby explicitně zakázal přístup k místnímu účtu.

V této referenční implementaci je přístup k účtům místního clusteru explicitně zakázán, když systém nasadí cluster.

Integrace ID Microsoft Entra pro úlohu

Podobně jako spravovaná identita přiřazená systémem Azure pro celý cluster můžete spravované identity přiřadit na úrovni podu. Identita úlohy umožňuje hostované úloze přistupovat k prostředkům prostřednictvím ID Microsoft Entra. Například úloha ukládá soubory ve službě Azure Storage. Když potřebuje přístup k těmto souborům, pod se vůči prostředku ověří jako spravovaná identita Azure.

V této referenční implementaci ID úloh Microsoft Entra v AKS poskytuje spravované identity pro pody. Tento přístup se integruje s nativními možnostmi Kubernetes pro federaci s externími zprostředkovateli identit. Další informace o ID úloh Microsoft Entra federaci najdete v tématu Federace identit úloh.

Výběr síťového modelu

AKS podporuje více síťových modelů, včetně překrytí kubenet, CNI a Azure CNI. Modely CNI jsou pokročilejší modely a jsou vysoce výkonné. Při komunikaci mezi pody se výkon CNI podobá výkonu virtuálních počítačů ve virtuální síti. CNI také nabízí rozšířené řízení zabezpečení, protože umožňuje používat zásady sítě Azure. Doporučujeme síťový model založený na CNI.

V modelu CNI, který není překryvný, získá každý pod IP adresu z adresního prostoru podsítě. Prostředky ve stejné síti (nebo partnerské prostředky) mají přístup k podům přímo prostřednictvím jejich IP adresy. Překlad síťových adres (NAT) není pro směrování daného provozu potřeba.

V této referenční implementaci používáme azure CNI Overlay, který pro uzly přiděluje pouze IP adresy z podsítě fondu uzlů a pro IP adresy podů používá vysoce optimalizovanou vrstvu překrytí. Vzhledem k tomu, že Azure CNI Overlay používá méně IP adres virtuální sítě než mnoho dalších přístupů, doporučujeme ho použít pro nasazení s omezenými IP adresami.

Informace o modelech najdete v tématu Volba síťového modelu rozhraní kontejneru pro použití a porovnání síťových modelů kubenet a rozhraní Azure Container Networking Interface.

Nasazení prostředků příchozího přenosu dat

Prostředky příchozího přenosu dat Kubernetes zpracovávají směrování a distribuci příchozího provozu do clusteru. Existují dvě části prostředků příchozího přenosu dat:

• Interní nástroj pro vyrovnávání zatížení spravovaný službou AKS. Nástroj pro vyrovnávání zatížení zveřejňuje kontroler příchozího přenosu dat prostřednictvím privátní statické IP adresy. Slouží jako jediný kontaktní bod, který přijímá příchozí toky.

  Tato architektura používá Azure Load Balancer. Load Balancer je mimo cluster v podsíti vyhrazené pro prostředky příchozího přenosu dat. Přijímá provoz ze služby Application Gateway a tato komunikace probíhá přes protokol TLS (Transport Layer Security). Další informace o šifrování TLS pro příchozí provoz najdete v tématu Tok příchozího přenosu dat.

• Kontroler příchozího přenosu dat. Tento příklad používá Traefik. Spouští se ve fondu uzlů uživatele v clusteru. Přijímá provoz z interního nástroje pro vyrovnávání zatížení, ukončí protokol TLS a předá ho podům úloh přes protokol HTTP.

Kontroler příchozího přenosu dat je důležitou součástí clusteru. Při konfiguraci této komponenty zvažte následující body.

• Omezte kontroler příchozího přenosu dat na konkrétní rozsah operací v rámci rozhodování o návrhu. Například můžete řadiči povolit interakci pouze s pody, které spouští konkrétní úlohu.

• Vyhněte se umístění replik na stejný uzel, aby se zatížení rozložilo, a pomáhá zajistit kontinuitu podnikových procesů v případě selhání uzlu. Slouží podAntiAffinity k tomuto účelu.

• Omezit pody tak, aby byly naplánovány pouze ve fondu uzlů uživatele pomocí .nodeSelectors Toto nastavení izoluje úlohy a systémové pody.

• Otevřete porty a protokoly, které umožňují konkrétním entitám odesílat provoz do kontroleru příchozího přenosu dat. V této architektuře traefik přijímá provoz pouze ze služby Application Gateway.

• Nakonfigurujte a livenessProbe nastavtereadinessProbe, která monitorují stav podů v zadaném intervalu. Kontroler příchozího přenosu dat by měl odesílat signály, které označují stav podů.

• Zvažte omezení přístupu kontroleru příchozího přenosu dat k určitým prostředkům a možnost provádět určité akce. Toto omezení můžete implementovat prostřednictvím oprávnění RBAC Kubernetes. Například v této architektuře má Traefik udělená oprávnění ke sledování, získávání a výpisu služeb a koncových bodů pomocí pravidel v objektu Kubernetes ClusterRole .

Další informace o návrhu příchozího přenosu dat pro kontejnery Windows v AKS v referenční architektuře směrného plánu najdete v tématu Kontejnery Windows v AKS.

Nastavení směrovače

Kontroler příchozího přenosu dat používá trasy k určení, kam se má odesílat provoz. Trasy určují zdrojový port, na kterém se provoz přijímá, a informace o cílových portech a protokolech.

Tady je příklad z této architektury:

Traefik ke konfiguraci tras používá zprostředkovatele Kubernetes. Volby annotationsa entrypoints , tlskteré označují, že trasy se obsluhují přes HTTPS. Možnost middlewares určuje, že je povolený pouze provoz z podsítě služby Application Gateway. Odpovědi používají kódování gzip, pokud klient přijme. Protože Traefik ukončuje protokol TLS, komunikace s back-endovými službami je přes protokol HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Zabezpečení síťového toku

V této architektuře tok sítě zahrnuje:

• Příchozí provoz z klienta do úlohy, která běží v clusteru.

• Odchozí provoz z podu nebo uzlu v clusteru do externí služby.

• Provoz mezi pody mezi pody Tento provoz zahrnuje komunikaci mezi kontrolerem příchozího přenosu dat a úlohou. Pokud se vaše úloha skládá z více aplikací nasazených do clusteru, komunikace mezi těmito aplikacemi spadá také do této kategorie.

• Provoz správy mezi klientem a serverem rozhraní API Kubernetes

Stáhněte si soubor aplikace Visio s touto architekturou.

Tato architektura má několik vrstev zabezpečení pro zabezpečení všech typů provozu.

Tok příchozího přenosu dat

Architektura přijímá pouze šifrované požadavky TLS z klienta. Protokol TLS v1.2 je minimální povolená verze s omezenou sadou šifer. Je povoleno striktní porovnávání názvu serveru (SNI). Kompletní protokol TLS se nastavuje prostřednictvím služby Application Gateway pomocí dvou různých certifikátů TLS, jak je znázorněno v následujícím diagramu.

Stáhněte si soubor aplikace Visio s touto architekturou.

1. Klient odešle požadavek HTTPS na název domény: bicycle.contoso.com. Tento název je přidružený k záznamu DNS A k veřejné IP adrese služby Application Gateway. Tento provoz je šifrovaný, aby se zajistilo, že provoz mezi klientským prohlížečem a bránou není možné zkontrolovat ani změnit.

2. Application Gateway má integrovaný firewall webových aplikací a vyjednává metodu handshake protokolu TLS, která bicycle.contoso.comumožňuje pouze zabezpečené šifry. Application Gateway je bod ukončení protokolu TLS, což je důležité, protože brána firewall webových aplikací služby Application Gateway potřebuje zkontrolovat odpověď ve formátu prostého textu. Key Vault ukládá certifikát TLS. Cluster k němu přistupuje pomocí spravované identity přiřazené uživatelem, která je integrovaná se službou Application Gateway. Další informace najdete v tématu Ukončení šifrování TLS s využitím certifikátů služby Key Vault.

   Application Gateway zpracovává pravidla kontroly firewallu webových aplikací a spouští pravidla směrování, která přesměrují provoz do nakonfigurovaného back-endu.

3. Při přesunu provozu ze služby Application Gateway do back-endu se znovu zašifruje jiným certifikátem TLS, což je zástupný znak pro *.aks-ingress.contoso.com, protože se předává internímu nástroji pro vyrovnávání zatížení. Toto opětovné šifrování pomáhá zajistit, aby nezabezpečený provoz neprotékal do podsítě clusteru.

4. Kontroler příchozího přenosu dat přijímá šifrovaný provoz přes nástroj pro vyrovnávání zatížení. Kontroler je dalším bodem ukončení protokolu TLS a *.aks-ingress.contoso.com předává provoz podům úloh přes protokol HTTP. Certifikáty jsou uložené ve službě Key Vault a ovladač rozhraní csI (Container Storage Interface) je připojí ke clusteru. Další informace najdete v tématu Přidání správy tajných kódů.

V každém segmentu směrování přes pod úlohy můžete implementovat kompletní provoz TLS. Při rozhodování o zabezpečení provozu mezi pody nezapomeňte měřit výkon, latenci a provozní účinky. U většiny clusterů s jedním tenantem, se správnými postupy řízení RBAC a vyspělými postupy životního cyklu vývoje softwaru, stačí protokol TLS šifrovat až do kontroleru příchozího přenosu dat a chránit ho pomocí firewallu webových aplikací. Tento přístup minimalizuje režii při správě úloh a režii kvůli nízkému výkonu sítě. Požadavky na úlohy a dodržování předpisů určují, kde provádíte ukončení protokolu TLS.

Výstupní tok provozu

V této architektuře doporučujeme, aby veškerý odchozí provoz z clusteru komunikoval přes bránu Azure Firewall. Nebo můžete použít vlastní podobné síťové virtuální zařízení. Nedoporučujeme používat jiné možnosti výchozího přenosu dat, jako je Azure NAT Gateway nebo proxy server HTTP, protože neposkytují kontrolu síťového provozu. U nulová důvěra (Zero Trust) řízení a možnosti kontroly provozu prochází veškerý výchozí provoz z clusteru přes bránu firewall. Tuto konfiguraci můžete implementovat pomocí uživatelem definovaných tras (UDR). Dalším segmentem směrování trasy je privátní IP adresa služby Azure Firewall. Azure Firewall se rozhodne, jestli se má blokovat nebo povolit odchozí provoz. Toto rozhodnutí vychází z konkrétních pravidel, která definujete ve službě Azure Firewall, nebo na předdefinovaných pravidlech analýzy hrozeb.

Alternativou ke službě Azure Firewall je použití funkce proxy serveru HTTP AKS. Veškerý provoz, který opustí cluster, přejde na IP adresu proxy serveru HTTP, který předává provoz nebo ho zahodí.

U obou metod zkontrolujte požadovaná pravidla odchozího síťového provozu pro AKS.

Výjimkou nulová důvěra (Zero Trust) ovládacího prvku je, když cluster potřebuje komunikovat s jinými prostředky Azure. Cluster může například potřebovat vyžádat aktualizovanou image z registru kontejneru nebo tajných kódů ze služby Key Vault. V těchto scénářích doporučujeme používat službu Private Link. Výhodou je, že se konkrétní podsítě dostanou přímo ke službě a provoz mezi clusterem a službami neprochází přes internet. Nevýhodou je, že Služba Private Link potřebuje místo použití cílové služby přes veřejný koncový bod další konfiguraci. Kromě toho ne všechny služby Azure ani produkty podporují Službu Private Link. V takových případech zvažte povolení koncového bodu služby virtuální sítě v podsíti pro přístup ke službě.

Pokud privátní propojení nebo koncové body služby nejsou volbou, můžete prostřednictvím svých veřejných koncových bodů kontaktovat jiné služby a řídit přístup prostřednictvím pravidel služby Azure Firewall a brány firewall integrované do cílové služby. Vzhledem k tomu, že tento provoz prochází statickými IP adresami brány firewall, můžete tyto adresy přidat do seznamu povolených IP adres služby. Nevýhodou je, že Azure Firewall pak potřebuje více pravidel, aby se zajistilo, že povoluje jenom provoz z konkrétní podsítě. Při plánování více IP adres pro výchozí přenos dat s využitím služby Azure Firewall je potřeba tyto adresy zahrnout do těchto adres. Jinak byste se mohli dostat do vyčerpání portů. Další informace o plánování více IP adres najdete v tématu Vytvoření služby Azure Firewall s více IP adresami.

Informace o aspektech výchozího přenosu dat specifického pro Windows v kontejnerech Windows v referenční architektuře standardních hodnot AKS najdete v tématu Kontejnery Windows v AKS.

Provoz mezi pody

Ve výchozím nastavení může pod přijímat provoz z jakéhokoli jiného podu v clusteru. Pomocí Kubernetes NetworkPolicy omezte síťový provoz mezi pody. Použijte zásady uvážlivě nebo můžete mít situaci, kdy je zablokovaný kritický tok sítě. Podle potřeby povolte pouze konkrétní komunikační cesty, například provoz mezi kontrolerem příchozího přenosu dat a úlohou. Další informace najdete v tématu Zásady sítě.

Při zřizování clusteru povolte zásady sítě, protože ho nemůžete přidat později. Máte několik možností pro technologie, které implementují NetworkPolicy. Doporučujeme zásady sítě Azure, které vyžadují rozhraní Azure Container Networking Interface (CNI). Další informace najdete v následující poznámce. Mezi další možnosti patří síťová zásada Calico, dobře známá open source možnost. Pokud potřebujete spravovat zásady sítě na úrovni clusteru, zvažte Calico. Calico se nevztahuje na standardní podpora Azure.

Další informace najdete v tématu Rozdíly mezi moduly zásad sítě Azure.

Provoz správy

V rámci spouštění clusteru přijímá server rozhraní API Kubernetes provoz z prostředků, které chtějí provádět operace správy v clusteru, například žádosti o vytvoření prostředků pro škálování clusteru. Mezi příklady těchto prostředků patří fond agentů sestavení v kanálu DevOps, instance Služby Azure Bastion v podsíti Služby Azure Bastion a samotné fondy uzlů. Místo přijetí tohoto provozu správy ze všech IP adres použijte funkci rozsahů IP adres autorizovaných k AKS, která povoluje provoz jenom z vašich autorizovaných rozsahů IP adres na server rozhraní API.

Další informace najdete v tématu Definování rozsahů IP adres autorizovaných serverem rozhraní API.

Pro další vrstvu řízení můžete za cenu větší složitosti zřídit privátní cluster AKS. Pomocí privátního clusteru můžete zajistit, aby síťový provoz mezi vaším serverem ROZHRANÍ API a fondy uzlů zůstal pouze v privátní síti a nikdy nebyl vystavený internetu. Další informace najdete v tématu Privátní clustery AKS.

Přidání správy tajných kódů

Ukládejte tajné kódy do spravovaného úložiště klíčů, jako je key Vault. Výhodou je, že spravované úložiště klíčů zpracovává rotaci tajných kódů. Poskytuje silné šifrování a protokol auditu přístupu. Udržuje také základní tajné kódy mimo kanál nasazení. V této architektuře je povolená a nakonfigurovaná brána firewall služby Key Vault a služba Private Link se používá při připojování z prostředků v Azure, které potřebují přístup k tajným klíčům a certifikátům.

Key Vault je dobře integrovaný s dalšími službami Azure. Pro přístup k tajným kódům použijte integrovanou funkci těchto služeb. Další informace o tom, jak Application Gateway přistupuje k certifikátům TLS pro tok příchozího přenosu dat, najdete v části Tok příchozího přenosu dat.

Model oprávnění Azure RBAC pro Key Vault umožňuje přiřazovat identity úloh k přiřazení role Uživatel tajných kódů služby Key Vault nebo Čtenář služby Key Vault a přistupovat k tajným kódům. Další informace najdete v tématu Přístup ke službě Key Vault pomocí RBAC.

Přístup k tajným kódům clusteru

Pokud chcete podům povolit přístup k tajným kódům z konkrétního úložiště, musíte použít identity úloh. K usnadnění procesu načítání použijte ovladač CSI úložiště tajných kódů. Pokud pod potřebuje tajný klíč, ovladač se připojí k zadanému úložišti, načte tajný kód na svazku a připojí tento svazek v clusteru. Pod pak může tajný kód získat ze systému souborů svazku.

Ovladač CSI má mnoho poskytovatelů, kteří podporují různá spravovaná úložiště. Tato implementace používá Key Vault s ovladačem CSI úložiště tajných kódů. Doplněk načte certifikát TLS ze služby Key Vault a načte ovladač do podu, na kterém běží kontroler příchozího přenosu dat. K této operaci dochází při vytváření podů a svazek ukládá veřejné i privátní klíče.

Úložiště úloh

Úloha v této architektuře je bezstavová. Pokud potřebujete uložit stav, doporučujeme ho zachovat mimo cluster. Pokyny pro stav úlohy jsou mimo rozsah tohoto článku.

Další informace najdete v tématu Možnosti úložiště pro aplikace v AKS.

Správa zásad

Efektivním způsobem správy clusteru AKS je vynucování zásad správného řízení prostřednictvím zásad. Kubernetes implementuje zásady prostřednictvím gatekeepera open policy agenta (OPA). V případě AKS doručujte zásady prostřednictvím Služby Azure Policy. Každá zásada se vztahuje na všechny clustery v jeho oboru. OPA Gatekeeper zpracovává vynucování zásad v clusteru a protokoluje všechny kontroly zásad. Změny zásad se okamžitě neprojeví ve vašem clusteru, takže počítejte s určitými zpožděními.

Ke správě clusterů AKS můžete použít Azure Policy k:

• Zabráníte nebo omezíte nasazení clusterů AKS ve skupině prostředků nebo předplatném. Použijte standardy pro vaši organizaci. Můžete například postupovat podle konvence pojmenování nebo zadat značku.
• Zabezpečte cluster AKS prostřednictvím služby Azure Policy pro Kubernetes.

Při nastavování zásad je použijte na základě požadavků úlohy. Zvažte tyto faktory:

• Chcete nastavit kolekci zásad, označovanou také jako iniciativy, nebo zvolit jednotlivé zásady? Azure Policy poskytuje dvě předdefinované iniciativy: základní a omezené. Každá iniciativa je kolekce předdefinovaných zásad použitelných pro cluster AKS. Doporučujeme vybrat iniciativu a zvolit další zásady pro cluster a prostředky, jako je Container Registry, Application Gateway nebo Key Vault, které s clusterem pracují. Zvolte zásady na základě požadavků vaší organizace.

• Chcete akci auditovat nebo odepřít? V režimu auditování je akce povolená, ale označená jako nevyhovující předpisům. Procesy pro kontrolu nekompatibilních stavů v pravidelných intervalech a provedení nezbytných opatření. V režimu Odepřít je akce zablokovaná, protože porušuje zásady. Při výběru tohoto režimu buďte opatrní, protože může být příliš omezující, aby úloha fungovala.

• Máte ve své úloze oblasti, které by neměly být v souladu s návrhem? Azure Policy má možnost určit obory názvů Kubernetes, které jsou vyloučené z vynucování zásad. Doporučujeme, abyste zásady stále použili v režimu auditování , abyste o těchto instancích věděli.

• Máte požadavky, na které se předdefinované zásady nevztahují? Můžete vytvořit vlastní definici služby Azure Policy, která použije vlastní zásady OPA Gatekeeper. Neuplatněte vlastní zásady přímo na cluster. Další informace najdete v tématu Vytváření a přiřazování definic vlastních zásad.

• Máte požadavky na celou organizaci? Pokud ano, přidejte tyto zásady na úrovni skupiny pro správu. Váš cluster by měl také přiřazovat vlastní zásady specifické pro úlohy, i když má vaše organizace obecné zásady.

• Přiřadíte zásady Azure konkrétním oborům? Ujistěte se, že se také ověřují produkční zásady v předprodukčním prostředí. Jinak při nasazování do produkčního prostředí může docházet k neočekávaným dodatečným omezením, která v předprodukčním prostředí nezapočítáváte.

Tato referenční implementace umožňuje službě Azure Policy při vytvoření clusteru AKS. Omezující iniciativa je přiřazena v režimu auditování , aby bylo možné získat přehled o nedodržování předpisů.

Implementace také nastavuje další zásady, které nejsou součástí žádné předdefinované iniciativy. Tyto zásady jsou nastavené v režimu Odepření . Existují například zásady, které zajistí, že image se načítají jenom z nasazené instance container Registry. Zvažte vytvoření vlastních iniciativ. Zkombinujte zásady platné pro vaši úlohu do jednoho přiřazení.

Pokud chcete sledovat, jak Azure Policy funguje v rámci vašeho clusteru, můžete přistupovat k protokolům podů pro všechny pody v gatekeeper-system oboru názvů a protokolům pro azure-policy pody azure-policy-webhook v kube-system oboru názvů.

Další informace o aspektech azure Policy specifických pro Windows najdete v článku o správě zásad AKS v kontejnerech Windows.

Škálovatelnost uzlů a podů

Díky rostoucí poptávce může Kubernetes horizontálně navýšit kapacitu přidáním dalších podů do existujících uzlů prostřednictvím horizontálního automatického škálování podů. Pokud Už Kubernetes nemůže plánovat více podů, je potřeba zvýšit počet uzlů prostřednictvím automatického škálování clusteru AKS. Kompletní řešení škálování musí mít způsoby, jak škálovat repliky podů i počet uzlů v clusteru.

Existují dva přístupy: automatické škálování nebo ruční škálování.

Automatické škálování i ruční přístup vyžadují monitorování a nastavení upozornění na využití procesoru nebo vlastní metriky. U škálování podů může operátor aplikace zvýšit nebo snížit počet replik podů úpravou ReplicaSet rozhraní API Kubernetes. U škálování clusteru je jednou metodou oznámení, když plánovač Kubernetes selže. Dalším způsobem je sledovat čekající pody v průběhu času. Počet uzlů můžete upravit prostřednictvím Azure CLI nebo webu Azure Portal.

Doporučujeme přístup k automatickému škálování, protože některé z těchto ručních mechanismů jsou integrované do automatického škálování.

Jako obecná metoda začněte testováním výkonnosti s minimálním počtem podů a uzlů. Tyto hodnoty použijte k vytvoření očekávaného směrného plánu. Pak pomocí kombinace metrik výkonu a ručního škálování vyhledejte kritické body a seznamte se s odezvou aplikace na škálování. Nakonec tato data použijte k nastavení parametrů pro automatické škálování. Další informace o scénáři ladění výkonu pomocí AKS najdete v tématu Scénář ladění výkonu: Distribuované obchodní transakce.

Horizontální automatické škálování podů

Horizontální automatické škálování podů (HPA) je prostředek Kubernetes, který škáluje počet podů.

V prostředku HPA doporučujeme nastavit minimální a maximální počet replik. Hodnoty omezují hranice automatického škálování.

HPA se může škálovat na základě využití procesoru, využití paměti a vlastních metrik. K dispozici je pouze využití procesoru. Definice HorizontalPodAutoscaler určuje cílové hodnoty pro metriky. Například specifikace nastaví cílové využití procesoru. Zatímco pody běží, kontroler HPA používá rozhraní API metrik Kubernetes ke kontrole využití procesoru jednotlivých podů. Porovná danou hodnotu s cílovým využitím a vypočítá poměr. Pak pomocí tohoto poměru určí, jestli jsou pody přetížené nebo nepřidělené. Využívá plánovač Kubernetes k přiřazování nových podů uzlům nebo odebírání podů z uzlů.

Může dojít k konfliktu časování, kdy HPA kontroluje před dokončením operace škálování. Výsledkem může být nesprávný výpočet poměru. Další informace najdete v tématu Cooldown událostí škálování.

Pokud je vaše úloha řízená událostmi, oblíbenou opensourcovou možností je automatické škálování řízené událostmi Kubernetes (KEDA). Zvažte KEDA, pokud zdroj událostí, jako je například fronta zpráv, řídí vaši úlohu, a nikoli zatížení vázané na procesor nebo paměťovou vazbu. KEDA podporuje mnoho zdrojů událostí nebo škálovačů. Použijte seznam zdrojů událostí, které může KEDA škálovat ve škálovacích nástrojích KEDA. Seznam obsahuje škálovací nástroj služby Azure Monitor, což je pohodlný způsob škálování úloh KEDA na základě metrik služby Azure Monitor.

Automatické škálování clusteru

Automatické škálování clusteru je komponenta doplňku AKS, která škáluje počet uzlů ve fondu uzlů. Přidejte ho během zřizování clusteru. Pro každý fond uzlů uživatele potřebujete samostatné automatické škálování clusteru.

Plánovač Kubernetes aktivuje automatické škálování clusteru. Pokud plánovač Kubernetes kvůli omezením prostředků neplánuje pod, automatické škálování automaticky zřídí nový uzel ve fondu uzlů. Naopak automatické škálování clusteru kontroluje nevyužitou kapacitu uzlů. Pokud uzel neběží s očekávanou kapacitou, přesunou se pody do jiného uzlu a nepoužívaný uzel se odebere.

Když povolíte automatické škálování, nastavte maximální a minimální počet uzlů. Doporučené hodnoty závisí na očekávaném výkonu úlohy, na to, kolik má cluster růst, a na náklady. Minimálním číslem je rezervovaná kapacita pro tento fond uzlů. V této referenční implementaci je minimální hodnota nastavena na dvě kvůli jednoduchosti úlohy.

Pro fond systémových uzlů je doporučená minimální hodnota tři.

Informace o aspektech škálování specifických pro Windows, které jsou součástí této referenční architektury standardních hodnot, najdete v článku o kontejnerech Windows v AKS .

Rozhodnutí o kontinuitě podnikových procesů

Pokud chcete zachovat provozní kontinuitu, definujte SLO pro infrastrukturu a vaši aplikaci. Další informace najdete v tématu Doporučení pro definování cílů spolehlivosti. Projděte si podmínky smlouvy o úrovni služeb (SLA) pro AKS v nejnovější smlouvě SLA pro online služby článek.

Uzly clusteru

Abyste splnili minimální úroveň dostupnosti pro úlohy, potřebujete ve fondu uzlů více uzlů. Pokud uzel selže, může aplikace pokračovat ve spuštění jiného uzlu ve stejném fondu uzlů a clusteru. Pro spolehlivost doporučujeme pro fond systémových uzlů tři uzly. Pro fond uzlů uživatele začněte beze dvou uzlů. Pokud potřebujete vyšší dostupnost, zřiďte více uzlů.

Izolujte aplikaci od systémových služeb tak, že ji umístíte do samostatného fondu uzlů, který se označuje jako fond uzlů uživatele. Služby Kubernetes tak běží na vyhrazených uzlech a nekonkurují vašim úlohám. K identifikaci fondu uzlů a plánování úloh doporučujeme používat značky, popisky a tainty. Ujistěte se, že je fond systémových uzlů taintovaný pomocí taintuCriticalAddonsOnly.

Pro spolehlivost jsou zásadní pravidelné aktualizace clusteru, jako jsou včasné aktualizace. Doporučujeme také monitorovat stav podů prostřednictvím sond.

Dostupnost podů

Zadejte požadavky na prostředky podu: Ve svých nasazeních doporučujeme zadat požadavky na prostředky podu. Plánovač pak může odpovídajícím způsobem naplánovat pod. Spolehlivost je výrazně snížená, pokud se pody nedají naplánovat.

Nastavení rozpočtů přerušení podů: Toto nastavení určuje, kolik replik v nasazení se může během události aktualizace nebo upgradu snížit. Další informace najdete v tématu Rozpočty přerušení podů.

Nakonfigurujte v nasazení několik replik pro zpracování přerušení, jako jsou selhání hardwaru. U plánovaných událostí, jako jsou aktualizace a upgrady, může rozpočet přerušení pomoci zajistit požadovaný počet replik podů pro zpracování očekávaného zatížení aplikace.

Nastavte kvóty prostředků pro obory názvů úloh: Kvóta prostředků v oboru názvů pomáhá zajistit správné nastavení požadavků a limitů podů v nasazení. Další informace najdete v tématu Vynucení kvót prostředků.

Nastavení požadavků a omezení podů: Nastavení požadavků a omezení umožňuje Kubernetes efektivně přidělovat podům prostředky procesoru a paměti a umožňuje vyšší hustotu kontejnerů na uzlu. Požadavky a limity také můžou zvýšit spolehlivost a zároveň snížit náklady z důvodu lepšího využití hardwaru.

Pokud chcete odhadnout limity pro úlohu, otestujte a nastavte směrný plán. Začněte se stejnými hodnotami pro požadavky a limity. Potom postupně tyto hodnoty vylaďte, dokud nenavážete prahovou hodnotu, která může způsobit nestabilitu v clusteru.

V manifestech nasazení můžete zadat požadavky a omezení. Další informace najdete v tématu Nastavení požadavků a omezení podů.

Zóny dostupnosti a podpora více oblastí

Pokud chcete chránit před určitými typy výpadků, použijte zóny dostupnosti, pokud je oblast podporuje. Komponenty řídicí roviny i uzly ve fondech uzlů se pak můžou rozprostřet mezi zóny. Pokud není k dispozici celá zóna, je uzel v jiné zóně v dané oblasti stále dostupný. Každý fond uzlů se mapuje na samostatnou škálovací sadu virtuálních počítačů, která spravuje instance uzlů a škálovatelnost. Služba AKS spravuje operace a konfiguraci škálovací sady. Tady je několik důležitých aspektů, když povolíte více zón:

• Celá infrastruktura: Zvolte oblast, která podporuje zóny dostupnosti. Další informace najdete v tématu Omezení. Pokud chcete mít smlouvu SLA o provozu, musíte zvolit úroveň Standard nebo Premium. Smlouva SLA o provozu je při použití zón dostupnosti vyšší.

• Cluster: Zóny dostupnosti můžete nastavit pouze při vytváření fondu uzlů. Později je nejde změnit. Velikostiuzlůch Základní škálovací sada virtuálních počítačů poskytuje stejnou konfiguraci hardwaru napříč zónami.

  Podpora více zón platí nejen pro fondy uzlů, ale také řídicí rovinu. Řídicí rovina AKS zahrnuje požadované zóny, jako jsou fondy uzlů. Pokud v clusteru nepoužíváte podporu zón, není zaručeno, že se komponenty řídicí roviny rozdělí mezi zóny dostupnosti.

• Závislé prostředky: Pro kompletní zónovou výhodu musí všechny závislosti služby podporovat také zóny. Pokud závislá služba nepodporuje zóny, je možné, že selhání zóny může způsobit selhání této služby.

  Spravovaný disk je například k dispozici v zóně, ve které byl zřízen. Pokud dojde k selhání, může se uzel přesunout do jiné zóny, ale spravovaný disk se nepřesune s tímto uzlem do této zóny.

Kvůli jednoduchosti v této architektuře se AKS nasadí do jedné oblasti s fondy uzlů, které zahrnují zóny dostupnosti jedna, dvě a tři. Další prostředky infrastruktury, jako je Azure Firewall a Application Gateway, se také nasazují do stejné oblasti s podporou více zón. Pro Container Registry je povolená geografická replikace.

Několik oblastí

Když povolíte zóny dostupnosti, není to dostatek pokrytí v nepravděpodobné události, že selže celá oblast. Pokud chcete získat vyšší dostupnost, spusťte více clusterů AKS v různých oblastech.

• Preferujte spárované oblasti , pokud jsou k dispozici. Výhodou použití spárovaných oblastí je spolehlivost během aktualizací platformy. Azure zajišťuje, aby se najednou aktualizovala pouze jedna oblast v páru. Některé oblasti nemají páry. Pokud vaše oblast není spárovaná, můžete stále nasadit řešení s více oblastmi výběrem jiných oblastí, které chcete použít. Zvažte použití kanálu kontinuální integrace a průběžného doručování (CI/CD), který nakonfigurujete pro orchestraci obnovení z selhání oblasti. Některé nástroje DevOps, jako je Flux, můžou usnadnit nasazení ve více oblastech.

• Zadejte umístění, kde má redundantní služba sekundární instanci, pokud prostředek Azure podporuje geografickou redundanci. Například povolením geografické replikace pro Container Registry automaticky replikuje image do vybraných oblastí Azure. Poskytuje také nepřetržitý přístup k imagím, i když dojde k výpadku primární oblasti.

• V závislosti na vašem požadavku zvolte směrovač provozu, který může distribuovat provoz napříč zónami nebo oblastmi. Tato architektura nasadí Load Balancer, protože dokáže distribuovat provoz mimo web mezi zóny. Pokud potřebujete distribuovat provoz napříč oblastmi, zvažte Azure Front Door. Další možnosti najdete v tématu Volba nástroje pro vyrovnávání zatížení.

Zotavení po havárii

Pokud dojde k selhání v primární oblasti, v ideálním případě můžete rychle vytvořit novou instanci v jiné oblasti. Tady je několik doporučení:

• Použijte více oblastí. Pokud má primární oblast spárovanou oblast, použijte tuto dvojici. Pokud ne, vyberte oblasti na základě požadavků na rezidenci dat a latenci.

• Použijte nestátní úlohu, kterou můžete efektivně replikovat. Pokud potřebujete uložit stav v clusteru, který nedoporučujeme, nezapomeňte zálohovat data často v jiné oblasti.

• Integrujte strategii obnovení, jako je replikace do jiné oblasti, jako součást kanálu DevOps, abyste splnili cíl úrovně služby( SLO).

• Zřiďte každou službu Azure pomocí funkcí, které podporují zotavení po havárii. Například v této architektuře je služba Container Registry povolená pro geografickou replikaci. Pokud se oblast nezdaří, můžete i nadále načíst image z replikované oblasti.

• Nasaďte infrastrukturu jako kód, včetně clusteru AKS a všech dalších komponent, které potřebujete. Pokud potřebujete nasazení do jiné oblasti, můžete znovu použít skripty nebo šablony a vytvořit identickou instanci.

Zálohování clusteru

V případě mnoha architektur můžete zřídit nový cluster a vrátit ho do provozního stavu prostřednictvím spouštění clusteru založeného na operacích Gitu a následně nasazení aplikace. Pokud je ale kritický stav prostředků, jako jsou mapy konfigurace, úlohy a tajné kódy, které nejde zachytit v rámci procesu spouštění, zvažte strategii obnovení. Doporučujeme spouštět bezstavové úlohy v Kubernetes. Pokud vaše architektura zahrnuje stav založený na disku, musíte také zvážit strategii obnovení pro daný obsah.

Pokud zálohování clusteru musí být součástí strategie obnovení, musíte nainstalovat řešení, které odpovídá vašim obchodním požadavkům v rámci clusteru. Tento agent zodpovídá za odesílání stavu prostředků clusteru do cíle podle vašeho výběru a koordinace snímků trvalých svazků Azure založených na disku.

Příkladem běžného řešení zálohování Kubernetes, které můžete nainstalovat a spravovat přímo, je VMware Velero . Nebo můžete použít rozšíření zálohování AKS k poskytnutí spravované implementace Velero. Rozšíření zálohování AKS podporuje zálohování prostředků Kubernetes i trvalých svazků s plány a rozsahem zálohování externalizovaným jako konfigurace trezoru ve službě Azure Backup.

Referenční implementace neimplementuje zálohování, což zahrnuje další prostředky Azure ke správě, monitorování, nákupu a zabezpečení. Tyto prostředky můžou zahrnovat účet služby Azure Storage, trezor a konfiguraci služby Azure Backup a funkci důvěryhodného přístupu. Místo toho jsou operace Gitu kombinované se záměrem spouštět bezstavové úlohy řešení pro obnovení.

Vyberte a ověřte řešení zálohování, které splňuje váš obchodní cíl, včetně definovaného cíle bodu obnovení a cíle doby obnovení. Definujte proces obnovení v týmovém runbooku a procvičte si ho pro všechny důležité obchodní úlohy.

Smlouva SLA serveru rozhraní API Kubernetes

AKS můžete použít jako bezplatnou službu, ale tato úroveň nenabízí finančně zajištěnou smlouvu SLA. Pokud chcete získat smlouvu SLA, musíte zvolit úroveň Standard. Doporučujeme, aby všechny produkční clustery používaly úroveň Standard. Zarezervujte úroveň Free pro předprodukční clustery a úroveň Premium pouze pro důležité úlohy . Když používáte zóny dostupnosti Azure, smlouva SLA serveru rozhraní Kubernetes API je vyšší. Fondy uzlů a další prostředky jsou pokryté vlastními smlouvami SLA. Další informace o konkrétních smlouvách SLA pro každou službu najdete ve sla pro online služby.

Kompromis

Existuje kompromis mezi náklady a dostupností pro nasazení architektury napříč zónami a zejména oblastmi. Některé funkce replikace, jako je geografická replikace ve službě Container Registry, jsou k dispozici v cenových úrovních Premium, což je dražší. U nasazení ve více oblastech se náklady také zvyšují, protože poplatky za šířku pásma se použijí při přesunu provozu mezi oblastmi.

Také můžete očekávat další latenci sítě při komunikaci mezi zónami nebo oblastmi uzlu. Změřte účinek tohoto rozhodnutí o architektuře na vaši úlohu.

Testování pomocí simulací a vynucených převzetí služeb při selhání

Otestujte spolehlivost vašeho řešení prostřednictvím vynuceného testování převzetí služeb při selhání se simulovanými výpadky. Simulace můžou zahrnovat zastavení uzlu, zastavení všech prostředků AKS v konkrétní zóně pro simulaci zónového selhání nebo vyvolání selhání externí závislosti. Azure Chaos Studio můžete také použít k simulaci různých typů výpadků v Azure a v clusteru.

Další informace naleznete v tématu Chaos Studio.

Monitorování a shromažďování metrik

Ke sledování výkonu úloh kontejnerů doporučujeme přehledy kontejnerů služby Azure Monitor, protože události můžete zobrazovat v reálném čase. Zaznamenává protokoly kontejneru ze spuštěných podů a agreguje je pro zobrazení. Shromažďuje také informace z rozhraní API metrik o využití paměti a procesoru za účelem monitorování stavu spuštěných prostředků a úloh. Přehledy kontejnerů můžete také použít k monitorování výkonu při škálování podů. Zahrnuje telemetrii, která je důležitá pro monitorování, analýzu a vizualizaci shromážděných dat. Container Insights identifikuje trendy a umožňuje nakonfigurovat upozorňování tak, aby dostávala proaktivní oznámení o kritických problémech.

Většina úloh hostovaných v podech generuje metriky Prometheus. Přehledy kontejnerů se můžou integrovat s Nástrojem Prometheus. Můžete zobrazit metriky aplikací a úloh shromážděné z uzlů a Kubernetes.

Některá řešení od jiných společností než Microsoft se integrují s Kubernetes, jako jsou Datadog, Grafana nebo New Relic. Takže pokud už vaše organizace tato řešení používá, můžete je využít.

V AKS spravuje Azure některé základní služby Kubernetes. Azure implementuje protokoly pro komponenty řídicí roviny AKS jako protokoly prostředků. Ve většině clusterů doporučujeme povolit následující možnosti. Možnosti vám můžou pomoct při řešení problémů s clusterem a mají relativně nízkou hustotu protokolů.

• ClusterAutoscaler: Získejte pozorovatelnost operací škálování pomocí protokolování. Další informace najdete v tématu Načtení protokolů a stavu automatického škálování clusteru.
• KubeControllerManager: Získejte pozorovatelnost v interakci mezi Kubernetes a řídicí rovinou Azure.
• kube-audit-admin: Získejte pozorovatelnost do aktivit, které upravují váš cluster. Není důvod, proč by se měly povolit i kube-audit kube-audit-admin obě. kube-audit je nadmnožina kube-audit-admin , která zahrnuje i nemodify (čtení) operací.
• guard: zachyťte audity Microsoft Entra ID a Azure RBAC.

Při vývoji počátečního clusteru nebo životního cyklu úloh může být užitečné povolit jiné kategorie protokolů, například KubeScheduler nebo kube-audit. Přidané automatické škálování clusteru, umístění podů a plánování a podobná data vám můžou pomoct při řešení potíží s provozem clusteru nebo úloh. Pokud ale po ukončení řešení potíží zachováte rozšířené protokoly řešení potíží na plný úvazek, může vám docházet k zbytečným nákladům na příjem a ukládání dat ve službě Azure Monitor.

I když Azure Monitor obsahuje sadu existujících dotazů protokolu, se kterými můžete začít, můžete je také použít jako základ k vytvoření vlastních dotazů. S rostoucím růstem knihovny můžete ukládat a opakovaně používat dotazy protokolu pomocí jednoho nebo více balíčků dotazů. Vaše vlastní knihovna dotazů poskytuje lepší pozorovatelnost stavu a výkonu clusterů AKS. Podporuje dosažení cílů úrovně služby.

Další informace o našich osvědčených postupech monitorování pro AKS najdete v tématu Monitorování AKS pomocí služby Azure Monitor.

Další informace o aspektech monitorování specifických pro Windows najdete v tématu Kontejnery Windows v AKS.

Metriky sítě

Základní metriky sítě na úrovni clusteru jsou dostupné prostřednictvím nativních metrik platformy a prometheus. Doplněk Sledování sítě můžete dále použít k zveřejnění síťových metrik na úrovni uzlu. Většina clusterů by měla používat doplněk Pozorovatelnost sítě k poskytování dalších možností řešení potíží se sítí a k detekci neočekávaného využití sítě nebo problémů na úrovni uzlu.

Pro úlohy, které jsou vysoce citlivé na ztrátu paketů TCP (Transmission Control Protocol) nebo UDP (User Datagram Protocol), latenci nebo tlak DNS, jsou důležité metriky sítě na úrovni podů. V AKS najdete tuto úroveň podrobností pomocí funkce Rozšířené pozorovatelnosti sítě. Většina úloh nevyžaduje tuto hloubku pozorovatelnosti sítě. Doplněk Advanced Network Observability byste neměli instalovat, pokud vaše pody nevyžadují vysoce optimalizovanou síť s citlivostí na úroveň paketů.

Povolení samoopravení

Monitorujte stav podů nastavením aktivního stavu a sond připravenosti. Pokud Kubernetes zjistí nereagující pod, restartuje pod. Sonda aktivity určuje, jestli je pod v pořádku. Pokud Kubernetes zjistí nereagující pod, restartuje pod. Sonda připravenosti určuje, jestli je pod připravený přijímat požadavky a provoz.

Rutinní aktualizace pro clustery AKS

Součástí každodenních operací pro clustery Kubernetes je provádění rutinních aktualizací platformy a operačního systému. V každém clusteru AKS existují tři vrstvy aktualizací, které je potřeba řešit:

• Verze Kubernetes (například Kubernetes 1.30.3 až 1.30.7 nebo Kubernetes 1.30.7 až 1.31.1), která může obsahovat změny a vyřazení rozhraní Kubernetes API. Změny verzí v této vrstvě ovlivňují celý cluster.
• Image virtuálního pevného disku (VHD) na každém uzlu, která kombinuje aktualizace operačního systému a aktualizace komponent AKS. Tyto aktualizace se testují na verzi Kubernetes clusteru. Změny verzí v této vrstvě se použijí na úrovni fondu uzlů a nemají vliv na verzi Kubernetes.
• Vlastní nativní proces aktualizace operačního systému, například služba Windows Update nebo apt. Dodavatel operačního systému tyto aktualizace dodává přímo a nejsou testovány na verzi Kubernetes clusteru. Změny verzí v této vrstvě mají vliv na jeden uzel a nemají vliv na verzi Kubernetes.

Každá z těchto vrstev je nezávisle řízena. Rozhodnete se, jak se jednotlivé vrstvy zpracovávají pro clustery úloh. Zvolte, jak často se každý cluster AKS, jeho fondy uzlů nebo jeho uzly aktualizuje (tempo). Vyberte také, které dny nebo časy mají aktualizace použít ( časové období údržby). Zvolte, jestli se aktualizace instalují ručně, nebo automaticky nebo ne. Stejně jako úloha, která běží na vašem clusteru, potřebuje bezpečný postup nasazení, a proto proveďte aktualizace clusterů.

Ucelený přehled o opravách a upgradu najdete v pokynech k opravám a upgradu AKS v provozní příručce AKS day-2. Následující informace použijte pro základní doporučení, která souvisejí s touto architekturou.

Neměnná infrastruktura

Úlohy, které provozují clustery AKS jako neměnnou infrastrukturu, se automaticky ani ručně neaktualizují jejich clustery. Nastavte upgrade image uzlu a none automatický upgrade clusteru na none. V této konfiguraci zodpovídáte výhradně za všechny upgrady ve všech vrstvách. Jakmile bude dostupná požadovaná aktualizace, musíte ji otestovat v předprodukčním prostředí a vyhodnotit její kompatibilitu v novém clusteru. Potom nasaďte razítko produkční repliky, které zahrnuje aktualizované virtuální pevné disky ve verzi AKS a fondu uzlů. Až bude nový produkční cluster připravený, vyprázdní se starý cluster a nakonec se vyřadí z provozu.

Neměnná infrastruktura s pravidelným nasazením nové infrastruktury je jediná situace, ve které by produkční cluster neměl mít nasazenou místní strategii upgradu. Všechny ostatní clustery by měly mít místní strategii upgradu.

Místní upgrady

Úlohy, které nepracují s clustery AKS jako neměnnou infrastrukturou, by měly pravidelně aktualizovat spuštěné clustery, aby řešily všechny tři vrstvy. Přirovnejte proces aktualizace k požadavkům vaší úlohy. Jako výchozí bod návrhu procesu rutinní aktualizace použijte následující doporučení.

• Naplánujte funkci plánované údržby AKS, abyste mohli řídit upgrady v clusteru. Tato funkce umožňuje provádět aktualizace, což je ze své podstaty riziková operace, a snížit tak účinek neočekávaného selhání.
• Nakonfigurujte rozpočty přerušení podů tak, aby vaše aplikace při postupném upgradu zůstala stabilní. Ale nekonfigurujte rozpočty tak agresivní, že blokují upgrady uzlů, protože většina upgradů vyžaduje proces cordonu a vyprázdnění na každém uzlu.
• Potvrďte kvótu prostředků Azure a dostupnost prostředků. Místní upgrady nasazují nové instance uzlů, označované jako přepětí uzlů, před odebráním starých uzlů. To znamená, že pro nové uzly musí být k dispozici kvóta Azure a adresní prostor IP adres. Hodnota nárůstu 33 % je dobrým výchozím bodem pro většinu úloh.
• Otestujte kompatibilitu s nástroji, jako jsou sítě služeb nebo agenti zabezpečení, které jste přidali do clusteru. A otestujte komponenty úloh, jako jsou kontrolery příchozího přenosu dat, sítě služeb a pody úloh. Proveďte testy v předprodukčním prostředí.

Místní upgrady pro uzly

Pro upgrady imagí operačního systému uzlu použijte kanál automatického NodeImage upgradu. Tento kanál nakonfiguruje cluster tak, aby aktualizoval virtuální pevný disk na každém uzlu pomocí aktualizací na úrovni uzlu. Microsoft otestuje aktualizace na vaší verzi AKS. U uzlů Windows dochází k aktualizacím přibližně jednou za měsíc. U linuxových uzlů k těmto aktualizacím dochází přibližně jednou týdně.

• Upgrady nikdy nemění vaši verzi AKS ani Kubernetes, takže není problém s kompatibilitou rozhraní API Kubernetes.
• Když použijete NodeImage kanál upgradu, bude respektovat časové období plánované údržby, které byste měli nastavit alespoň jednou týdně. Nastavte ji bez ohledu na to, jakou bitovou kopii uzlu používáte, abyste zajistili včasnou aplikaci.
• Mezi tyto aktualizace patří zabezpečení na úrovni operačního systému, kompatibilita a funkční aktualizace, nastavení konfigurace operačního systému a aktualizace komponent AKS.
• Verze imagí a jejich zahrnutá čísla verzí součástí se sledují pomocí sledování verzí AKS.

Pokud požadavky na zabezpečení pro váš cluster vyžadují agresivnější četnost oprav a váš cluster může tolerovat potenciální přerušení, použijte SecurityPatch místo toho kanál upgradu. Microsoft tyto aktualizace také testuje. Aktualizace se publikují pouze v případě, že existují upgrady zabezpečení, které Microsoft považuje za důležité k vydání před dalším plánovaným upgradem image uzlu. Když kanál používáte SecurityPatch , získáte také aktualizace, které NodeImage kanál přijal. Možnost SecurityPatch kanálu stále respektuje časové intervaly údržby, proto se ujistěte, že časové období údržby má častější mezery (například každý den nebo každý druhý den), které podporují tyto neočekávané aktualizace zabezpečení.

Většina clusterů, které provádí místní upgrady, by se měla vyhnout možnostem None kanálu upgradu image uzlu.Unmanaged

Místní aktualizace clusteru

Kubernetes je rychle se vyvíjející platforma a pravidelné aktualizace přinášejí důležité opravy zabezpečení a nové funkce. Je důležité, abyste zůstali aktuální s aktualizacemi Kubernetes. Měli byste zůstat ve dvou nejnovějších verzích nebo N-2. Je důležité upgradovat na nejnovější verzi Kubernetes, protože se často vydávají nové verze.

Většina clusterů by měla být schopná provádět místní aktualizace verzí AKS s dostatečným opatrností a rigorií. Riziko provedení místního upgradu verze AKS je většinou možné zmírnit prostřednictvím dostatečného předprodukčního testování, ověření kvóty a konfigurace rozpočtu podů. Jakýkoli místní upgrade ale může vést k neočekávanému chování. Pokud jsou místní upgrady pro vaši úlohu považovány za příliš rizikové, doporučujeme místo zbývajících doporučení použít modré zelené nasazení clusterů AKS.

Doporučujeme, abyste se při prvním nasazení clusteru Kubernetes vyhnuli funkci automatického upgradu clusteru. Použijte ruční přístup, který vám poskytne čas otestovat novou verzi clusteru AKS ve vašich předprodukčních prostředích před tím, než aktualizace dorazí do produkčního prostředí. Tento přístup také dosahuje nejvyšší úrovně předvídatelnosti a kontroly. Musíte ale pečlivě sledovat nové aktualizace platformy Kubernetes a rychle přijímat nové verze při jejich vydání. Lepší je přijmout "aktuální" myšlení v dlouhodobém přístupu podpory .

Pokud je pro váš cluster dostupná nová verze AKS, můžete dostávat oznámení pomocí systémového tématu AKS pro Azure Event Grid. Referenční implementace nasadí toto téma systému Event Grid, abyste se mohli přihlásit k odběru události z řešení oznámení streamu Microsoft.ContainerService.NewKubernetesVersionAvailable událostí. Projděte si poznámky k verzi AKS, kde najdete konkrétní problémy s kompatibilitou, změny chování nebo vyřazení funkcí.

Nakonec můžete dosáhnout bodu spolehlivosti s verzemi Kubernetes, verzemi AKS, clusterem, jeho komponentami na úrovni clusteru a úlohou a prozkoumat funkci automatického upgradu. V případě produkčních systémů by bylo vzácné, že by se nikdy nepřesunulo .patch Při automatickém upgradu verze AKS také zkontrolujte nastavení verze AKS pro váš cluster jako nastavení verze AKS (IaC) infrastruktury jako kódu, aby se nesynchronizují. Nakonfigurujte časové období plánované údržby tak, aby podporovalo operaci automatického upgradu.

Monitorování zabezpečení

Monitorujte infrastrukturu kontejneru pro aktivní hrozby i potenciální bezpečnostní rizika. Tady jsou některé zdroje informací:

• Microsoft Defender for Containers k identifikaci a nápravě doporučení defenderu pro cloud pro vaše image kontejnerů
• Defender for Containers pravidelně kontroluje ohrožení zabezpečení imagí kontejnerů.
• Defender for Containers také generuje výstrahy zabezpečení v reálném čase pro podezřelé aktivity.
• Koncepty zabezpečení AKS pro aplikace a clustery podrobně popisuje, jak zabezpečení kontejnerů chrání celý kompletní kanál před sestavením a úlohami aplikací běžícími v AKS.

Provoz clusteru a úloh

Aspekty operací clusteru a úloh (DevOps) najdete v pilíři principů návrhu efektivity provozu.

Spouštění clusteru

Po zřízení máte funkční cluster, ale před nasazením úloh můžete mít ještě několik požadovaných kroků. Proces přípravy clusteru se nazývá bootstrapping. Spouštění se může skládat z nasazení požadovaných imagí na uzly clusteru, vytváření oborů názvů a provádění dalších úloh, které splňují požadavky případu použití vaší organizace.

Aby se snížila mezera mezi zřízeným clusterem a správně nakonfigurovaným clusterem, měli by operátoři clusteru uvažovat o tom, jak vypadá jejich jedinečný proces spouštění. Musí předem připravit relevantní prostředky. Pokud je například důležité mít před nasazením úloh aplikace spuštěné kured na každém uzlu, operátor clusteru by měl ověřit, že instance služby Container Registry, která obsahuje cílovou image Kured, již existuje před zřízením clusteru.

Proces spouštění můžete nakonfigurovat pomocí jedné z následujících metod:

• Rozšíření clusteru GitOps Flux v2
• Pipelines
• Self-configuration with Flux or Argo CD, například

Jednou z hlavních výhod použití rozšíření clusteru Flux v2 GitOps pro AKS je, že mezi zřízeným clusterem a spouštěcím clusterem není v podstatě žádná mezera. Nastaví prostředí s pevným základem správy, který bude dále podporovat i to, že bootstrapping jako šablony prostředků bude v souladu s vaší strategií IaC.

Při použití rozšíření se kubectl nevyžaduje pro žádnou část procesu bootstrappingu. Přístup založený na kubectl si můžete rezervovat pro situace, které řeší tísňové tísňové opravy. Mezi šablonami pro definice prostředků Azure a spouštěním manifestů prostřednictvím rozšíření GitOps můžete provádět všechny běžné konfigurační aktivity bez nutnosti používat kubectl.

Izolace odpovědností za úlohy

Rozdělte úlohy týmy a typy prostředků tak, aby jednotlivé části spravily jednotlivě.

Začněte se základní úlohou, která obsahuje základní komponenty, a vytvořte je na něm. Počáteční úlohou je konfigurace sítí. Zřiďte virtuální sítě pro centra a paprsky a také podsítě v těchto sítích. Paprsk má například samostatné podsítě pro fondy systémových a uživatelských uzlů a prostředky příchozího přenosu dat. Nasaďte podsíť pro Azure Firewall v centru.

Dalším úkolem je integrovat základní úlohu s ID Microsoft Entra.

Použití IaC

Zvolte idempotentní deklarativní metodu nad imperativním přístupem, pokud je to možné. Místo psaní posloupnosti příkazů, které určují možnosti konfigurace, použijte deklarativní syntaxi, která popisuje prostředky a jejich vlastnosti. Můžete použít Bicep, šablony Azure Resource Manageru (šablony ARM) nebo Terraform.

Nezapomeňte zřídit prostředky podle zásad řízení. Když například vyberete velikosti virtuálních počítačů, zůstaňte v rámci omezení nákladů a možností zóny dostupnosti, aby odpovídaly požadavkům vaší aplikace. Azure Policy můžete také použít k vynucování zásad vaší organizace pro tato rozhodnutí.

Pokud potřebujete napsat posloupnost příkazů, použijte Azure CLI. Tyto příkazy pokrývají celou řadu služeb Azure a můžete je automatizovat prostřednictvím skriptování. Azure CLI podporuje Windows a Linux. Další možností pro různé platformy je Azure PowerShell. Vaše volba závisí na preferované sadě dovedností.

Uložte a zpřístupněte skripty a soubory šablon v systému správy zdrojového kódu.

CI/CD úloh

Kanály pro pracovní postup a nasazení musí být schopné nepřetržitě sestavovat a nasazovat aplikace. Aktualizace se musí bezpečně a rychle nasadit a vrátit zpět v případě, že dojde k problémům.

Vaše strategie nasazení musí zahrnovat spolehlivý a automatizovaný kanál průběžného doručování. Automaticky nasaďte změny imagí kontejneru úloh do clusteru.

V této architektuře gitHub Actions spravuje pracovní postup a nasazení. Mezi další oblíbené možnosti patří Azure DevOps a Jenkins.

CI/CD clusteru

Stáhněte si soubor aplikace Visio s touto architekturou.

Místo použití imperativního přístupu, jako je kubectl, použijte nástroje, které automaticky synchronizují změny clusteru a úložiště. Pokud chcete spravovat pracovní postup, například vydání nové verze a ověření této verze před nasazením do produkčního prostředí, zvažte tok GitOps.

Základní součástí toku CI/CD je spuštění nově zřízeného clusteru. Přístup GitOps je užitečný, protože operátory umožňují deklarativně definovat proces spouštění jako součást strategie IaC a automaticky zobrazit konfiguraci v clusteru.

Při použití GitOps se v clusteru nasadí agent, aby se zajistilo, že stav clusteru je koordinovaný s konfigurací uloženou v privátním úložišti Git. Jedním z těchto agentů je flux, který používá jeden nebo více operátorů v clusteru k aktivaci nasazení v Kubernetes. Flux dělá tyto úlohy:

• Monitoruje všechna nakonfigurovaná úložiště.
• Detekuje nové změny konfigurace.
• Aktivuje nasazení.
• Aktualizuje požadovanou spuštěnou konfiguraci na základě těchto změn.

Můžete také nastavit zásady, které určují způsob nasazení změn.

Tady je příklad, který ukazuje, jak automatizovat konfiguraci clusteru pomocí GitOps a Fluxu:

Stáhněte si soubor aplikace Visio s touto architekturou.

1. Vývojář potvrdí změny zdrojového kódu, jako jsou konfigurační soubory YAML, které jsou uložené v úložišti Git. Změny se pak nasdílí na server Gitu.

2. Flux běží v podu společně s úlohou. Flux má k úložišti Git přístup jen pro čtení, aby se zajistilo, že Flux používá změny jenom podle požadavků vývojářů.

3. Flux rozpozná změny v konfiguraci a tyto změny použije pomocí příkazů kubectl.

4. Vývojáři nemají přímý přístup k rozhraní Kubernetes API prostřednictvím kubectl.

Na serveru Git můžete mít zásady větví, aby několik vývojářů pak mohlo schválit změny prostřednictvím žádosti o přijetí změn, než se změna použije v produkčním prostředí.

I když můžete GitOps a Flux nakonfigurovat ručně, doporučujeme GitOps s rozšířením clusteru Flux v2 pro AKS.

Strategie nasazení úloh a clusteru

Nasaďte všechny změny, jako jsou komponenty architektury, úlohy a konfigurace clusteru, do alespoň jednoho předprodukčního clusteru AKS. Tím simulovat změnu a může identifikovat problémy před jejich nasazením do produkčního prostředí.

Než přejdete k dalšímu kroku, spusťte testy a ověřování v každé fázi. Pomáhá zajistit, abyste mohli odesílat aktualizace do produkčního prostředí vysoce kontrolovaným způsobem a minimalizovat přerušení před neočekáženými problémy s nasazením. Nasazení by mělo dodržovat podobný model jako v produkčním prostředí pomocí stejného kanálu GitHub Actions nebo operátorů Flux.

Pokročilé techniky nasazení, jako je modré zelené nasazení, testování A/B a kanárské verze, vyžadují další procesy a potenciálně další nástroje. Flagger je oblíbené opensourcové řešení, které pomáhá řešit pokročilé scénáře nasazení.

Správa nákladů

Začněte kontrolou kontrolního seznamu návrhu optimalizace nákladů a seznamem doporučení uvedených v dobře architektuře pro AKS. Pomocí cenové kalkulačky Azure můžete odhadnout náklady na služby, které používáte v architektuře. Další osvědčené postupy najdete v tématu Optimalizace nákladů.

Zvažte použití analýzy nákladů AKS pro podrobné přidělování nákladů na infrastrukturu clusteru podle konstruktorů specifických pro Kubernetes.

Informace o aspektech správy nákladů specifických pro Windows najdete v tématu Kontejnery Windows v AKS.

Zřízení

• Zjistěte, odkud vaše náklady pocházejí. V nasazení, správě a provozu samotného clusteru Kubernetes existují minimální náklady spojené s AKS. Co ovlivňuje náklady, jsou instance virtuálních počítačů, úložiště, data protokolů a síťové prostředky spotřebované clusterem. Zvažte výběr levnějších virtuálních počítačů pro fondy systémových uzlů. Řada DS2_v2 je typickým typem virtuálního počítače pro fond systémových uzlů.

• Nemá stejnou konfiguraci pro vývoj/testování a produkční prostředí. Produkční úlohy mají dodatečné požadavky na vysokou dostupnost a obvykle jsou dražší. Tato konfigurace není nutná v vývojovém/testovacím prostředí.

• Přidejte smlouvu SLA o provozuschopnosti pro produkční úlohy. Existují ale úspory pro clustery navržené pro vývoj/testování nebo experimentální úlohy, u kterých není potřeba zaručit dostupnost. Cíl úrovně služeb je například dostatečný. Pokud ji vaše úloha podporuje, zvažte také použití vyhrazených fondů spotových uzlů, které spouštějí spotové virtuální počítače.

  U neprodukčních úloh, které zahrnují Azure SQL Database nebo službu Aplikace Azure Service jako součást architektury úloh AKS, vyhodnoťte, jestli máte nárok používat předplatná Azure Pro vývoj/testování k získání slev za služby.

• Zřiďte cluster s minimálním počtemuzlůchm systémem a povolte automatické škálování clusteru, aby mohl monitorovat a provádět rozhodnutí o velikosti místo toho, aby začínal s nadlimitovaným clusterem, aby vyhovoval potřebám škálování.

• Nastavte požadavky a omezení podů tak, aby Kubernetes přiděloval prostředky uzlů s vyšší hustotou, abyste k kapacitě použili hardware.

• Vezměte v úvahu, že když povolíte diagnostiku v clusteru, může zvýšit náklady.

• Pokud chcete snížit náklady na uzly v případě, že vaše úloha musí existovat po dlouhou dobu, zavážete se k jednoleté nebo tříleté instanci rezervovaných virtuálních počítačů Azure. Další informace najdete v tématu Úspora nákladů s využitím rezervovaných instancí virtuálních počítačů Azure.

• Při vytváření fondů uzlů používejte značky. Značky pomáhají při vytváření vlastních sestav ke sledování skutečných nákladů. Značky můžete použít ke sledování celkových výdajů a mapování jakýchkoli nákladů na konkrétní zdroj nebo tým. Pokud je cluster sdílený mezi týmy, sestavte sestavy zpětného účtování na příjemce a identifikujte měřené náklady pro sdílené cloudové služby. Další informace najdete v tématu Určení taintu, popisku nebo značky pro fond uzlů.

• Pokud je vaše úloha více oblastí a replikujete data mezi oblastmi, počítejte s dalšími náklady na šířku pásma. Další informace najdete v tématu Ceny šířky pásma.

• Vytvářejte rozpočty, abyste zůstali v mezích nákladových omezení, která vaše organizace identifikuje. Rozpočty můžete vytvářet prostřednictvím služby Microsoft Cost Management. Můžete také vytvořit upozornění, která budou dostávat oznámení při překročení určitých prahových hodnot. Další informace najdete v tématu Vytvoření rozpočtu pomocí šablony.

Monitor

Můžete monitorovat celý cluster a náklady na výpočetní prostředky, úložiště, šířku pásma, protokoly a bránu firewall. Azure nabízí možnosti monitorování a analýzy nákladů:

• Azure Advisor

• Microsoft Cost Management

V ideálním případě můžete náklady monitorovat v reálném čase nebo alespoň v pravidelných intervalech. Potom můžete provést akci před koncem měsíce, když se náklady už vypočítají. Sledujte také měsíční trendy v průběhu času, abyste zůstali v rozpočtu.

Pokud chcete učinit rozhodnutí řízená daty, nastavte, který prostředek na podrobné úrovni má největší náklady. Také dobře rozumí měřiči, které počítají využití prostředků. Analýzou metrik můžete například určit, jestli je platforma překládaná. Měřiče využití můžete zobrazit v metrikách služby Azure Monitor.

Optimalizovat

Reagovat na doporučení poskytovaná azure Advisorem Existují další způsoby optimalizace:

• Povolte automatické škálování clusteru, aby rozpoznal a odebral nevyužité uzly ve fondu uzlů.

  Důležité

  Agresivní změna nastavení automatického škálování clusteru, jako je minimální a maximální nastavení uzlů pro fond uzlů, aby ovlivnila náklady, můžou mít neproduktivní výsledky. Pokud scale-down-unneeded-time je například nastavená hodnota 10 minut a minimální a maximální nastavení uzlu se upraví každých pět minut na základě charakteristik úloh, počet uzlů se nikdy nezmenšuje. Důvodem je to, že výpočet nepotřebného času pro každý uzel se resetuje kvůli aktualizaci nastavení automatického škálování clusteru.

• Zvolte nižší skladovou položku pro fondy uzlů, pokud ji vaše úloha podporuje.

• Pokud aplikace nevyžaduje škálování s nárůstem kapacity, zvažte změnu velikosti clusteru na správnou velikost tím, že v průběhu času analyzujete metriky výkonu.

• Pokud to vaše úloha podporuje, škálujte fondy uzlů uživatelů na 0 uzlů , pokud neočekáváte, že budou spuštěné. Pokud v clusteru nejsou naplánované žádné úlohy, zvažte použití funkce spuštění/zastavení AKS k vypnutí všech výpočetních prostředků, včetně fondu systémových uzlů a řídicí roviny AKS.

Další informace související s náklady najdete v tématu Ceny AKS.

Další kroky

• Architektura pokročilých mikroslužeb AKS
• Standardní hodnoty AKS pro clustery s více oblastmi
• Regulovaný cluster AKS pro PCI-DSS 3.2.1
• Kontejnery Windows v referenční architektuře standardních hodnot AKS

Související prostředky

• Plán AKS na GitHubu
• Úvod do Kubernetes
• Vývoj a nasazování aplikací v Kubernetes
• Well-Architected Framework recenze pro AKS
• Akcelerátor cílové zóny AKS
• Provozní průvodce AKS 2. den
• Architektura mikroslužeb v AKS
• Použití služby Azure Firewall k ochraně clusteru AKS
• Operace Gitu pro AKS
• Streamování dat pomocí AKS