Köra Windows-containrar på AKS

Den här artikeln är avsedd att betraktas som ett tillägg till AKS-baslinjearkitekturen, som ger en grundlig genomgång av de rekommenderade konfigurationerna för att distribuera ett AKS-kluster till en produktionsmiljö. Fokus i den här artikeln ligger på att ge vägledning i förhållande till distribution av Windows-containrar på AKS. Därför fokuserar den här artikeln på de konfigurationer som är specifika för att distribuera Windows på AKS och du bör gå tillbaka till AKS-baslinjedokumentationen för konfigurationer som redan beskrivs där.

Se GITHub-projektet för AKS Windows-baslinje för att granska referensimplementeringen som är associerad med den här referensarkitekturen, inklusive exempeldistributionskod.

Nätverksdesign

Nätverksdesignen som används i den här arkitekturen baseras på den design som används i AKS-baslinjearkitekturen och delar därför alla kärnkomponenter med den designen förutom följande ändringar.

• Active Directory-domänkontrollanter har lagts till för att stödja Windows-baserade arbetsbelastningar.
• Ingresslösningen i den här arkitekturen använder Azure Front Door (AFD) och Microsoft Entra-programproxy (AAP) i stället för Azure App Gateway, som används i AKS-baslinjearkitekturen.

Ingångsdesign

Komponenter:

• Azure Front Door med WAF: AFD är den offentliga ingresspunkten för de appar som finns i AKS-klustret. AFD Premium används i den här designen eftersom det tillåter användning av Private Link, som låser intern apptrafik till privata nätverk, vilket ger den högsta säkerhetsnivån. Web Application Firewall (WAF) skyddar mot vanliga sårbarheter och sårbarheter för webbprogram.
• Microsoft Entra-programproxy: Den här komponenten fungerar som den andra ingresspunkten framför den interna lastbalanseraren som hanteras av AKS. Det har Microsoft Entra-ID aktiverat för förautentisering av användare och använder en princip för villkorlig åtkomst för att förhindra obehöriga IP-intervall (AAP ser den ursprungliga klient-IP-adressen, som den jämför med principen för villkorlig åtkomst) och användare från att komma åt webbplatsen. Det här är det enda sättet att dirigera Kerberos-autentiseringsbegäranden när du använder en Azure-tjänst som stöder WAF. En detaljerad beskrivning av hur du ger enkel inloggningsåtkomst till Programproxy skyddade appar finns i Kerberos-begränsad delegering för enkel inloggning (SSO) till dina appar med Programproxy
• Intern lastbalanserare: Hanteras av AKS. Den här lastbalanseraren exponerar ingresskontrollanten via en privat statisk IP-adress. Den fungerar som en enda kontaktpunkt som tar emot inkommande HTTP-begäranden.
• Inga inkommande styrenheter i klustret (till exempel Nginx) används i den här arkitekturen.

För att kunna implementera den här designen måste AFD konfigureras för att använda den Programproxy URL som skapas när appen publiceras i den tjänsten. Den här konfigurationen dirigerar inkommande trafik till proxyn och tillåter förautentisering.

Nätverkstopologi

Diagrammet nedan visar nätverksdesignen hub-spoke som används i den här arkitekturen.

Ladda ned en Visio-fil med den här arkitekturen.

Topologi för nodpool

Den här arkitekturen använder tre nodpooler: En systemnodpool som kör Linux, en användarnodpool som kör Linux och en användarnodpool som kör Windows. Användarnodpoolerna i Windows och Linux används för arbetsbelastningar medan systemnodpoolen används för alla konfigurationer på systemnivå, till exempel CoreDNS.

Inkommande trafikflöde

1. Klienten skickar en HTTPS-begäran till domännamnet: bicycle.contoso.com. Det namnet är associerat med DNS A-posten för den offentliga IP-adressen för Azure Front Door. Den här trafiken är krypterad för att se till att trafiken mellan klientwebbläsaren och gatewayen inte kan inspekteras eller ändras.
2. Azure Front Door har en integrerad brandvägg för webbprogram (WAF) och förhandlar om TLS-handskakningen för bicycle.contoso.com, vilket endast tillåter säkra chiffer. Azure Front Door Gateway är en TLS-avslutningspunkt eftersom det krävs för att bearbeta WAF-inspektionsregler och köra routningsregler som vidarebefordrar trafiken till den konfigurerade serverdelen. TLS-certifikatet lagras i Azure Key Vault.
3. AFD dirigerar användarbegäran till Azure Programproxy. AFD har konfigurerats för att endast tillåta HTTPS-trafik. Användaren måste autentisera med Microsoft Entra-ID om förautentisering är aktiverat.
4. Appproxyn dirigerar användaren till serverdelsappcontainern via AKS-lastbalanseraren.

