Tento článek se považuje za rozšíření architektury standardních hodnot AKS, které poskytuje důkladnou kontrolu doporučených konfigurací pro nasazení clusteru AKS do produkčního prostředí. Tento článek se zaměřuje na pokyny týkající se nasazení kontejnerů Windows v AKS. Tento článek se zaměřuje na tyto konfigurace specifické pro nasazení Windows v AKS a měli byste se vrátit do dokumentace ke standardním hodnotám AKS pro konfigurace, které už jsou zde popsané.
Návrh sítě
Návrh sítě použitý v této architektuře vychází z návrhu použitého v architektuře standardních hodnot AKS a proto sdílí všechny základní komponenty s tímto návrhem s výjimkou následujících změn.
- Řadiče domény služby Active Directory byly přidány pro podporu úloh založených na Windows.
- Řešení příchozího přenosu dat v této architektuře využívá proxy aplikací Azure Front Door (AFD) a Microsoft Entra místo služby Aplikace Azure Gateway, která se používá v architektuře standardních hodnot AKS.
Poznámka:
Migrace úloh Windows do AKS obvykle nezahrnuje velké refaktoringové úsilí a jako takové úlohy můžou používat funkce, které byly poměrně snadné implementovat místně, ale představují výzvu v Azure. Jedním z příkladů je aplikace, která používá ověřování gMSA a Kerberos. Jedná se o běžný případ použití, a proto tato architektura vede s komponentami, které řeší potřeby těchto úloh. Konkrétně použití proxy aplikací, které frontuje AFD jako součást cesty příchozího přenosu dat. Pokud vaše úloha tuto podporu nepotřebuje, můžete postupovat podle stejných pokynů jako v směrném plánu AKS pro příchozí přenos dat.
Návrh příchozího přenosu dat
Komponenty:
- Azure Front Door s WAF: AFD je veřejně přístupný bod příchozího přenosu dat pro aplikace hostované v clusteru AKS. AFD Premium se v tomto návrhu používá, protože umožňuje používat Službu Private Link, která zamkne interní provoz aplikací do privátních sítí a poskytuje nejvyšší úroveň zabezpečení. Firewall webových aplikací (WAF) chrání před běžným zneužitím a ohrožením zabezpečení webových aplikací.
- Proxy aplikace Microsoft Entra: Tato komponenta slouží jako druhý bod příchozího přenosu dat před interním nástrojem pro vyrovnávání zatížení spravovaným službou AKS. Má povolené ID Microsoft Entra pro předběžné ověření uživatelů a používá zásadu podmíněného přístupu k zabránění neautorizovanému rozsahu IP adres (proxy aplikace vidí původní IP adresu klienta, kterou porovnává se zásadami podmíněného přístupu) a uživatelům v přístupu k webu. Toto je jediný způsob, jak směrovat žádosti o ověřování protokolem Kerberos při používání služby Azure, která podporuje WAF. Podrobný popis poskytování jednotného přihlašování k aplikacím chráněným proxy aplikací najdete v tématu Omezené delegování protokolu Kerberos pro jednotné přihlašování k vašim aplikacím pomocí proxy aplikací
- Interní nástroj pro vyrovnávání zatížení: Spravuje 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í požadavky HTTP.
- V této architektuře se nepoužívají žádné kontrolery příchozího přenosu dat v clusteru (například Nginx).
Aby bylo možné tento návrh implementovat, musí být služba AFD nakonfigurovaná tak, aby používala adresu URL proxy aplikací, která se vytvoří při publikování aplikace v této službě. Tato konfigurace směruje příchozí provoz na proxy server a umožňuje provést předběžné ověření.
Poznámka:
Zachování zdrojových IP adres klienta se nepodporuje, takže architekti aplikací by měli naplánovat alternativní míry pro externalizaci této logiky mimo cluster pro aplikace, které závisí na zdrojové IP adrese.
Topologie sítě
Následující diagram znázorňuje návrh hvězdicové sítě, který se používá v této architektuře.
Stáhněte si soubor aplikace Visio s touto architekturou.
Topologie fondu uzlů
Tato architektura používá tři fondy uzlů: fond systémových uzlů se systémem Linux, fond uzlů uživatele se systémem Linux a fond uzlů uživatele se systémem Windows. Fondy uzlů uživatelů windows a Linuxu se používají pro úlohy, zatímco fond systémových uzlů se používá pro všechny konfigurace na úrovni systému, jako je CoreDNS.
Tok příchozího přenosu dat
- 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 pro veřejnou IP adresu služby Azure Front Door. Tento provoz je šifrovaný, aby se zajistilo, že se provoz mezi klientským prohlížečem a bránou nedá zkontrolovat ani změnit. - Azure Front Door má integrovaný firewall webových aplikací (WAF) a vyjednává metodu handshake protokolu TLS, která
bicycle.contoso.comumožňuje pouze zabezpečené šifry. Azure Front Door 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. - AFD směruje požadavek uživatele na proxy Aplikace Azure lication. Služba AFD je nakonfigurovaná tak, aby povolovala jenom provoz HTTPS. Pokud je povolené předběžné ověřování, musí se uživatel ověřit pomocí ID Microsoft Entra.
- Proxy aplikace přesměruje uživatele do kontejneru back-endové aplikace prostřednictvím nástroje pro vyrovnávání zatížení AKS.
Poznámka:
Při rozhodování o zabezpečení provozu typu pod-to-pod můžete vynutit kompletní provoz TLS na každém segmentu směrování, ale zvažte měření výkonu, latence a provozního dopadu. U většiny clusterů s jedním tenantem, které mají správné řídicí roviny RBAC a vyspělé postupy životního cyklu vývoje softwaru, stačí vynutit šifrování kontroleru příchozího přenosu dat a chránit back-end pomocí firewallu webových aplikací (WAF). Tato konfigurace 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šechny pokyny uvedené v článku Standardní hodnoty AKS platí tady s dalším doporučením pro úlohy Windows: Pokud chcete využít výhod automatických aktualizací Windows Serveru, nesmíte v sadě pravidel služby Azure Firewall blokovat požadované plně kvalifikované názvy domén .
Poznámka:
Použití samostatných fondů uzlů pro úlohy založené na Linuxu a Windows vyžaduje použití selektoru uzlů, aby se zajistilo, že při nasazení dané úlohy se nasadí do příslušného fondu uzlů na základě typu úlohy.
Plánování IP adres
Na rozdíl od clusterů AKS s fondy uzlů s Linuxem vyžadují clustery AKS s fondy uzlů Windows Azure CNI. Použití Azure CNI umožňuje přiřazení IP adresy podu z virtuální sítě Azure. Pod pak může komunikovat přes azure Virtual Network stejně jako jakékoli jiné zařízení. Může se připojit k jiným podům, k partnerským sítím nebo místním sítím pomocí ExpressRoute nebo VPN nebo k jiným službám Azure pomocí služby Private Link.
Všechny pokyny týkající se plánování IP adres uvedených v článku o architektuře standardních hodnot AKS platí tady s jedním dalším doporučením: Zvažte zřízení vyhrazené podsítě pro vaše řadiče domény. Pokud jde o fond uzlů Windows, doporučujeme oddělit ho od ostatních fondů uzlů logicky prostřednictvím samostatných podsítí.
Upgrade fondu uzlů
Proces upgradu uzlů Windows se nezmění z pokynů uvedených v dokumentaci k upgradu image uzlu Azure Kubernetes Service (AKS), ale při plánování četnosti upgradu byste měli zvážit následující rozdíly v plánu.
Microsoft poskytuje nové image Windows Serveru, včetně aktuálních oprav, pro uzly měsíčně a neprovádí automatické opravy ani aktualizace. Proto musíte uzly aktualizovat ručně nebo programově podle tohoto plánu. Použití GitHub Actions k vytvoření úlohy cron, která běží podle plánu, umožňuje programově naplánovat měsíční upgrady. Pokyny uvedené v dokumentaci uvedené výše odrážejí procesy uzlů Linuxu, ale můžete soubor YAML aktualizovat tak, aby se plán cron spouštěl měsíčně, a ne na týden. Budete také muset změnit parametr "run-on" v souboru YAML na "windows-latest", abyste se ujistili, že upgradujete na nejnovější image Windows Serveru.
Další pokyny najdete v průvodci operátorem AKS o opravách pracovních uzlů a aktualizaci .
Poznámka:
Clustery musí být upgradovány před upgradem uzlů a fondů uzlů. Pokud chcete provést upgrade, postupujte podle pokynů k upgradům clusteru.
Důležité informace o výpočetních prostředcích
Větší velikosti imagí přidružených k imagím windows serveru vyžadují nasazení disků operačního systému s odpovídající velikostí ve fondu uzlů. Použití dočasných disků s operačním systémem se stále doporučuje pro všechny uzly, včetně Windows, abyste porozuměli požadavkům na velikost, které musíte dodržovat při plánování nasazení.
Správa identit
Kontejnery Windows nemohou být připojené k doméně, takže pokud potřebujete ověřování a autorizaci služby Active Directory, můžete použít účty spravované služby skupiny (gMSA). Pokud chcete použít gMSA, musíte v clusteru AKS s uzly Windows povolit profil gMSA. Úplný přehled architektury a průvodce povolením profilu najdete v dokumentaci gMSA AKS.
Škálování uzlů a podů
Pokyny k automatickému škálování clusteru se pro kontejnery Windows nemění. Pokyny najdete v dokumentaci k automatickému škálování clusteru.
Základní dokumentace ke clusteru popisuje přístupy ručního a automatického škálování, které jsou k dispozici pro škálování podů. Oba přístupy jsou k dispozici pro clustery s kontejnery Windows a pokyny uvedené v tomto článku také obecně platí.
Rozdíly mezi kontejnery Linuxu a Windows s ohledem na operace škálování podů jsou ve většině případů velikost image. Větší velikosti imagí kontejnerů Windows pravděpodobně zvětší dobu, po kterou se operace škálování dokončí, a proto je potřeba vzít v úvahu některé aspekty přístupu ke škálování. Tento scénář je běžný u starších aplikací .NET kvůli velikosti modulu runtime .NET. Pokud chcete zmírnit zpoždění při stahování image v době škálování, můžete pomocí daemonSet stáhnout image z ACR do mezipaměti na všech uzlech Windows a tudíž aktivovat pody s předem načtenou imagí. Z tohoto okamžiku by pody potřebovaly jenom projít procesy konfigurace aplikace definované pro vaši úlohu, než se přenesou do režimu online.
Srovnávací cvičení by se měla provést, aby bylo možné porozumět časovému dopadu provádění operací škálování a tato data by se měla zvážit oproti obchodním požadavkům. Pokud vaše úloha potřebuje škálovat rychleji, než je možné prostřednictvím automatického škálování, doporučujeme zvážit následující alternativní řešení "hot spare":
Nejprve budete muset provést základní testování, abyste zjistili, kolik podů budete muset spustit ve špičce a v době načítání mimo špičku. S tímto směrným plánem můžete naplánovat počet uzlů tak, aby počítaly s celkovým počtem uzlů, které budete muset mít kdykoli k dispozici. Toto řešení zahrnuje použití ručního škálování clusteru a nastavení počátečního počtu uzlů na požadovaný počet uzlů mimo špičku. Když přiblížíte časové období špičky, budete muset předem škálovat na časový počet uzlů ve špičce. V době, kdy to bude potřeba, budete muset pravidelně navazovat směrný plán, aby se zohlednily změny využití aplikací nebo jiných obchodních požadavků.
Sledování
Kontejnery se systémem Windows je možné monitorovat pomocí služby Azure Monitor a Container Insights, podobně jako kontejnery Linuxu. Pokyny uvedené v článku O směrném plánu AKS jsou uvedené i ve většině případů. Monitorování Služby Container Insights pro cluster s Windows Serverem má ale následující omezení:
- Systém Windows nemá metriku RSS paměti. V důsledku toho není k dispozici pro uzly a kontejnery Windows. K dispozici je metrika Pracovní sada .
- Informace o kapacitě diskového úložiště nejsou dostupné pro uzly Windows.
Container Insights můžete také komplimentovat pomocí pravidel shromažďování dat ke shromažďování událostí a čítačů výkonu ze systémů Windows Server.
Poznámka:
Přehledy kontejnerů pro operační systém Windows Server 2022 jsou ve verzi Public Preview.
Správa zásad
Všechny pokyny k zásadám, které najdete v článku o standardních hodnotách AKS, platí pro úlohy Windows. Další zásady specifické pro Windows, které najdete v předdefinovaných definicích azure Kubernetes Service, najdete v referenčním článku o službě Azure Kubernetes Service :
- Kontejnery clusteru Kubernetes pro Windows by neměly přepočítat procesor a paměť.
- Kontejnery clusteru Kubernetes pro Windows by neměly běžet jako ContainerAdministrator
- Kontejnery clusteru Kubernetes s Windows by se měly spouštět jenom se schválenými uživateli a doménovými skupinami uživatelů.
Spouštění clusteru
Stejně jako u pokynů ke spuštění clusteru, které jsou uvedeny v článku Standardní hodnoty AKS, by operátoři clusteru měli zvážit také přístup při spouštění úloh založených na Windows. Stejné pokyny uvedené v článku Standardní hodnoty AKS platí i tady.
Správa nákladů
Všechny pokyny pro optimalizaci nákladů uvedené v článku Standardní hodnoty AKS platí pro úlohy Windows. Další aspekty nákladů, které by se měly zohlednit, jsou:
- Licenční náklady na Windows Server zvyšují náklady na uzly pro váš cluster AKS. Doporučení pro optimalizaci nákladů pro tento faktor zahrnují rezervaci kapacity nebo použití stávajících licencí, pokud už je máte pro jiné obchodní účely.
- Informace o slevách pro příslušné licence Windows Serveru najdete v dokumentaci k Zvýhodněné hybridní využití Azure pro Windows Server (AHUB).
- Pokyny k použití výhod pro nové a existující clustery najdete v nejčastějších dotazech k kontejnerům Windows Serveru.
- Velikost imagí kontejnerů Windows může mít další náklady na Službu Azure Container Registry (ACR) kvůli množství úložiště požadovanému pro více imagí, počet souběžných uzlů, které se načítá z požadavků na ACR a geografickou replikaci.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autoři:
- Isabelle Bersano | Architekt cloudového řešení
- Akshay Nimbalkar | Hlavní architekt cloudového řešení
- Clayton Siemens | Hlavní vývojář obsahu
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
- Další informace o kontejnerech Windows
Související prostředky
- Zjistěte, jak nasadit fondy uzlů Windows v clusteru AKS.