Ausführen von Windows-Containern auf AKS

Dieser Artikel ist als eine Erweiterung zur AKS-Baselinearchitektur gedacht, die eine gründliche Überprüfung der empfohlenen Konfigurationen für die Bereitstellung eines AKS-Clusters in einer Produktionsumgebung bietet. Der Schwerpunkt dieses Artikels ist es, Anleitungen für die Bereitstellung von Windows-Containern in AKS zu bieten. Daher konzentriert sich dieser Artikel auf die Konfigurationen, die für die Bereitstellung von Windows in AKS spezifisch sind, und Sie sollten sich Konfigurationen, die in der AKS Baseline-Dokumentation bereits beschrieben sind, auf diese Dokumentation beziehen.

Informationen zur Referenzimplementierung, die mit dieser Referenzarchitektur verbunden ist, finden Sie im GitHub-Projekt für AKS Windows-Baseline, einschließlich Beispielcode für die Bereitstellung.

Netzwerkentwurf.

Der in dieser Architektur verwendete Netzwerkentwurf basiert auf dem Entwurf, der in der AKS-Baselinearchitektur verwendet wird, und teilt daher alle Kernkomponenten mit diesem Entwurf, mit Ausnahme der folgenden Änderungen.

• Active Directory-Domänencontroller wurden hinzugefügt, um die Windows-basierten Workloads zu unterstützen.
• Die Lösung für eingehenden Datenverkehr in dieser Architektur verwendet Azure Front Door (AFD) und Microsoft Entra-Anwendungsproxy anstelle von Azure-App Gateway, das in der AKS-Baselinearchitektur verwendet wird.

Entwurf für eingehenden Datenverkehr

Komponenten:

• Azure Front Door mit WAF: AFDS ist der öffentliche Eingangspunkt für die Apps, die im AKS-Cluster gehostet werden. AFDS Premium wird in diesem Design verwendet, da es die Verwendung von Private Link ermöglicht, was den internen App-Datenverkehr für private Netzwerke sperrt und so die höchste Ebene an Sicherheit bietet. Web Application Firewall (WAF) schützt vor gängigen Exploits und Sicherheitsrisiken von Webanwendungen.
• Microsoft Entra-Anwendungsproxy: Diese Komponente dient als zweiter Eingangspunkt vor dem internen Lastenausgleich, der von AKS verwaltet wird. Microsoft Entra ID ist für die Vorauthentifizierung von Benutzer*innen aktiviert und verwendet eine Richtlinie für bedingten Zugriff, um nicht autorisierte IP-Bereiche (der Anwendungsproxy sieht die IP-Adresse des ursprünglichen Clients, die mit der Richtlinie für bedingten Zugriff verglichen wird) und Benutzer*innen am Zugriff auf die Website zu hindern. Dies ist die einzige Möglichkeit, Kerberos-Authentifizierungsanforderungen weiterzuleiten, während ein Azure-Dienst verwendet wird, der WAF unterstützt. Eine detaillierte Beschreibung zum Bereitstellen des einmaligen Anmeldens für von einem Anwendungsproxy geschützte Apps finden Sie unter Eingeschränkte Kerberos-Delegierung für einmaliges Anmelden (Single Sign-On, SSO) für Ihre Apps mit Anwendungsproxy
• Interner Lastenausgleich: Verwaltet von AKS. Dieses Lastenausgleichsmodul macht den Eingangscontroller über eine private statische IP-Adresse verfügbar. Er dient als einziger Kontaktpunkt, der eingehende HTTP-Anforderungen empfängt.
• In dieser Architektur werden keine Eingangsdatencontroller (wie z. B. Nginx) im Cluster verwendet.

Um diesen Entwurf zu implementieren, muss AFDS so konfiguriert werden, dass die Anwendungsproxy-URL verwendet wird, die erstellt wird, wenn die App in diesem Dienst veröffentlicht wird. Diese Konfiguration leitet eingehenden Datenverkehr an den Proxy weiter und ermöglicht die Vorauthentifizierung.

Netzwerktopologie

Das folgende Diagramm zeigt den in dieser Architektur verwendeten Hub-Spoke-Netzwerkentwurf.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Topologie des Knotenpools