Utgående trafikflöde

All vägledning som finns i aks-baslinjeartikeln gäller här med en ytterligare rekommendation för Windows-arbetsbelastningar: För att kunna dra nytta av automatiska Windows Server-uppdateringar får du inte blockera de nödvändiga FQDN:erna i din Azure Firewall-regeluppsättning.

Planering av IP-adress

Till skillnad från AKS-kluster med Linux-nodpooler kräver AKS-kluster med Windows-nodpooler Azure CNI. Med Azure CNI kan en podd tilldelas en IP-adress från ett virtuellt Azure-nätverk. Podden kan sedan kommunicera via Azure Virtual Network precis som alla andra enheter. Den kan ansluta till andra poddar, till peer-kopplade nätverk eller lokala nätverk med hjälp av ExpressRoute eller ett VPN eller till andra Azure-tjänster med Private Link.

All vägledning i förhållande till planeringen av IP-adresserna som anges i artikeln om AKS-baslinjearkitektur gäller här, med ytterligare en rekommendation: överväg att etablera ett dedikerat undernät för domänkontrollanterna. När det gäller Windows-nodpoolen rekommenderar vi att du separerar den från de andra nodpoolerna logiskt via separata undernät.

Uppgradering av nodpool

Processen för att uppgradera Windows-noder ändras inte från vägledningen i dokumentationen om uppgradering av azure Kubernetes Service-noder (AKS), men du bör överväga följande schemaskillnader för att planera uppgraderingens takt.

Microsoft tillhandahåller nya Windows Server-avbildningar, inklusive uppdaterade korrigeringar, för noder varje månad och utför inga automatiska korrigeringar eller uppdateringar. Därför måste du uppdatera noderna manuellt eller programmatiskt enligt det här schemat. Med GitHub Actions för att skapa ett cron-jobb som körs enligt ett schema kan du schemalägga månatliga uppgraderingar programmatiskt. Vägledningen i dokumentationen som länkas ovan återspeglar Linux-nodprocesser, men du kan uppdatera YAML-filen för att ange att cron-schemat ska köras varje månad i stället för varannan vecka. Du måste också ändra parametern "runs-on" i YAML-filen till "windows-latest" för att säkerställa att du uppgraderar till den senaste Windows Server-avbildningen.

Mer information finns i AKS-operatorns guide om korrigering och uppdatering av arbetsnoder.

Beräkningsöverväganden

De större avbildningsstorlekarna som är associerade med Windows serverbaserade avbildningar kräver distribution av operativsystemdiskar med lämplig storlek i nodpoolen. Användning av tillfälliga OS-diskar rekommenderas fortfarande för alla noder, inklusive Windows, så se till att du förstår de storlekskrav som du måste följa när du planerar distributionen.

Identitetshantering

Windows-containrar kan inte vara domänanslutna, så om du behöver Active Directory-autentisering och auktorisering kan du använda grupphanterade tjänstkonton (gMSA). För att kunna använda gMSA måste du aktivera gMSA-profilen i ditt AKS-kluster som kör Windows-noder. Se gMSA AKS-dokumentationen för en fullständig granskning av arkitekturen och en guide om hur du aktiverar profilen.

Skalning av noder och poddar

Vägledningen för autoskalning av kluster ändras inte för Windows-containrar. Mer information finns i dokumentationen för autoskalning av kluster.

Dokumentationen om baslinjeklustret beskriver de manuella och automatiska skalningsmetoder som är tillgängliga för poddskalning. Båda metoderna är tillgängliga för kluster som kör Windows-containrar och vägledningen i den artikeln gäller vanligtvis även här.

