Windows-containers uitvoeren op AKS

Dit artikel is bedoeld om te worden beschouwd als een uitbreiding op de AKS-basislijnarchitectuur, die een grondig overzicht biedt van de aanbevolen configuraties voor het implementeren van een AKS-cluster in een productieomgeving. De focus van dit artikel ligt op het bieden van richtlijnen ten opzichte van het implementeren van Windows-containers op AKS. Daarom richt dit artikel zich op die configuraties die specifiek zijn voor het implementeren van Windows op AKS. Raadpleeg de documentatie van de AKS-basislijn voor configuraties die daar al zijn beschreven.

Raadpleeg het GitHub-project AKS Windows-basislijn om de referentie-implementatie te controleren die is gekoppeld aan deze referentiearchitectuur, inclusief voorbeeldimplementatiecode.

Netwerkontwerp

Het netwerkontwerp dat in deze architectuur wordt gebruikt, is gebaseerd op het ontwerp dat wordt gebruikt in de AKS-basislijnarchitectuur en deelt daarom alle kernonderdelen met dat ontwerp, met uitzondering van de volgende wijzigingen.

• Active Directory-domeincontrollers zijn toegevoegd ter ondersteuning van de Windows-workloads.
• De oplossing voor inkomend verkeer in deze architectuur maakt gebruik van Azure Front Door (AFD) en microsoft Entra-toepassingsproxy in plaats van Azure-app Gateway, die wordt gebruikt in de AKS-basislijnarchitectuur.

Ontwerp voor inkomend verkeer

Onderdelen:

• Azure Front Door met WAF: AFD is het openbare toegangspunt voor de apps die worden gehost op het AKS-cluster. AFD Premium wordt in dit ontwerp gebruikt omdat het gebruik van Private Link, waarmee intern app-verkeer wordt vergrendeld voor privénetwerken, waardoor het hoogste beveiligingsniveau wordt geboden. Web Application Firewall (WAF) beschermt tegen veelvoorkomende aanvallen en beveiligingsproblemen van webtoepassingen.
• Microsoft Entra-toepassingsproxy: dit onderdeel fungeert als het tweede ingangspunt voor de interne load balancer die wordt beheerd door AKS. Microsoft Entra ID is ingeschakeld voor verificatie vooraf van gebruikers en maakt gebruik van beleid voor voorwaardelijke toegang om onbevoegde IP-bereiken te voorkomen (toepassingsproxy ziet het ip-adres van de oorspronkelijke client, dat wordt vergeleken met het beleid voor voorwaardelijke toegang) en gebruikers hebben toegang tot de site. Dit is de enige manier om Kerberos-verificatieaanvragen te routeren tijdens het gebruik van een Azure-service die WAF ondersteunt. Raadpleeg Kerberos Constrained Delegation voor eenmalige aanmelding voor uw apps met toepassingsproxy voor een gedetailleerde beschrijving van het bieden van toegang tot eenmalige aanmelding voor toepassingsproxy beveiligde apps
• Interne load balancer: beheerd door AKS. Deze load balancer maakt de ingangscontroller beschikbaar via een privé statisch IP-adres. Het fungeert als één contactpunt dat binnenkomende HTTP-aanvragen ontvangt.
• Er worden geen ingangscontrollers in het cluster (zoals Nginx) gebruikt in deze architectuur.

Als u dit ontwerp wilt implementeren, moet AFD worden geconfigureerd voor het gebruik van de toepassingsproxy-URL die wordt gemaakt wanneer de app in die service wordt gepubliceerd. Met deze configuratie wordt binnenkomend verkeer naar de proxy gerouteerd en kan vooraf verificatie plaatsvinden.

Netwerktopologie

In het onderstaande diagram ziet u het hub-spoke-netwerkontwerp dat in deze architectuur wordt gebruikt.

Een Visio-bestand van deze architectuur downloaden.

Topologie van knooppuntgroep

Deze architectuur maakt gebruik van drie knooppuntgroepen: een systeemknooppuntgroep met Linux, een gebruikersknooppuntgroep met Linux en een gebruikersknooppuntgroep met Windows. De Windows- en Linux-gebruikersknooppuntgroepen worden gebruikt voor workloads terwijl de systeemknooppuntgroep wordt gebruikt voor alle configuraties op systeemniveau, zoals CoreDNS.

Stroom inkomend verkeer

1. De client verzendt een HTTPS-aanvraag naar de domeinnaam: bicycle.contoso.com. Deze naam is gekoppeld aan de DNS A-record voor het openbare IP-adres van Azure Front Door. Dit verkeer wordt versleuteld om ervoor te zorgen dat het verkeer tussen de clientbrowser en gateway niet kan worden geïnspecteerd of gewijzigd.
2. Azure Front Door heeft een geïntegreerde WAF (Web Application Firewall) en onderhandelt over de TLS-handshake voor bicycle.contoso.com, waardoor alleen veilige coderingen mogelijk zijn. Azure Front Door Gateway is een TLS-beëindigingspunt, omdat het vereist is om WAF-inspectieregels te verwerken en routeringsregels uit te voeren die het verkeer doorsturen naar de geconfigureerde back-end. Het TLS-certificaat wordt opgeslagen in Azure Key Vault.
3. AFD stuurt de gebruikersaanvraag naar de Azure-toepassing Proxy. AFD is geconfigureerd om alleen HTTPS-verkeer toe te staan. De gebruiker moet worden geverifieerd met Microsoft Entra-id als verificatie vooraf is ingeschakeld.
4. De app-proxy stuurt de gebruiker naar de container van de back-end-app via de AKS-load balancer.

