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

Tato referenční architektura poskytuje doporučenou základní architekturu infrastruktury pro nasazení clusteru Azure Kubernetes Service (AKS) v Azure. Používá naše principy návrhu a je založen na našich osvědčených postupech architektury z architektury Azure Well-Architected Framework , aby se prostřednictvím nasazení této infrastruktury pro obecné účely nasazovala in interně nebo několik různých týmů, jako jsou sítě, zabezpečení a identita.

Tato architektura se nezaměřuje na úlohu, ale soustředí se na samotný cluster AKS. Zde uvedené informace jsou minimálním doporučeným směrný plán pro většinu clusterů AKS. Integruje se se službami Azure, které poskytují pozorovatelnost, síťovou topologii, která podporuje víceregionální růst, a zabezpečuje provoz v clusteru.

Cílová architektura je ovlivněná vašimi obchodními požadavky a v důsledku toho se může lišit mezi různými kontexty aplikace. Měli byste ho považovat za výchozí bod pro předprodukční a produkční fáze.

Implementace této architektury je dostupná také na GitHubu: Referenční implementace standardních hodnot služby Azure Kubernetes Service (AKS). Můžete ho použít jako alternativní výchozí bod a nakonfigurovat ho podle svých 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. Rozbočovače a paprsky se nasazují v samostatných virtuálních sítích připojených prostřednictvím partnerského vztahu. Mezi výhody této topologie patří:

• Oddělení správy. Umožňuje způsob použití zásad správného řízení a dodržování principu nejnižších oprávnění. Podporuje také koncept cílové zóny Azure s oddělením povinností.

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

• Organizace často pracují s topologií hvězdicové oblasti. Hvězdicové síťové topologie je možné v budoucnu rozšířit a zajistit izolaci úloh.

• Všechny webové aplikace by měly vyžadovat službu firewallu webových aplikací (WAF), která pomáhá řídit tok provozu HTTP.

• Přirozená volba pro úlohy, které pokrývají více předplatných.

• Díky tomu je architektura rozšiřitelná. Aby bylo možné vyhovět novým funkcím nebo úlohám, je možné přidat nové paprsky místo toho, aby se přepracovával topologie sítě.

• Některé prostředky, jako je brána firewall a DNS, se dají sdílet napříč sítěmi.

• Odpovídá cílovým zónám 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.

Pokud chcete zkontrolovat změny návrhu sítě zahrnuté v kontejnerech Windows v referenční architektuře standardních hodnot AKS, přečtěte si doprovodný článek.

Centrum

Centrální virtuální síť je centrálním bodem připojení a pozorovatelnosti. Centrum vždy obsahuje bránu Azure Firewall s globálními zásadami brány firewall definovanými centrálními IT týmy, které vynucují zásady brány firewall pro celou organizaci, Azure Bastion, podsíť brány pro připojení VPN a Azure Monitor pro pozorovatelnost sítě.

V síti se nasadí tři podsítě.

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

Azure Firewall je brána firewall jako služba. Instance brány firewall zabezpečuje odchozí síťový provoz. Bez této vrstvy zabezpečení může tento provoz komunikovat se zlými službami třetích stran, které by mohly exfiltrovat citlivá firemní data. Azure Firewall Manager umožňuje centrálně nasazovat a konfigurovat více instancí služby Azure Firewall a spravovat 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 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. Bastion můžete použít k bezpečnému přístupu k prostředkům Azure bez vystavení prostředků na internetu. Tato podsíť se používá pouze pro správu a operace.

Mluvil

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

Podsíť pro hostování brány Aplikace Azure

Azure 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 firewall webových aplikací (WAF). WAF zabezpečuje příchozí provoz před běžnými webovými útoky, včetně robotů. Instance má konfiguraci veřejné 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ý bude plnit 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í se službou Azure Kubernetes Service (AKS).

Podsíť pro hostování uzlů clusteru