Diese Architektur verwendet drei Knotenpools: Einen Systemknotenpool unter Linux, einen Benutzerknotenpool unter Linux und einen Benutzerknotenpool unter Windows. Die Windows- und Linux-Benutzerknotenpools werden für Workloads verwendet, während der Systemknotenpool für alle Konfigurationen auf Systemebene wie z. B. CoreDNS verwendet wird.

Eingehender Datenverkehrsfluss

1. Der Client sendet eine HTTPS-Anforderung an den Domänennamen: bicycle.contoso.com. Dieser Name ist mit dem DNS-A-Eintrag für die öffentliche IP-Adresse von Azure Front Door verknüpft. Dieser Datenverkehr wird verschlüsselt, um sicherzustellen, dass er zwischen dem Clientbrowser und dem Gateway nicht überprüft oder geändert werden kann.
2. Azure Front Door verfügt über eine integrierte Web Application Firewall (WAF) und handelt den TLS-Handshake für bicycle.contoso.com aus, sodass nur sichere Chiffren möglich sind. Das Azure Front Door-Gateway ist ein TLS-Abschlusspunkt, da es für die Verarbeitung von WAF-Überprüfungsregeln erforderlich ist, und es führt Routingregeln aus, mit denen der Datenverkehr an das konfigurierte Back-End weitergeleitet wird. Das TLS-Zertifikat wird in Azure Key Vault gespeichert.
3. AFDS leitet die Benutzeranforderung an den Azure-Anwendungsproxy weiter. AFDS ist so konfiguriert, dass nur HTTPS-Datenverkehr zugelassen wird. Die*der Benutzer*in muss sich bei Microsoft Entra ID authentifizieren, wenn die Vorauthentifizierung aktiviert ist.
4. Der Anwendungsproxy leitet den Benutzer über den AKS-Lastenausgleich an den Back-End-App-Container weiter.

Ausgehender Datenverkehrsfluss

Alle Anleitungen im Artikel „AKS-Baseline“ gelten hier mit einer zusätzlichen Empfehlung für Windows-Workloads: Um automatische Windows Server-Updates zu nutzen, dürfen Sie die erforderlichen FQDNs in Ihrem Azure Firewall-Regelsatz nicht blockieren.

IP-Adressplanung

Im Gegensatz zu AKS-Clustern mit Linux-Knotenpools erfordern AKS-Cluster mit Windows-Knotenpools Azure CNI. Bei der Verwendung von Azure CNI kann einem Pod eine IP-Adresse aus einem virtuellen Azure-Netzwerk zugewiesen werden. Der Pod kann dann über das virtuelle Azure-Netzwerk wie jedes andere Gerät kommunizieren. Er kann über ExpressRoute oder ein VPN eine Verbindung mit anderen Pods, Peernetzwerken oder lokalen Netzwerken oder über Private Link mit anderen Azure-Diensten herstellen.

Alle Anleitungen hinsichtlich der Planung der IP-Adressen im Artikel „AKS-Baselinearchitektur“ gelten hier mit einer zusätzlichen Empfehlung: Erwägen Sie die Bereitstellung eines dedizierten Subnetzes für Ihre Domänencontroller. In Bezug auf den Windows-Knotenpool wird empfohlen, diesen logisch durch separate Subnetze von den anderen Knotenpools zu trennen.

Knotenpoolupgrade

Der Prozess für das Upgraden von Windows-Knoten ist gegenüber den Anleitungen in der Dokumentation für Azure Kubernetes Service(AKS)-Knotenimageupgrades unverändert. Sie sollten jedoch die folgenden Zeitplanunterschiede berücksichtigen, um den Rhythmus für Ihre Upgrades zu planen.