Uitgaande verkeersstroom

Alle richtlijnen in het artikel AKS-basislijn zijn hier van toepassing met een extra aanbeveling voor Windows-workloads: als u wilt profiteren van automatische Windows Server-updates, moet u de vereiste FQDN's niet blokkeren in uw Azure Firewall-regelset.

PLANNING van IP-adressen

In tegenstelling tot AKS-clusters met Linux-knooppuntgroepen vereisen AKS-clusters met Windows-knooppuntgroepen Azure CNI. Als u Azure CNI gebruikt, kan een pod een IP-adres uit een virtueel Azure-netwerk toewijzen. De pod kan vervolgens communiceren via het virtuele Azure-netwerk, net als elk ander apparaat. Het kan verbinding maken met andere pods, met gekoppelde netwerken of on-premises netwerken via ExpressRoute of een VPN, of met andere Azure-services met behulp van Private Link.

Alle richtlijnen ten opzichte van het plannen van de IP-adressen in het artikel over de AKS-basislijnarchitectuur zijn hier van toepassing, met één extra aanbeveling: overweeg om een speciaal subnet in te richten voor uw domeincontrollers. Wat de Windows-knooppuntgroep betreft, is het raadzaam dat u deze logisch scheidt van de andere knooppuntgroepen via afzonderlijke subnetten.

Upgrade van knooppuntgroep

Het proces voor het upgraden van Windows-knooppunten is ongewijzigd ten opzichte van de richtlijnen in de upgradedocumentatie voor AKS-knooppunten (Azure Kubernetes Service), maar u moet rekening houden met de volgende planningsverschillen om uw upgradefrequentie te plannen.

Microsoft biedt nieuwe Windows Server-installatiekopieën, waaronder bijgewerkte patches, voor knooppunten maandelijks en voert geen automatische patches of updates uit. Als zodanig moet u uw knooppunten handmatig of programmatisch bijwerken volgens dit schema. Door GitHub Actions te gebruiken om een cron-taak te maken die volgens een schema wordt uitgevoerd, kunt u maandelijkse upgrades programmatisch plannen. De richtlijnen in de bovenstaande documentatie weerspiegelen processen voor Linux-knooppunten, maar u kunt het YAML-bestand bijwerken om uw cron-planning zo in te stellen dat het maandelijks wordt uitgevoerd in plaats van tweewekelijks. U moet ook de parameter 'runs-on' in het YAML-bestand wijzigen in 'windows-latest' om ervoor te zorgen dat u een upgrade uitvoert naar de meest recente Windows Server-installatiekopieën.

Zie de handleiding van de AKS-operator over patching en updates voor werkknooppunten voor aanvullende richtlijnen.

Overwegingen voor berekeningen

Voor de grotere installatiekopieën die zijn gekoppeld aan installatiekopieën op basis van Windows-servers, is de implementatie van besturingssysteemschijven in uw knooppuntgroep vereist. Het gebruik van tijdelijke besturingssysteemschijven wordt nog steeds aanbevolen voor alle knooppunten, waaronder Windows, dus zorg ervoor dat u de groottevereisten begrijpt waaraan u moet voldoen bij het plannen van uw implementatie.

Identiteitsbeheer

Windows-containers kunnen niet aan een domein worden toegevoegd. Als u Active Directory-verificatie en -autorisatie nodig hebt, kunt u Beheerde serviceaccounts voor groepen (gMSA) gebruiken. Als u gMSA wilt gebruiken, moet u het gMSA-profiel inschakelen op uw AKS-cluster met Windows-knooppunten. Raadpleeg de gMSA AKS-documentatie voor een volledige beoordeling van de architectuur en een handleiding voor het inschakelen van het profiel.

Schalen van knooppunten en pods

Richtlijnen voor automatische schaalaanpassing van clusters zijn ongewijzigd voor Windows-containers. Raadpleeg de documentatie voor automatische schaalaanpassing van clusters voor hulp.

In de documentatie van het basiscluster worden de handmatige en automatische schaalaanpassingsmethoden beschreven die beschikbaar zijn voor het schalen van pods. Beide benaderingen zijn beschikbaar voor clusters met Windows-containers en de richtlijnen in dat artikel zijn hier ook algemeen van toepassing.