AKS udržuje dvě samostatné skupiny uzlů (nebo fondů 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 Private Link

Pro Azure Container Registry a Azure Key Vault se vytvoří připojení Azure Private Link, takže k těmto službám je možné přistupovat pomocí privátního koncového bodu v rámci paprskové virtuální sítě. Privátní koncové body nevyžadují vyhrazenou podsíť a dají se také umístit do virtuální sítě centra. V základní implementaci se nasadí do vyhrazené podsítě v rámci paprskové virtuální sítě. Tento přístup snižuje přenosy předávající připojení k partnerské síti, udržuje prostředky, které patří do clusteru ve stejné virtuální síti, a umožňuje použít podrobná pravidla zabezpečení na úrovni podsítě pomocí skupin zabezpečení sí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.

Adresní prostor virtuální sítě by měl být dostatečně velký, aby mohl obsahovat všechny podsítě. Účet pro všechny entity, které budou přijímat provoz. IP adresy těchto entit budou přiděleny z adresního prostoru podsítě. Zvažte tyto body.

• Upgrade

  Uzly 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 opravách systému. 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.

  U podů můžete potřebovat další adresy v závislosti na vaší strategii. U kumulativních aktualizací budete potřebovat adresy dočasných podů, které spouští úlohu při aktualizaci skutečných podů. Pokud použijete strategii nahrazení, odeberou se pody a vytvoří se nové. Adresy přidružené ke starým podům se proto znovu používají.

• Škálovatelnost

  Vezměte v úvahu počet uzlů všech systémových a uživatelských uzlů a limit maximální škálovatelnosti. Předpokládejme, že chcete vertikálně na více instancí snížit kapacitu o 400 %. Budete potřebovat čtyřikrát počet adres pro všechny tyto uzly se škálováním na více instancí.

  V této architektuře je možné kontaktovat každý pod přímo. Každý pod tedy potřebuje individuální adresu. Škálovatelnost podů ovlivní výpočet adresy. Toto rozhodnutí bude záviset na vašem výběru ohledně počtu podů, které chcete zvětšit.

• Adresy Služby Azure Private Link

  Factor in the addresses that are required for communication with other Azure services over Private Link. V této architektuře máme k propojením se službou Azure Container Registry a Key Vault přiřazené dvě adresy.

• Některé adresy jsou vyhrazené pro použití v Azure. Nelze jim přiřadit.

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

Tato architektura je navržená pro jednu úlohu. U více úloh můžete chtít izolovat fondy uzlů uživatele od sebe a od fondu systémových uzlů. Výsledkem této volby je 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.

Kompletní sadu aspektů pro tuto architekturu najdete v tématu Základní topologie sítě AKS.

Informace týkající se plánování IP adresy pro cluster AKS najdete v tématu Plánování přidělování IP adres pro váš cluster.

Informace o plánování IP adres zahrnutých v kontejnerech Windows v referenční architektuře standardních hodnot AKS najdete v doprovodném článku.

Doplňky a funkce ve verzi Preview

Kubernetes a AKS se neustále vyvíjejí produkty 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. Rozdíl mezi těmito dvěma je následující:

• Tým AKS popisuje funkce ve verzi Preview, které se dodávají a vylepšují. Důvodem je to, že mnoho funkcí ve verzi Preview zůstává v daném stavu jen několik měsíců před přechodem do fáze obecné verze (GA).
• Doplňky a rozšíření AKS poskytují další podporované funkce. Jejich instalace, konfigurace a životní cyklus spravuje AKS.

Tato základní architektura nezahrnuje každou funkci preview nebo doplněk, místo toho jsou zahrnuté pouze ty, které do clusteru pro obecné účely přidávají významnou hodnotu. Vzhledem k tomu, že tyto funkce pocházejí z verze Preview, bude tato základní architektura odpovídajícím způsobem revidována. V předprodukčních clusterech můžete chtít vyhodnotit některé další funkce preview nebo doplňky AKS, které rozšiřují zabezpečení, spravovatelnost nebo jiné požadavky. U doplňků třetích stran je potřeba 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. Při načítání těchto bodů do clusteru vezměte v úvahu tyto body.

• Cluster se ověří za účelem vyžádání image.

• Pokud používáte veřejnou image, zvažte její import do registru kontejneru, který odpovídá vašemu SLO. Jinak může na image docházet k neočekávaným problémům s dostupností. Tyto problémy můžou způsobit provozní problémy, pokud image není dostupná, když ji potřebujete. Tady jsou některé výhody použití registru kontejneru místo veřejného registru:

  • Můžete blokovat neoprávněný přístup k vašim imagím.
  • Nebudete mít 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í.
  • Využijte výhod integrované kontroly kontejnerů a dodržování předpisů image.

  Možnost je Azure Container Registry (ACR).

• 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á jenom image z ACR nasazené jako součást architektury.

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. Minimalizuje nároky na služby, které běží na všech uzlech, jako je monitorování a protokolování.

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

• Skutečné velikosti uzlů pro vaši úlohu budou záviset na požadavcích určených týmem pro návrh. Na základě obchodních požadavků jsme pro produkční úlohy zvolili DS4_v2. Pokud chcete snížit náklady, můžete snížit velikost na DS3_v2, což je minimální doporučení.

• Při plánování kapacity clusteru předpokládejme, že vaše úloha může spotřebovávat až 80 % každého uzlu; zbývajících 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.

Integrace ID Microsoft Entra pro cluster

Zabezpečení přístupu ke clusteru a z clusteru je důležité. Při rozhodování o zabezpečení si můžete myslet z pohledu clusteru:

• Vnitřní přístup. Přístup AKS ke komponentám Azure, jako je síťová infrastruktura, Azure Container Registry a Azure Key Vault. Autorizovat pouze prostředky, ke kterým má cluster povolený přístup.
• Přístup mimo přístup. Poskytnutí přístupu identit 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.

Ze dvou způsobů se doporučuje spravované identity. S instančními objekty zodpovídáte za správu a obměnu tajných kódů 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čuje se povolit spravované identity, aby cluster mohl komunikovat s externími prostředky Azure prostřednictvím ID Microsoft Entra. Toto nastavení můžete povolit pouze během vytváření clusteru. I když se Microsoft Entra ID nepoužívá okamžitě, můžete ho později začlenit.

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

Jako příklad pro vnitřní případ se podíváme na použití spravovaných identit, když cluster potřebuje načíst image z registru kontejneru. Tato akce vyžaduje, aby cluster získal přihlašovací údaje registru. Jedním ze způsobů je uložit tyto informace ve formě objektu Tajný kód Kubernetes a použít imagePullSecrets k načtení tajného kódu. Tento přístup se nedoporučuje kvůli složitostem zabezpečení. Potřebujete nejen předchozí znalosti tajného kódu, ale také zpřístupnění tohoto tajného kódu prostřednictvím kanálu DevOps. Dalším důvodem 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á těmito obavami.

V této architektuře cluster přistupuje k prostředkům Azure, které jsou zabezpečené pomocí ID Microsoft Entra, a 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 hodlá provést. 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, kdy byly k clusteru přiřazeny předdefinované role Azure:

• Přispěvatel sítě Schopnost clusteru řídit paprskovou virtuální síť. Toto přiřazení role umožňuje, aby identita přiřazená systémem clusteru AKS fungovala s vyhrazenou podsítí pro služby kontroleru interního příchozího přenosu dat.
• Monitorování vydavatele metrik Schopnost clusteru odesílat metriky do služby Azure Monitor.
• AcrPull. Schopnost clusteru načíst image ze zadaných registrů kontejnerů Azure.

Přístup ke clusteru

Integrace Microsoft Entra také zjednodušuje zabezpečení externího přístupu. Předpokládejme, že uživatel chce použít kubectl. Jako počáteční krok spustí az aks get-credentials příkaz pro získání přihlašovacích údajů clusteru. Microsoft Entra ID ověří identitu uživatele 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 umožňuje přístup k 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ý používá nativní Azure RBAC k řízení přístupu ke clusteru. Obě jsou podrobně popsány níže.

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

Kubernetes podporuje řízení přístupu na základě role (RBAC) prostřednictvím:

• Sada oprávnění. Definované objektem Role nebo ClusterRole objektem pro oprávnění v rámci clusteru.

• Vazby, které přiřazují uživatele a skupiny, kteří můžou tyto akce provádět. Definováno objektem nebo ClusterRoleBinding objektemRoleBinding.

Kubernetes má některé předdefinované role, jako je správce clusteru, úpravy, zobrazení atd. Svázání těchto rolí s uživateli a skupinami Microsoft Entra za účelem správy přístupu pomocí podnikového adresáře Další informace najdete v tématu Použití RBAC Kubernetes s integrací Microsoft Entra.

Ujistěte se, že vaše skupiny Microsoft Entra používané pro přístup ke clusteru a oboru názvů jsou součástí kontrol přístupu Microsoft Entra.

Použití Azure RBAC pro autorizaci Kubernetes

Místo použití nativního RBAC Kubernetes (ClusterRoleBindings a RoleBindings) pro autorizaci s integrovaným ověřováním Microsoft Entra, další možností, kterou doporučujeme, je použití Azure RBAC a přiřazení rolí Azure k vynucení kontrol autorizace v clusteru. Tato přiřazení rolí je možné přidat i v oborech předplatného nebo skupiny prostředků, aby všechny clustery v oboru dědily 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. Přístup uživatelů ke clusterům pomocí této metody se nenavrhuje. Je založená na certifikátu a provádí se externě pro vašeho primárního zprostředkovatele identity; 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 se při nasazení clusteru explicitně zakáže přístup přes účty místního clusteru.

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. Pokud 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 se spravované identity pro pody poskytují prostřednictvím ID úloh Microsoft Entra v AKS. To se integruje s nativními funkcemi Kubernetes pro federaci s externími zprostředkovateli identit. Další informace o ID úloh Microsoft Entra federaci najdete v následujícím přehledu.

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

Prostředky příchozího přenosu dat Kubernetes směrují a distribuují příchozí provoz do clusteru. Existují dvě části prostředků příchozího přenosu dat:

• Interní nástroj pro vyrovnávání zatížení. Spravuje ho AKS. Tento 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.

  V této architektuře se používá Azure Load Balancer. Nachází se mimo cluster v podsíti vyhrazené pro prostředky příchozího přenosu dat. Přijímá provoz ze služby Aplikace Azure Gateway a tato komunikace probíhá přes protokol TLS. 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. Zvolili jsme 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 tyto body.

• V rámci rozhodnutí o návrhu zvolte obor, ve kterém bude kontroler příchozího přenosu dat fungovat. 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 zajistilo provozní kontinuitu, pokud uzel nefunguje. Slouží podAntiAffinity k tomuto účelu.

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

• Otevřete porty a protokoly, které konkrétním entitám umožňují odesílat provoz do kontroleru příchozího přenosu dat. V této architektuře traefik přijímá provoz pouze z brány Aplikace Azure.

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

• 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í je možné 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 .

Pokud chcete zkontrolovat návrh příchozího přenosu dat používaný v kontejnerech Windows v referenční architektuře standardních hodnot AKS, přečtěte si doprovodný článek.

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. tls, annotationsa entrypoints indikuje, že trasy budou obsluhovány přes HTTPS. Určujemiddlewares, že je povolený pouze provoz z podsítě Aplikace Azure Brány. Odpovědi použijí kódování gzip, pokud klient přijme. Protože Traefik ukončuje protokol TLS, komunikace s back-endovými službami probíhá 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

Tok sítě v tomto kontextu je možné kategorizovat jako:

• Příchozí provoz. Z klienta do úlohy spuštěné v clusteru.

• Výchozí přenos dat. Z podu nebo uzlu v clusteru do externí služby.

• Provoz mezi pody. Komunikace 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á do této kategorie.

• Provoz správy. Provoz, který prochází 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 cypherů. Je povolená striktní indikace názvu serveru (SNI). Kompletní protokol TLS je nastavený prostřednictvím služby Application Gateway pomocí dvou různých certifikátů TLS, jak je znázorněno na tomto obrázku.

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ý prostřednictvím záznamu DNS A k veřejné IP adrese služby Aplikace Azure 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í (WAF) a vyjednává metodu handshake protokolu TLS pro bicycle.contoso.com, což umožňuje pouze zabezpečené šifry. Application Gateway je bod ukončení protokolu TLS, protože je nutný ke zpracování pravidel kontroly WAF a spouštění pravidel směrování, která přesměrují provoz do nakonfigurovaného back-endu. Certifikát TLS je uložený ve službě Azure Key Vault. Přistupuje se k ní pomocí spravované identity přiřazené uživatelem integrované se službou Application Gateway. Informace o této funkci najdete v tématu Ukončení protokolu TLS s certifikáty služby Key Vault.

3. Při přesunu provozu ze služby Application Gateway do back-endu se znovu zašifruje jiným certifikátem TLS (zástupným znakem pro *.aks-ingress.contoso.com), který se předá internímu nástroji pro vyrovnávání zatížení. Toto opětovné šifrování zajišťuje, že provoz, který není zabezpečený, neprochází 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ší bod ukončení protokolu TLS pro *.aks-ingress.contoso.com a předává provoz podům úloh přes protokol HTTP. Certifikáty se ukládají ve službě Azure Key Vault a připojují se ke clusteru pomocí ovladače rozhraní CSI (Container Storage Interface). Další informace najdete v tématu Přidání správy tajných kódů.

Kompletní provoz TLS můžete implementovat v každém segmentu směrování až do podu úloh. Při rozhodování o zabezpečení provozu mezi pody nezapomeňte měřit výkon, latenci a provozní dopad. U většiny clusterů s jedním tenantem, se správnými postupy RBAC řídicí roviny 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í (WAF). To minimalizuje režijní náklady na správu úloh a dopad na výkon sítě. Vaše požadavky na úlohy a dodržování předpisů budou určovat, kde provádíte ukončení protokolu TLS.

Výstupní tok provozu

V této architektuře doporučujeme veškerý odchozí provoz z clusteru komunikovat prostřednictvím služby Azure Firewall nebo vlastního podobného síťového virtuálního zařízení přes jiné možnosti, jako je NAT Gateway nebo proxy server HTTP. U řízení nulové důvěryhodnosti a možnosti kontroly provozu prochází veškerý výchozí provoz z clusteru přes Azure Firewall. Tuto volbu můžete implementovat pomocí uživatelem definovaných tras (UDR). Dalším segmentem směrování trasy je privátní IP adresa brány Azure Firewall. V této části se Azure Firewall rozhodne, jestli se má blokovat nebo povolit odchozí provoz. Toto rozhodnutí vychází z konkrétních pravidel definovaných ve službě Azure Firewall nebo na předdefinovaných pravidlech analýzy hrozeb.

Alternativou k použití služby Azure Firewall je použití funkce proxy serveru HTTP AKS. Veškerý výchozí přenos dat clusteru se nejprve nastaví na IP adresu proxy serveru HTTP, který se rozhodne přeposlat provoz nebo ho vypustit.

V obou metodách zkontrolujte požadovaná pravidla výchozí sítě pro AKS.

Výjimkou ovládacího prvku nulové důvěryhodnosti je, když cluster potřebuje komunikovat s jinými prostředky Azure. Cluster například potřebuje vyžádat aktualizovanou image z registru kontejneru nebo tajné kódy ze služby Azure Key Vault. Doporučeným přístupem je použití služby Azure Private Link. Výhodou je, že se konkrétní podsítě dostanou přímo ke službě místo provozu mezi clusterem a službami procházející 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 Nebo skladové položky Azure podporují 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 možné, 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, je možné tyto adresy přidat seznam povolených IP adres služby. Nevýhodou je, že Azure Firewall musí mít další pravidla, aby se zajistilo, že je povolený jenom provoz z konkrétní podsítě. Při plánování více IP adres pro výchozí přenos dat pomocí služby Azure Firewall zapojte tyto adresy, jinak byste se mohli dostat k vyčerpání portů. Další informace o plánování více IP adres najdete v tématu Omezení a řízení odchozího provozu.

Pokud chcete zkontrolovat aspekty výchozího přenosu dat specifické pro Windows používané v kontejnerech Windows v referenční architektuře standardních hodnot AKS, projděte si doprovodný článek.

Provoz mezi pody

Ve výchozím nastavení může pod přijímat provoz z jakéhokoli jiného podu v clusteru. Kubernetes NetworkPolicy se používá k omezení síťového provozu mezi pody. Použijte zásady uvážlivě, jinak může dojít k 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ě.

Povolte zásady sítě, když je cluster zřízený, protože ho nejde přidat později. Existuje několik možností pro technologie, které implementují NetworkPolicy. Doporučuje se Azure Network Policy, které vyžaduje rozhraní Azure Container Networking Interface (CNI), viz následující poznámka. Mezi další možnosti patří Calico Network Policy, dobře známá opensourcová 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 zásadami Azure Network Policy a Calico a jejich funkcemi.

Provoz správy

V rámci spouštění clusteru bude server rozhraní API Kubernetes přijímat provoz z prostředků, které chtějí provádět operace správy v clusteru, například žádosti o vytvoření prostředků nebo škálování clusteru. Mezi příklady těchto prostředků patří fond agentů sestavení v kanálu DevOps, podsíti Bastionu a fondy uzlů. Místo přijetí tohoto provozu správy ze všech IP adres použijte funkci Autorizované rozsahy IP adres 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 další 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, který není přístupný z 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 Azure Key Vault. Výhodou je, že spravované úložiště zpracovává obměnu tajných kódů, nabízí silné šifrování, poskytuje protokol auditu přístupu a udržuje základní tajné kódy mimo kanál nasazení. V této architektuře je brána firewall služby Azure Key Vault povolená a nakonfigurovaná s připojením privátního propojení k prostředkům v Azure, které potřebují přístup k tajným kódům a certifikátům.

Služba Azure 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. Příklad, jak Aplikace Azure Brána 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 buď 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ě Azure Key Vault pomocí RBAC.

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

K povolení přístupu k tajným kódům z konkrétního úložiště budete muset 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ě. V této implementaci jsme zvolili azure Key Vault s ovladačem CSI úložiště tajných kódů pomocí doplňku, který načte certifikát TLS ze služby Azure Key Vault a načte ho do podu, na kterém běží kontroler příchozího přenosu dat. Provádí se během vytváření podů a svazků se ukládají veřejné i privátní klíče.

Úložiště úloh

Úloha použitá 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 o možnostech úložiště najdete v tématu Možnosti úložiště pro aplikace ve službě Azure Kubernetes Service (AKS).

Správa zásad

Efektivní způsob správy clusteru AKS spočívá v vynucení zásad správného řízení prostřednictvím zásad. Kubernetes implementuje zásady prostřednictvím OPA Gatekeeperu. Pro AKS se zásady doručují prostřednictvím Služby Azure Policy. Každá zásada se použije pro všechny clustery v oboru. Vynucení služby Azure Policy v konečném důsledku zpracovává OPA Gatekeeper v clusteru a všechny kontroly zásad se protokolují. Změny zásad se v clusteru okamžitě neprojeví, očekává se, že se zpoždění projeví.

Existují dva různé scénáře, které služba Azure Policy poskytuje pro správu clusterů AKS:

• Zabránění nebo omezení nasazení clusterů AKS ve skupině prostředků nebo předplatném vyhodnocením standardů vaší organizace Postupujte například podle konvence vytváření názvů, zadejte značku atd.
• 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čovaných 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 vybrat a zvolit další zásady pro cluster a prostředky (ACR, Application Gateway, Key Vault a další), které s clusterem pracují, podle požadavků vaší organizace.

• Chcete akci auditovat nebo odepřít? V režimu auditování je akce povolená, ale označí se 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čuje se dál používat zásady v režimu auditování , abyste o těchto instancích věděli.

• Máte požadavky, které předdefinované zásady nepokrývají? 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 o vytváření vlastních zásad 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á organizace obecné zásady.

• Zásady Azure se přiřazují ke konkrétním oborům. Ujistěte se, že jsou zásady produkčního prostředí také ověřeny 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 dalším omezením, která se v předprodukčním prostředí nezohlednily.

V této referenční implementaci je služba Azure Policy povolená při vytváření clusteru AKS a přiřazuje omezující iniciativu 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í . Existuje například zásada, která zajistí, že se image načítají jenom z nasazené služby ACR. Zvažte vytvoření vlastních iniciativ. Zkombinujte zásady platné pro vaši úlohu do jednoho přiřazení.

Pokud chcete zjistit, 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 také k protokolům pro azure-policy pody azure-policy-webhook v kube-system oboru názvů.

Pokud chcete zkontrolovat aspekty Azure Policy specifické pro Windows, které jsou součástí kontejnerů Windows v referenční architektuře standardních hodnot AKS, přečtěte si doprovodný článek.

Š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 stávajících uzlů prostřednictvím horizontálního automatického škálování podů (HPA). Pokud už není možné naplánovat další pody, 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í.

Ruční nebo programový způsob vyžaduje 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 jedním ze způsobů, jak dostávat oznámení o selhání plánovače Kubernetes. 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 portálu.

Automatické škálování je doporučeným přístupem, protože některé z těchto ručních mechanismů jsou integrované do automatického škálování.

Jako obecný přístup začněte testováním výkonu 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í. 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 se doporučuje nastavit minimální a maximální počet replik. Tyto 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 tyto 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 existovat stav č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. Podrobnosti najdete v tématu Cooldown událostí škálování.

Pokud je vaše úloha řízená událostmi, oblíbenou opensourcovou možností je KEDA. Zvažte KEDA, pokud vaše úloha je řízena zdrojem událostí, jako je například fronta zpráv, místo aby byla vázána na procesor nebo paměť. KEDA podporuje mnoho zdrojů událostí (nebo škálovačů). Seznam podporovaných škálovacích nástrojů KEDA najdete tady , včetně škálovače Služby Azure Monitor. 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ů. Mělo by se přidat 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 hodnotu 2 z důvodu jednoduché povahy úlohy.

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

Pokud chcete zkontrolovat aspekty škálování zahrnuté v kontejnerech Windows v referenční architektuře standardních hodnot AKS, přečtěte si doprovodný článek.

Rozhodnutí o kontinuitě podnikových procesů

Pokud chcete zachovat provozní kontinuitu, definujte smlouvu o úrovni služeb pro infrastrukturu a vaši aplikaci. Informace o výpočtu měsíční doby provozu najdete v tématu SLA pro Azure Kubernetes Service (AKS).

Uzly clusteru

Pro splnění minimální úrovně dostupnosti pro úlohy je potřeba více uzlů ve fondu uzlů. Pokud dojde k výpadku uzlu, může aplikace pokračovat ve spuštění jiného uzlu ve fondu uzlů ve stejném clusteru. Pro spolehlivost se doporučují tři uzly pro fond systémových uzlů. Pro fond uzlů uživatele začněte s maximálně dvěma uzly. Pokud potřebujete vyšší dostupnost, zřiďte více uzlů.

Izolujte aplikace od systémových služeb tak, že je 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. Použití značek, popisků a taintů se doporučuje identifikovat fond uzlů pro naplánování úloh a zajistit, aby byl fond systémových uzlů taintovaný pomocí třídy CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

Pro spolehlivost je zásadní pravidelná aktualizace clusteru, jako jsou včasné aktualizace. Doporučuje se také monitorování stavu podů prostřednictvím sond.

Dostupnost podů

Zajistěte prostředky podu. Důrazně doporučujeme, aby nasazení určila požadavky na prostředky podu. Plánovač pak může odpovídajícím způsobem naplánovat pod. Spolehlivost bude výrazně zastaralá, pokud pody nelze naplánovat.

Nastavte rozpočty 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í zajistit, aby existoval 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ů zajistí správné nastavení požadavků na pod a omezení pro nasazení. Další informace najdete v tématu Vynucení kvót prostředků.

Nastavte požadavky a omezení podů. Nastavení těchto limitů umožňuje Kubernetes efektivně přidělovat prostředky procesoru nebo paměti podům a mít na uzlu vyšší hustotu kontejneru. Limity také můžou zvýšit spolehlivost s nižšími náklady kvůli lepšímu využití hardwaru.

Pokud chcete odhadnout limity, 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.

Tyto limity je možné zadat v manifestech nasazení. Další informace najdete v tématu Nastavení požadavků a omezení podů.

Zóny dostupnosti a podpora více oblastí

Pokud vaše smlouva SLA vyžaduje vyšší dobu provozu, chraňte před výpadky pomocí zón dostupnosti. Zóny dostupnosti můžete použít, pokud je tato 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. Operace a konfigurace škálovací sady se spravují službou AKS. Tady je několik aspektů, které je potřeba vzít v úvahu při povolování více zón:

• Celá infrastruktura. Zvolte oblast, která podporuje zóny dostupnosti. Další informace najdete v tématu Omezení a dostupnost oblastí. Pokud si chcete koupit smlouvu SLA pro dobu provozu, zvolte oblast, která tuto možnost podporuje. Smlouva SLA pro dobu provozu je při použití zón dostupnosti vyšší.

• Cluster. Zóny dostupnosti je možné nastavit pouze při vytvoření fondu uzlů a později je nelze změnit. Velikostiuzlůch Základní škálovací sada virtuálních počítačů poskytuje stejnou hardwarovou konfiguraci napříč zónami.

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

• Závislé prostředky. Pro úplné zónové výhody musí všechny závislosti služeb 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 dostupný v zóně, ve které je zřízený. V případě selhání se uzel může přesunout do jiné zóny, ale spravovaný disk se nepřesune s tímto uzlem do této zóny.

Pro zjednodušení se v této architektuře AKS nasadí do jedné oblasti s fondy uzlů, které pokrývají zóny dostupnosti 1, 2 a 3. Další prostředky infrastruktury, jako je Azure Firewall a Application Gateway, se nasazují také do stejné oblasti s podporou více zón. Pro Azure Container Registry je povolená geografická replikace.

Několik oblastí

Povolení zón dostupnosti nebude stačit, pokud dojde k výpadku celé oblasti. Pokud chcete mít vyšší dostupnost, spusťte v různých oblastech několik clusterů AKS.

• Použijte spárované oblasti. Zvažte použití kanálu CI/CD, který je nakonfigurovaný tak, aby používal spárovanou oblast k obnovení z selhání oblastí. Výhodou použití spárovaných oblastí je spolehlivost během aktualizací. Azure zajišťuje, aby se najednou aktualizovala pouze jedna oblast v páru. Některé nástroje DevOps, jako je Flux, můžou usnadnit nasazení ve více oblastech.

• Pokud prostředek Azure podporuje geografickou redundanci, zadejte umístění, kde bude redundantní služba mít sekundární. Povolení geografické replikace pro Azure Container Registry například automaticky replikuje image do vybraných oblastí Azure a poskytne nepřetržitý přístup k imagím, i když došlo k výpadku 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í Azure Load Balancer, protože dokáže distribuovat provoz mimo web mezi zóny. Pokud potřebujete distribuovat provoz napříč oblastmi, měli byste zvážit Službu Azure Front Door. Další aspekty najdete v tématu Volba nástroje pro vyrovnávání zatížení.

Zotavení po havárii

V případě selhání v primární oblasti byste měli být schopni rychle vytvořit novou instanci v jiné oblasti. Tady je několik doporučení:

• Použijte spárované oblasti.

• Nestavové úlohy je možné efektivně replikovat. Pokud potřebujete uložit stav v clusteru (nedoporučuje se), ujistěte se, že data často zálohujete ve spárované oblasti.

• Integrujte strategii obnovení, jako je replikace do jiné oblasti, jako součást kanálu DevOps, aby splňovala cíle úrovně služeb (SLO).

• Při zřizování jednotlivých služeb Azure zvolte funkce, které podporují zotavení po havárii. Například v této architektuře je pro geografickou replikaci povolená služba Azure Container Registry. Pokud oblast přestane fungovat, můžete i nadále načíst image z replikované oblasti.

Zálohování clusteru

V případě mnoha architektur je možné zřídit nový cluster a vrátit ho do provozního stavu prostřednictvím GitOps založeného na [spouštění clusteru}(#cluster bootstrapping) a následného nasazení aplikace. Pokud ale existuje kritický stav prostředků, jako jsou mapy konfigurace, úlohy a potenciálně tajné kódy, které z nějakého důvodu nejde zachytit v rámci procesu spouštění, zvažte strategii obnovení. Obecně se doporučuje spouštět bezstavové úlohy v Kubernetes, ale pokud vaše architektura zahrnuje stav založený na disku, budete také muset zvážit strategii obnovení pro daný obsah.

Pokud je potřeba, aby zálohování clusteru bylo 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 bude zodpovědný za odesílání stavu prostředků clusteru do cílového umístění zvoleného a koordinace snímků trvalých svazků založených na disku Azure.

VMware Velero je příkladem běžného řešení zálohování Kubernetes, které můžete nainstalovat a spravovat přímo. Alternativně je možné rozšíření zálohování AKS použít k zajištění 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í, které by zahrnovalo další prostředky Azure v architektuře pro správu, monitorování, platby a zabezpečení; například účet azure Storage, trezor Azure Backup a konfigurace a důvěryhodný přístup. GitOps v kombinaci se záměrem spouštět bezstavové úlohy je implementované řešení obnovení.

Zvolte a ověřte řešení, které splňuje váš obchodní cíl, včetně definovaného cíle bodu obnovení (RPO) a cíle doby obnovení (RTO). Definujte tento 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 se dá použít jako bezplatná služba, ale tato úroveň nenabízí finančně zajištěnou smlouvu SLA. Pokud chcete tuto smlouvu SLA získat, musíte zvolit úroveň Standard. Doporučujeme, aby všechny produkční clustery používaly úroveň Standard. Vyhraďte si clustery úrovně Free pro předprodukční clustery. V kombinaci s Azure Zóny dostupnosti se smlouva SLA serveru Kubernetes zvýší na 99,95 %. Fondy uzlů a další prostředky jsou pokryté vlastní smlouvou SLA.

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ě Azure Container Registry, jsou k dispozici v cenových úrovních Premium, což je dražší. Náklady se také zvětší, protože se použijí poplatky za šířku pásma při přesunu provozu mezi zónami a oblastmi.

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

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

Zajištění spolehlivosti prostřednictvím vynuceného testování převzetí služeb při selhání se simulovanými výpadky, jako je zastavení uzlu, vyřazení všech prostředků AKS v konkrétní zóně za účelem simulace selhání zón nebo vyvolání selhání externí závislosti. Azure Chaos Studio je také možné využít k simulaci různých typů výpadků v Azure a v clusteru.

Další informace najdete v tématu Azure Chaos Studio.

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

Azure Monitor Container Insights je doporučený nástroj pro monitorování výkonu úloh kontejnerů, protože události můžete zobrazit 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. Můžete ho také použít k monitorování výkonu při škálování podů. Zahrnuje shromažďování telemetrických dat kritických pro monitorování, analýzu a vizualizaci shromážděných dat k identifikaci trendů a konfiguraci upozornění tak, aby byla proaktivně upozorněna na kritické problémy.

Většina úloh hostovaných v podech generuje metriky Prometheus. Container Insights dokáže integrovat s Prometheus a zobrazit metriky aplikací a úloh, které shromažďuje z uzlů a Kubernetes.

Existují některá řešení třetích stran, která se integrují s Kubernetes, můžete využít, například Datadog, Grafana nebo New Relic, pokud je už vaše organizace používá.

V AKS spravuje Azure některé základní služby Kubernetes a protokoly pro komponenty řídicí roviny AKS se implementují v Azure jako protokoly prostředků. Doporučuje se, aby většina clusterů měla vždy povolené následující možnosti, protože vám můžou pomoct s řešením problémů s clustery a s relativně nízkou hustotou protokolů:

• Protokolováním clusterAutoscaler získáte pozorovatelnost operací škálování. Další informace najdete v tématu Načtení protokolů a stavu automatického škálování clusteru.
• KubeControllerManager , aby měl pozorovatelnost v interakci mezi Kubernetes a řídicí rovinou Azure.
• KubeAudit Správa mít pozorovatelnost do aktivit, které upravují váš cluster. Neexistuje žádný důvod, proč mít kubeAudit i KubeAudit Správa oba povolené, protože KubeAudit je nadmnožina KubeAudit Správa která zahrnuje i operace bez úprav (read).
• Guard zachycuje audity Microsoft Entra ID a Azure RBAC.

Další kategorie protokolů, jako je KubeScheduler nebo KubeAudit, můžou být velmi užitečné při vývoji počátečního clusteru nebo životního cyklu úloh, kdy přidání automatického škálování clusteru, umístění podů a plánování a podobných dat může pomoct při řešení problémů s provozem clusteru nebo úloh. Udržování rozšířených protokolů řešení potíží na plný úvazek, jakmile jsou potřeba řešení potíží, se můžou považovat za zbytečné náklady na příjem a ukládání 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 objemem knihovny můžete ukládat a opakovaně používat dotazy protokolu pomocí jednoho nebo více balíčků dotazů. Vaše vlastní knihovna dotazů pomáhá umožnit další pozorovatelnost stavu a výkonu clusterů AKS a podporovat cíle na úrovni služeb (SLO).

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

Pokud chcete zkontrolovat aspekty monitorování specifické pro Windows zahrnuté v kontejnerech Windows v referenční architektuře standardních hodnot AKS, přečtěte si doprovodný článek.

Povolení samoopravení

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

Aktualizace clusteru AKS

Definování strategie aktualizace, která je konzistentní s obchodními požadavky, je nejdůležitější. Pochopení úrovně předvídatelnosti data a času, kdy se aktualizuje verze clusteru AKS nebo jeho uzly, a požadovaný stupeň kontroly nad tím, jaká konkrétní image nebo binární soubory se nainstalují, jsou základní aspekty, které budou podrobný plán aktualizace clusteru AKS delineovat. Předvídatelnost je svázaná se dvěma hlavními vlastnostmi aktualizace clusteru AKS, které jsou intervalem aktualizace a časovým obdobím údržby. Řízení určuje, jestli se aktualizace instalují ručně nebo automaticky. Organizace s clustery AKS, které nejsou pod přísným nařízením zabezpečení, můžou zvážit týdenní nebo dokonce měsíční aktualizace, zatímco zbytek musí aktualizovat opravy označené zabezpečením, jakmile budou k dispozici (denně). Organizace, které provozují clustery AKS jako neměnnou infrastrukturu, je neaktualizuje. Znamená to, že se nevedou automatické ani ruční aktualizace. Místo toho, když bude požadovaná aktualizace k dispozici, nasadí se razítko repliky a pouze když je nová instance infrastruktury připravená, vyprázdní se stará instance, která jim poskytne nejvyšší úroveň kontroly.

Po určení podrobného plánu aktualizace clusteru AKS je možné ho snadno namapovat na dostupné možnosti aktualizace pro uzly AKS a verzi clusteru AKS:

• Uzly AKS:

  1. Žádné nebo ruční aktualizace: Jedná se o neměnnou infrastrukturu nebo pro ruční aktualizace. Tím dosáhnete větší předvídatelnosti a kontroly nad aktualizacemi uzlů AKS.
  2. Automatické bezobslužné aktualizace: AKS spouští nativní aktualizace operačního systému. To poskytuje předvídatelnost konfigurací časových období údržby v souladu s tím, co je vhodné pro firmu. Může být založená na špičkách a na tom, co je nejlepší provoz. Úroveň řízení je nízká, protože není možné předem vědět, co se konkrétně nainstaluje v uzlu AKS.
  3. Automatické aktualizace imagí uzlu: Doporučujeme automaticky aktualizovat image uzlů AKS, jakmile budou k dispozici nové virtuální pevné disky (VHD). Návrh časových období údržby tak, aby byla co nejvíce sladěna s obchodními potřebami. U aktualizací virtuálních pevných disků označených zabezpečením doporučujeme nakonfigurovat denní časové intervaly údržby, které poskytují nejnižší předvídatelnost. Pravidelné aktualizace virtuálního pevného disku je možné nakonfigurovat pomocí týdenního časového období údržby, každé dva týdny nebo dokonce měsíčně. V závislosti na tom, jestli je potřeba označit zabezpečením a pravidelnými virtuálními pevnými disky v kombinaci s časovým obdobím plánované údržby, předvídatelnost kolísá a nabízí větší nebo menší flexibilitu, aby byla v souladu s obchodními požadavky. I když by to bylo vždy v pořádku, obchodní požadavky by byly ideální, realita vyžaduje, aby organizace našli bod, který je v pořádku. Úroveň řízení je nízká, protože není možné předem zjistit, jaké konkrétní binární soubory byly zahrnuty do nového virtuálního pevného disku, a přesto tento typ automatických aktualizací je doporučenou možností, protože image jsou před zpřístupněním prověřeny.

  Poznámka:

  Další informace o konfiguraci automatických aktualizací uzlů AKS najdete v imagích operačního systému uzlu automatického upgradu.

• Verze clusteru AKS:

  1. Žádné nebo ruční aktualizace: Jedná se o neměnnou infrastrukturu nebo pro ruční aktualizace. Tím dosáhnete větší předvídatelnosti a kontroly nad aktualizacemi verzí clusteru AKS. Doporučujeme se přihlásit k tomuto nastavení, protože toto nastavení zůstává v plné kontrole a umožňuje otestovat novou verzi clusteru AKS (tj. 1.14.x až 1.15.x) v nižších prostředích před dosažením produkčního prostředí.
  2. Automatické aktualizace: Produkční cluster se nedoporučuje automaticky opravovat ani aktualizovat žádným způsobem (tj. 1.16.x až 1.16.y) na novou dostupnou verzi clusteru AKS, aniž by byla řádně testována v nižších prostředích. Zatímco upstreamové verze Kubernetes a aktualizace verzí clusteru AKS jsou sladěné s pravidelným tempem, doporučení je stále obranné s clustery AKS v produkčním prostředí, což zvyšuje předvídatelnost a kontrolu nad procesem aktualizace. Proti zvážení této konfigurace pro nižší prostředí jako součást efektivity provozu, což umožňuje proaktivní provádění rutinního testování detekovat potenciální problémy co nejdříve.

Udržujte verzi Kubernetes v aktualizovaném stavu s podporovanými verzemi N-2. Upgrade na nejnovější verzi Kubernetes je kritický, protože se často vydávají nové verze.

Další informace najdete v tématu Pravidelné aktualizace na nejnovější verzi Kubernetes a upgrade clusteru Azure Kubernetes Service (AKS).

Oznámení událostí vyvolaných vaším clusterem, jako je dostupnost nové verze AKS pro váš cluster, je možné dosáhnout prostřednictvím 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í.

Týdenní aktualizace

AKS poskytuje nové image uzlů, které mají nejnovější aktualizace operačního systému a modulu runtime. Tyto nové image se nepoužijí automaticky. Zodpovídáte za rozhodování, jak často se mají obrázky aktualizovat. Doporučuje se, abyste měli každý týden proces upgradu základní image fondů uzlů. Další informace najdete v tématu Image uzlu Azure Kubernetes Service (AKS) s upgradempoznámek k verzi AKS.

Denní aktualizace

Mezi upgrady imagí si uzly AKS stahují a instalují opravy operačního systému a modulu runtime jednotlivě. Instalace může vyžadovat restartování virtuálních počítačů uzlů. AKS nerestartuje uzly kvůli čekajícími aktualizacím. Mějte proces, který monitoruje uzly pro použité aktualizace, které vyžadují restartování a provádí restartování těchto uzlů řízeným způsobem. Open source možnost je Kured (Kubernetes restart démon).

Udržování imagí uzlů v synchronizaci s nejnovější týdenní verzí minimalizuje tyto občasné požadavky na restartování při zachování stavu rozšířeného zabezpečení. Spoléhat se jen na upgrady imagí uzlů zajistí kompatibilitu AKS a týdenní opravy zabezpečení. Zatímco použití denních aktualizací vyřeší problémy se zabezpečením rychleji, nemusí být nutně testovány v AKS. Pokud je to možné, použijte upgrade image uzlu jako primární strategii týdenních oprav zabezpečení.

Monitorování zabezpečení

Monitorujte infrastrukturu kontejneru pro aktivní hrozby i potenciální bezpečnostní rizika:

• Povolte Microsoft Defender for Containers k identifikaci a nápravě doporučení defenderu pro cloud pro vaše image kontejnerů.
• Microsoft Defender for Containers pravidelně kontroluje ohrožení zabezpečení imagí kontejnerů.
• Microsoft Defender for Containers také generuje výstrahy zabezpečení v reálném čase pro podezřelé aktivity.
• Informace o posílení zabezpečení použitého u hostitelů virtuálních počítačů AKS najdete v tématu Posílení zabezpečení v hostitelském operačním systému.

Operace clusteru a úloh (DevOps)

Tady je několik aspektů. Další informace najdete v pilíři Efektivita provozu .

Spouštění clusteru

Po dokončení zřizování máte funkční cluster, ale před nasazením úloh se můžou vyžadovat kroky. Proces přípravy clusteru se nazývá bootstrapping a může se skládat z akcí, jako je nasazení požadovaných imagí na uzly clusteru, vytváření oborů názvů a cokoli jiného, co splňuje požadavky vašeho případu použití nebo organizace.

Aby se snížila mezera mezi zřízeným clusterem a clusterem, který je správně nakonfigurovaný, měli by operátoři clusteru uvažovat o tom, jak bude jejich jedinečný proces spouštění vypadat, a připravit relevantní prostředky předem. Pokud je například před nasazením úloh aplikace důležité kured na každém uzlu, operátor clusteru bude chtít před zřízením clusteru zajistit, aby služba ACR obsahující cílovou image Kured už existuje.

Proces spouštění je možné nakonfigurovat pomocí jedné z následujících metod:

• Samoobslužná konfigurace s využitím něco jako Flux nebo Argo CD
• Pipelines
• Rozšíření clusteru GitOps Flux v2

Jednou z hlavních výhod použití rozšíření clusteru GitOps Flux v2 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 zahrnutí tohoto bootstrappingu jako šablon prostředků pro zajištění souladu s vaší strategií IaC.

A konečně při použití rozšíření kubectl se nevyžaduje pro žádnou část procesu spouštění a použití kubectlpřístupu na základě přístupu je možné rezervovat pro situace opravy tísňového volání. Mezi šablonami pro definice prostředků Azure a spouštěním manifestů prostřednictvím rozšíření GitOps je možné provádět všechny běžné konfigurační aktivity bez nutnosti použití 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 by byla konfigurace sítí. Zřiďte virtuální sítě pro hvězdicovou síť a 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. Podsíť pro Službu Azure Firewall v centru

Další částí může být integrace základní úlohy s ID Microsoft Entra.

Použití infrastruktury jako kódu (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. Jednou z možností je šablona Azure Resource Manageru (ARM ). Další je Terraform.

Ujistěte se, že při zřizování prostředků podle zásad správného řízení. Když například vyberete správné velikosti virtuálních počítačů, zůstaňte v rámci omezení nákladů, možnosti zóny dostupnosti tak, aby odpovídaly požadavkům vaší aplikace.

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

Uložte skripty a soubory šablon a skriptů verzí do systému správy zdrojového kódu.

CI/CD úloh

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

Vaše strategie nasazení musí obsahovat spolehlivý a automatizovaný kanál průběžného doručování (CD). Změny imagí kontejneru úloh by se měly automaticky nasadit do clusteru.

V této architektuře jsme pro správu pracovního postupu a nasazení zvolili GitHub Actions . Mezi další oblíbené možnosti patří Azure DevOps Services 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ý na tomto konci, který operátorům umožňuje deklarativní definování procesu spouštění v rámci strategie IaC a automatické zobrazení konfigurace 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í.
• Aktualizace požadované spuštěné konfigurace na základě těchto změn.

Můžete také nastavit zásady, které určují způsob nasazení těchto 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 git server.

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.

5. Zásady větve můžete mít na vašem serveru Git. Díky tomu může několik vývojářů schválit změnu prostřednictvím žádosti o přijetí změn, než se použije v produkčním prostředí.

I když je možné GitOps a Flux nakonfigurovat ručně, pro AKS se doporučuje gitOps s rozšířením clusteru Flux v2.

Strategie nasazení úloh a clusteru

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

Než přejdete na další fázi, spusťte testy a ověření, abyste měli jistotu, že můžete 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. Toto 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 verze Canary, budou vyžadovat další proces a potenciálně nástroje. Flagger je oblíbené opensourcové řešení, které pomáhá řešit vaše 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í popsaných v architektuře dobře architektuře pro AKS. Pomocí cenové kalkulačky Azure můžete odhadnout náklady na služby používané v architektuře. Další osvědčené postupy jsou popsané v části Optimalizace nákladů v architektuře Microsoft Azure.

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

Pokud chcete zkontrolovat aspekty správy nákladů specifické pro úlohy založené na Windows, které jsou součástí kontejnerů Windows v referenční architektuře standardních hodnot AKS, přečtěte si doprovodný článek.

Zřízení

• V nasazení, správě a provozu clusteru Kubernetes nejsou spojené žádné náklady. Jaký vliv mají náklady na 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ů. Skladová položka 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í.

• Pro produkční úlohy přidejte smlouvu SLA o době provozu. Existují však ú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žby je například dostatečný. Pokud ji vaše úloha podporuje, zvažte také použití vyhrazených fondů spotových uzlů, na kterých běží spotové virtuální počítače.

  V případě 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.

• Místo toho, abyste začali s nadlimitovaným clusterem podle potřeb škálování, zřiďte cluster s minimálním počtem uzlů a povolte automatickému škálování clusteru monitorovat a rozhodovat o velikosti.

• Nastavte požadavky a omezení podů tak, aby Kubernetes přiděloval prostředky uzlů s vyšší hustotou, aby se hardware využíval ke kapacitě.

• Povolení diagnostiky v clusteru může zvýšit náklady.

• Pokud se očekává, že vaše úloha existuje po dlouhou dobu, můžete se zavázat k rezervovaným instancím virtuálních počítačů na jeden nebo tři roky, abyste snížili náklady na uzly. Další informace najdete v tématu Rezervované virtuální počítače.

• Při vytváření fondů uzlů používejte značky. Značky jsou užitečné při vytváření vlastních sestav ke sledování účtovaných nákladů. Značky umožňují sledovat celkový počet výdajů a mapovat případné náklady 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ů.

• Přenosy dat mezi zónami dostupnosti v oblasti nejsou bezplatné. Pokud je vaše úloha více oblastí nebo existují přenosy napříč zónami dostupnosti, pak počítejte s dalšími náklady na šířku pásma. Další informace najdete v tématu Provoz napříč fakturačními zónami a oblastmi.

• Vytvářejte rozpočty, které budou v rámci omezení nákladů identifikovaných organizací. Jedním ze způsobů je vytváření rozpočtů prostřednictvím služby Azure 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

Pokud chcete monitorovat náklady na celý cluster a náklady na výpočetní prostředky, shromážděte také informace o úložišti, šířce pásma, bráně firewall a protokolech. Azure poskytuje různé řídicí panely pro monitorování a analýzu nákladů:

• Azure Advisor

• Azure Cost Management

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

Pokud chcete učinit rozhodnutí řízená daty, nastavte, které prostředky (členitá úroveň) mají největší náklady. Také dobře rozumí měřičům, které se používají k výpočtu využití jednotlivých prostředků. Analýzou metrik můžete určit, jestli je například platforma příliš velká. 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 detekovali a odebrali nevyužité uzly ve fondu uzlů.

• 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 navíc ve vašem clusteru nejsou naplánované žádné úlohy, zvažte použití funkce AKS Start/Stop 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

Pokračujte ve studiu základní architektury AKS:

• Další informace o hostování mikroslužeb na standardních hodnotách AKS najdete v tématu Architektura mikroslužeb Advanced Azure Kubernetes Service (AKS).
• Pokud chcete nasadit směrný plán AKS napříč několika oblastmi, přečtěte si základní hodnoty AKS pro clustery s více oblastmi.
• Pokud chcete nasadit směrný plán AKS do prostředí PCI-DSS 3.2.1, přečtěte si článek o regulovaném clusteru AKS pro PCI-DSS 3.2.1.
• Další informace o aspektech přidání kontejnerů Windows do referenční architektury najdete v doprovodném článku: Kontejnery Windows v referenční architektuře standardních hodnot AKS

Další informace o AKS

• Projděte si plán produktu AKS, viz Přehled služby Azure Kubernetes Service na GitHubu.
• Pokud potřebujete aktualizační program v Kubernetes, dokončete úvod do Kubernetes a vyvíjejte a nasazujte aplikace ve studijních programech Kubernetes .

Související prostředky

Projděte si následující související příručky:

• Přehled dobře architektuře Azure pro Azure Kubernetes Service (AKS)
• Akcelerátor cílové zóny AKS, což je implementace na podnikové úrovni založená na této architektuře. Akcelerátor vám pomůže nastavit prostředí Azure konzistentním a opakovatelném způsobem pomocí infrastruktury jako kódu (IaC) pro nasazení služby Azure Kubernetes Service (AKS).
• Průvodce každodenními operacemi služby Azure Kubernetes Services (AKS)

Projděte si následující související architektury:

• Architektura mikroslužeb ve službě Azure Kubernetes Service
• Použití služby Azure Firewall k ochraně clusteru Azure Kubernetes Service (AKS)
• GitOps pro Azure Kubernetes Service
• Streamování dat pomocí AKS