Vad som skiljer sig mellan Linux- och Windows-containrar när det gäller poddskalningsåtgärder är storleken på avbildningen i de flesta fall. De större avbildningsstorlekarna för Windows-containrar kommer sannolikt att öka tiden för skalningsåtgärder att slutföras och därför bör vissa överväganden om skalningsmetoden tas. Det här scenariot är vanligt med äldre .NET-program på grund av storleken på .NET-körningen. För att minska fördröjningarna i att dra ned avbildningen under skalningstiderna kan du använda en DaemonSet för att hämta avbildningen från ACR till cachelagring på varje Windows-nod och därför starta poddarna med avbildningen förinstallerad. Då behöver poddarna bara köra igenom de appkonfigurationsprocesser som definierats för din arbetsbelastning innan de tas online.

Benchmarking-övningar bör utföras för att förstå tidseffekten av att utföra skalningsåtgärder och dessa data bör vägas mot affärskraven. Om din arbetsbelastning behöver skalas snabbare än vad som är möjligt via automatisk skalning rekommenderar vi att du överväger följande alternativa lösning för "frekvent reservlösning":

Du måste först utföra baslinjetestning för att identifiera hur många poddar du behöver köra vid tider med hög belastning och låg belastning. Med den här baslinjen upprättad kan du planera antalet noder för att ta hänsyn till det totala antalet noder som du behöver ha tillgängliga vid en viss tidpunkt. Den här lösningen innebär att du använder manuell skalning för klustret och anger det ursprungliga antalet noder till det lågtrafikade antalet noder som krävs. När du närmar dig en tidsperiod med hög belastning måste du i förebyggande syfte skala till antalet noder med hög belastning. Med tiden måste du regelbundet återupprätta baslinjen för att ta hänsyn till ändrade appanvändningar eller andra affärskrav.

Övervakning

Containrar som kör Windows kan övervakas med Azure Monitor och Container Insights, ungefär som Linux-containrar. Därför gäller vägledningen som finns i AKS-baslinjeartikeln även här för det mesta. Container Insights-övervakning för ett Windows Server-kluster har dock följande begränsningar:

• Windows har inget RSS-mått för minne. Därför är den inte tillgänglig för Windows-noder och containrar. Måttet Arbetsuppsättning är tillgängligt
• Information om disklagringskapacitet är inte tillgänglig för Windows-noder.

Du kan också komplettera Container Insights med hjälp av datainsamlingsregler för att samla in händelser och prestandaräknare från dina Windows Server-system.

Principhantering

All principvägledning som finns i AKS-baslinjeartikeln gäller för Windows-arbetsbelastningar. Ytterligare Windows-specifika principer som finns i den inbyggda Azure Policy-definitionen för Azure Kubernetes Service-referensartikeln är:

• Kubernetes-kluster Windows-containrar bör inte överbekräja processor och minne
• Kubernetes-kluster Windows-containrar ska inte köras som ContainerAdministrator
• Kubernetes-kluster Windows-containrar bör endast köras med godkänd användar- och domänanvändargrupp

Klusterstövlar

Precis som med vägledningen för klusterstövlar i aks-baslinjeartikeln bör klusteroperatorer även överväga sin bootstrapping-metod för Windows-baserade arbetsbelastningar. Samma vägledning som ges i AKS-baslinjeartikeln gäller även här.

Kostnadshantering

Alla riktlinjer för kostnadsoptimering som finns i AKS-baslinjeartikeln gäller för Windows-arbetsbelastningar. Andra kostnadsöverväganden som bör redovisas är:

• Licenskostnaderna för Windows Server ökar kostnaden för noder för ditt AKS-kluster. Kostnadsoptimeringsrekommendationer för den här faktorn omfattar att reservera kapacitet eller använda befintliga licenser om du redan har dem för andra affärsbruk.
  • Se dokumentationen Azure Hybrid-förmån för Windows Server (AHUB) för att lära dig mer om rabatter för dina Software Assurance-licenser (SA) gällande Windows Server-licenser.
  • Se Vanliga frågor och svar om Windows Server-containrar för instruktioner om hur du tillämpar förmånen på nya och befintliga kluster.
• Storleken på Windows-containeravbildningar kan medföra ytterligare kostnader för Azure Container Registry (ACR) på grund av mängden lagringsutrymme som krävs för flera avbildningar, antalet samtidiga noder som hämtar från kraven för ACR och geo-replikering.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Isabelle Bersano | Molnlösningsarkitekt
• Akshay Nimbalkar | Huvudarkitekt för molnlösning
• Clayton Siemens | Huvudinnehållsutvecklare

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Läs mer om Windows-containrar

Relaterade resurser

• Lär dig hur du distribuerar Windows-nodpooler i ett AKS-kluster