Wat verschilt tussen Linux- en Windows-containers met betrekking tot schaalbewerkingen voor pods is de grootte van de installatiekopieën in de meeste gevallen. De grotere afbeeldingsgrootten van Windows-containers verhogen waarschijnlijk de hoeveelheid tijd voor het voltooien van schaalbewerkingen en daarom moeten er enkele overwegingen worden genomen bij het schalen. Dit scenario is gebruikelijk bij verouderde .NET-toepassingen vanwege de grootte van de .NET-runtime. Als u de vertragingen bij het omlaag trekken van de installatiekopie tijdens schaaltijden wilt beperken, kunt u een DaemonSet gebruiken om de installatiekopie van ACR naar cache op elk Windows-knooppunt te halen en daarom de pods in te stellen met de vooraf geladen installatiekopie. Vanaf dat moment moeten de pods alleen de app-configuratieprocessen doorlopen die zijn gedefinieerd voor uw workload voordat ze online worden gebracht.

Benchmarkingoefeningen moeten worden uitgevoerd om inzicht te hebben in de tijdsimpact van het uitvoeren van schaalbewerkingen en deze gegevens moeten worden afgewogen tegen bedrijfsvereisten. Als uw werkbelasting sneller moet worden geschaald dan mogelijk is via automatisch schalen, kunt u het beste de volgende alternatieve 'hot spare'-oplossing overwegen:

U moet eerst basislijntests uitvoeren om te bepalen hoeveel pods u moet uitvoeren op piekbelastingstijden en off-peak laadtijden. Als deze basislijn tot stand is gebracht, kunt u het aantal knooppunten plannen om rekening te houden met het totale aantal knooppunten dat u op elk gewenst moment beschikbaar moet hebben. Deze oplossing omvat het gebruik van handmatig schalen voor uw cluster en het instellen van het eerste aantal knooppunten op het off-peak aantal vereiste knooppunten. Wanneer u een piekperiode nadert, moet u het aantal knooppunten vooraf schalen naar het piekbelastingstijdsaantal knooppunten. Naarmate de tijd vordert, moet u uw basislijn regelmatig opnieuw instellen om rekening te houden met het veranderen van app-gebruik of andere zakelijke vereisten.

Controleren

Containers met Windows kunnen worden bewaakt met Azure Monitor en Container Insights, net zoals Linux-containers. Daarom zijn de richtlijnen in het artikel AKS-basislijn hier ook van toepassing voor het grootste deel. Container Insights-bewaking voor een Windows Server-cluster heeft echter de volgende beperkingen:

• Windows heeft geen metrische geheugen-RSS-waarde. Als gevolg hiervan is het niet beschikbaar voor Windows-knooppunten en -containers. De metrische waarde voor de werkset is beschikbaar
• Informatie over schijfopslagcapaciteit is niet beschikbaar voor Windows-knooppunten.

U kunt Container Insights ook aanvullen met behulp van regels voor gegevensverzameling om gebeurtenissen en prestatiemeteritems van uw Windows Server-systemen te verzamelen.

Beleidsbeheer

Alle beleidsrichtlijnen in het AKS-basislijnartikel zijn van toepassing op Windows-workloads. Aanvullende Windows-specifieke beleidsregels in de ingebouwde Azure Policy-definities voor Azure Kubernetes Service-referentieartikel zijn:

• Windows-containers voor Kubernetes-clusters mogen niet te veel CPU en geheugen overschrijven
• Windows-containers voor Kubernetes-clusters mogen niet worden uitgevoerd als ContainerAdministrator
• Windows-containers voor Kubernetes-clusters mogen alleen worden uitgevoerd met goedgekeurde gebruikers- en domeingebruikersgroep

Cluster bootstrapping

Net als bij de richtlijnen voor het opstarten van clusters in het artikel AKS Baseline moeten clusteroperators ook rekening houden met hun bootstrapping-benadering voor Windows-workloads. Dezelfde richtlijnen in het artikel AKS-basislijn zijn hier ook van toepassing.

Kostenbeheer

Alle richtlijnen voor kostenoptimalisatie in het artikel AKS-basislijn zijn van toepassing op Windows-workloads. Andere kostenoverwegingen waarvoor rekening moet worden gehouden, zijn:

• De licentiekosten voor Windows Server verhogen de kosten van knooppunten voor uw AKS-cluster. Aanbevelingen voor kostenoptimalisatie voor deze factor zijn onder andere het reserveren van capaciteit of het gebruik van bestaande licenties als u deze al hebt voor andere zakelijke toepassingen.
  • Zie de documentatie van Azure Hybrid Benefit voor Windows Server (AHUB) voor meer informatie over kortingen voor uw Software Assurance (SA) toepasselijke Windows Server-licenties.
  • Zie de veelgestelde vragen over Windows Server-containers voor instructies over het toepassen van het voordeel op nieuwe en bestaande clusters.
• De grootte van Windows-containerinstallatiekopieën kan extra kosten voor Azure Container Registry (ACR) met zich meebrengen vanwege de hoeveelheid opslagruimte die nodig is voor meerdere installatiekopieën, het aantal gelijktijdige knooppunten dat wordt opgehaald uit de ACR- en geo-replicatievereisten.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

• Isabelle Bersano | Cloud Solution Architect
• Akshay Nimbalkar | Principal Cloud Solution Architect
• Clayton Siemens | Principal Content Developer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Meer informatie over Windows-containers

Verwante resources

• Meer informatie over het implementeren van Windows-knooppuntgroepen in een AKS-cluster