Microsoft stellt neue Windows Server-Images, einschließlich aktueller Patches, für Knoten monatlich bereit und führt kein automatisches Patchen oder Aktualisieren aus. Daher müssen Sie Ihre Knoten manuell oder programmgesteuert gemäß diesem Zeitplan aktualisieren. Wenn Sie GitHub Actions verwenden, um einen Cronjob zu erstellen, der nach einem Zeitplan ausgeführt wird, können Sie monatliche Upgrades programmgesteuert planen. Die Anleitung in der oben verlinkten Dokumentation spiegelt Linux-Knotenprozesse wider, aber Sie können die YAML-Datei aktualisieren, um Ihren Cron-Zeitplan so festzulegen, dass er monatlich statt zweiwöchentlich ausgeführt wird. Sie müssen auch den Parameter „runs-on“ in der YAML-Datei in „windows-latest“ ändern, um sicherzustellen, dass Sie ein Upgrade auf das neueste Windows-Serverimage durchführen.

Weitere Anleitungen finden Sie im Leitfaden des AKS-Operators zum Patchen und Aktualisieren von Workerknoten.

Computeaspekte

Die größeren Imagegrößen, die serverbasierten Windows-Images zugeordnet sind, erfordern die Bereitstellung von Betriebssystemdatenträgern mit der richtigen Größe in Ihrem Knotenpool. Die Verwendung kurzlebiger Betriebssystemdatenträger wird weiterhin für alle Knoten empfohlen, einschließlich Windows. Stellen Sie daher sicher, dass Sie die Größenanforderungen verstehen, die Sie bei der Planung Ihrer Bereitstellung einhalten müssen.

Identitätsverwaltung

Windows-Container können nicht in die Domäne eingebunden werden. Wenn Sie also die Active Directory-Authentifizierung und -Autorisierung benötigen, können Sie gruppenverwaltete Dienstkonten (Group Managed Service Accounts, gMSA) verwenden. Um gMSA verwenden zu können, müssen Sie das gMSA-Profil auf Ihrem AKS-Cluster aktivieren, auf dem Windows-Knoten ausgeführt werden. Eine vollständige Überprüfung der Architektur und eine Anleitung zum Aktivieren des Profils finden Sie in der gMSA AKS-Dokumentation.

Skalierung von Knoten und Pod

Die Anleitung zur automatischen Clusterskalierung ist für Windows-Container unverändert. Anleitungen finden Sie in der Dokumentation zur automatischen Clusterskalierung.

In der Baseline-Clusterdokumentation werden die Ansätze für manuelle und automatische Skalierung beschrieben, die für die Podskalierung verfügbar sind. Beide Ansätze sind für Cluster verfügbar, in denen Windows-Container ausgeführt werden, und die Anleitungen in diesem Artikel gelten im Allgemeinen auch hier.

Der Unterschied zwischen Linux- und Windows-Containern in Bezug auf Skalierungsvorgänge für Pods ist in den meisten Fällen die Größe des Images. Die größeren Imagegrößen von Windows-Containern erhöhen wahrscheinlich die benötigte Zeit, bis Skalierungsvorgänge abgeschlossen sind, und daher sollten einige Überlegungen zum Skalierungsansatz berücksichtigt werden. Dieses Szenario ist bei Legacy-.Net-Anwendungen aufgrund der Größe der .NET-Runtime üblich. Um die Verzögerungen beim Pullen des Images während der Skalierungszeiten zu verringern, können Sie ein DaemonSet verwenden, um das Image aus ACR in den Cache auf jedem Windows-Knoten zu pullen und daher die Pods mit dem vorinstallierten Image zu starten. Ab diesem Punkt müssen die Pods nur noch die für Ihre Workload definierten App-Konfigurationsprozesse durchlaufen, bevor sie online geschaltet werden.

Benchmark-Übungen sollten durchgeführt werden, um die zeitlichen Auswirkungen der Durchführung von Skalierungsvorgängen zu verstehen, und diese Daten sollten mit den Geschäftsanforderungen abgeglichen werden. Wenn Ihre Workload schneller skaliert werden muss, als dies durch die automatische Skalierung möglich ist, empfiehlt es sich, die folgende alternative Lösung für „hot spare“ (Reserve für heiße Ebene) in Betracht zu ziehen:

Sie müssen zunächst Baselinetests durchführen, um zu ermitteln, wie viele Pods Sie zu Spitzenlastzeiten und zu Zeiten mit geringer Last benötigen. Wenn diese Baseline festgelegt ist, können Sie ihre Knotenanzahl so planen, um die Gesamtanzahl der Knoten zu berücksichtigen, die Sie zu einem bestimmten Zeitpunkt zur Verfügung haben müssen. Diese Lösung umfasst die Verwendung der manuellen Skalierung für Ihren Cluster und das Festlegen der anfänglichen Anzahl von Knoten auf die erforderliche Anzahl von Knoten für Zeiten mit geringer Last. Wenn Sie sich einer Spitzenzeit nähern, müssen Sie die Anzahl der Knoten präventiv auf die Spitzenlastzeit skalieren. Im Laufe der Zeit müssen Sie Ihre Baseline regelmäßig neu festlegen, um Änderungen beim App-Verbrauch oder bei anderen geschäftlichen Anforderungen Rechnung zu tragen.

Überwachung

Container unter Windows können ähnlich wie Linux-Container mit Azure Monitor und Container-Erkenntnissen überwacht werden. Daher gelten die Anleitungen im Artikel „AKS-Baseline“ in den meisten Fällen auch hier. Für die Überwachung von Container-Erkenntnissen für einen Windows Server-Cluster gelten jedoch die folgenden Einschränkungen:

• Windows bietet keine RSS-Metrik für den Arbeitsspeicher. Folglich ist für Windows-Knoten und -Container keine entsprechende Metrik verfügbar. Die Metrik Arbeitssatz ist verfügbar
• Für Windows-Knoten sind keine Informationen zur Speicherkapazität des Datenträgers verfügbar.

Sie können Container-Erkenntnisse auch ergänzen, indem Sie Datensammlungsregeln verwenden, um von Ihren Windows Server-Systemen Ereignisse und Leistungsindikatoren zu sammeln.

Richtlinienverwaltung

Alle Anleitungen für Richtlinien im Artikel „AKS-Baseline“ gelten für Windows-Workloads. Weitere, im Referenzartikel Integrierte Azure Policy-Definitionen für Azure Kubernetes Service zu findende Windows-spezifische Richtlinien, die berücksichtigt werden müssen, sind:

• Windows-Container in Kubernetes-Clustern sollten CPU und Arbeitsspeicher nicht übermäßig beanspruchen
• Windows-Container in Kubernetes-Clustern sollten nicht als ContainerAdministrator ausgeführt werden.
• Windows-Container in Kubernetes-Clustern dürfen nur mit genehmigten Benutzer- und Domänenbenutzergruppen ausgeführt werden

Clusterbootstrapping

Wie bei der Anleitung zum Cluster-Bootstrapping, die im Artikel „AKS-Baseline“ bereitgestellt ist, sollten Operatoren von Clustern auch für Windows-basierte Workloads ihren Bootstrapping-Ansatz überdenken. Die gleiche Anleitung im Artikel zur AKS-Baseline gilt auch hier.

Kostenverwaltung

Alle Anleitungen für die Kostenoptimierung im Artikel „AKS-Baseline“ gelten für Windows-Workloads. Weitere Kostenaspekte, die berücksichtigt werden sollten, sind:

• Die Lizenzierungskosten für Windows Server erhöhen die Kosten von Knoten für Ihren AKS-Cluster. Zu den Empfehlungen zur Kostenoptimierung für diesen Faktor gehören die Reservierung von Kapazität oder die Verwendung vorhandener Lizenzen, wenn Sie diese bereits für andere geschäftliche Zwecke besitzen.
  • In der Dokumentation Azure-Hybridvorteil für Windows Server (AHUB) finden Sie Informationen zu Rabatten für Ihre anwendbaren Windows Server-Lizenzen für Software Assurance (SA).
  • Anweisungen zum Anwenden der Nutzen auf neue und vorhandene Cluster finden Sie in den Häufig gestellten Fragen zu Windows Server-Containern.
• Die Größe von Windows-Containerimages kann zusätzliche Kosten für die Azure Container Registry (ACR) verursachen, die sich aus der Menge des für mehrere Images erforderlichen Speichers, der Anzahl der gleichzeitig aus der ACR pullenden Nodes und den Anforderungen an die Georeplikation ergeben.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

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

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Erfahren Sie mehr über Windows-Container

Zugehörige Ressourcen

• Erfahren Sie, wie Sie Windows-Knotenpools in einem AKS-Cluster bereitstellen