Wenn Sie eine Frage zu Windows Server-Containern haben, prüfen Sie, ob sie in der Liste unten beantwortet wird.
Worin besteht der Unterschied zwischen Linux- und Windows Server-Containern?
Linux- und Windows Server-Container implementieren beide ähnliche Technologien in ihrem Kernel und Kernbetriebssystemen. Der Unterschied ergibt sich aus der Plattform und Arbeitslasten, die innerhalb des Containers ausgeführt.
Wenn ein Kunde Windows Server-Container verwendet, ist eine Integration in vorhandene Windows-Technologien wie u. a. .NET, ASP.NET und PowerShell möglich.
Was sind die Voraussetzungen für die Ausführung von Containern unter Windows?
Container wurden mit Windows Server 2016 auf der Plattform eingeführt. Zum Verwenden von Containern benötigen Sie entweder Windows Server 2016, das Windows 10 Anniversary Update (Version 1607) oder höher oder Windows 10 IoT Enterprise oder höher. Weitere Informationen finden Sie in den Systemanforderungen.
Welche Windows-Betriebssysteme werden in Kubernetes unterstützt?
Die Unterstützung für Windows-Container hängt von der Kubernetes-Plattform ab, auf der sie ausgeführt werden. Azure Kubernetes Service (AKS), AKS in Azure Stack HCI und Windows Server unterstützen Windows-Knoten unter Windows Server 2019 und Windows Server 2022. Azure Kubernetes Service Edge Essentials unterstützt Windows Server 2019, Windows Server 2022 und Windows 10/11 Enterprise oder Pro. Informationen zur Kompatibilität der Windows-Containerversion finden Sie unter Versionskompatibilität von Windows-Containern.
Wie kann ich meine Windows-Knoten patchen?
Für Windows Server-Knoten in AKS, AKS in Azure Stack HCI und Windows Server muss ein Upgrade ausgeführt werden, um die neuesten Patches und Updates zu erhalten. Windows-Updates sind auf den Windows-Knoten in diesen Diensten nicht aktiviert. Beide Dienste bieten jedoch Mechanismen zum Aktualisieren der Windows-Knotenimages.
Können meine Windows Server-Container gMSA verwenden?
Ja, gMSA wird bei in die Domäne eingebundenen Windows-Workerknoten unterstützt. Weitere Informationen zur Verwendung von gMSA mit Windows-Containern finden Sie unter Vorbereiten von Windows-Knoten für gMSA.
Was sind WCOW und LCOW?
WCOW ist die Abkürzung für „Windows Containers on Windows“. LCOW ist die Abkürzung für „Linux Containers on Windows“.
Wie werden Container lizenziert? Gibt es eine Einschränkung bezüglich der Anzahl von Containern, die ich ausführen kann?
Die EULA für Windows Containerimages beschreibt ein Nutzung, die verlangt, dass der Benutzer über ein Hostbetriebssystem mit einer gültigen Lizenz verfügt. Die Anzahl der Container, die ein Benutzer ausführen darf, hängt von der Edition des Hostbetriebssystems und dem Isolationsmodus ab, mit dem ein Container ausgeführt wird, sowie davon, ob diese Container zu Entwicklungs-/Testzwecken oder in der Produktion ausgeführt werden.
| Hostbetriebssystem | Grenzwert für prozessisolierte Container | Grenzwert für Hyper-V-isolierte Container |
|---|---|---|
| Windows Server Standard | Unbegrenzt | 2 |
| Windows Server Datacenter | Unbegrenzt | Unbegrenzt |
| Windows Pro und Enterprise | Unbegrenzt (nur für Test- oder Entwicklungszwecke) | Unbegrenzt (nur für Test- oder Entwicklungszwecke) |
| Windows 10 IoT Core | Unbegrenzt* | Unbegrenzt* |
| Windows IoT Enterprise | Unbegrenzt* | Unbegrenzt* |
Die Nutzung von Windows Server-Containerimages wird durch Lesen der Anzahl der Virtualisierungsgäste bestimmt, die für die betreffende Edition unterstützt werden.
Hinweis
*Die Verwendung von Containern in einer IoT-Edition von Windows ist abhängig davon, ob Sie die kommerziellen Nutzungsbedingungen von Microsoft für Windows Core-Laufzeitimages oder der Windows IoT Enterprise-Gerätelizenz („Kommerzielle Windows IoT-Vereinbarung“) zugestimmt haben. Zusätzliche Bestimmungen und Einschränkungen in den kommerziellen Windows-Vereinbarungen gelten für die Verwendung von Containerimages in einer Produktionsumgebung. Lesen Sie die Containerimage-EULA, um genau zu verstehen, was zulässig und was unzulässig ist.
Muss ich als Entwickler meine App für jeden Containertyp neu schreiben?
Nein Windows-Containerimages sind für Windows Server-Container und Hyper-V-Isolierung gleich. Die Auswahl des Containertyps erfolgt beim Starten des Containers. Aus Sicht des Entwicklers sind Windows Server-Container und Hyper-V-Isolierung zwei Varianten der gleichen Sache. Sie bieten die gleiche Entwicklungs-, Programmier- und Verwaltungserfahrung, sind offen und erweiterbar und beinhalten das gleiche Maß an Integration und Unterstützung wie Docker.
Ein Entwickler kann ein Containerimage unter Verwendung eines Windows Server-Containers erstellen und es in Hyper-V-Isolierung oder umgekehrt bereitstellen, ohne dass irgendwelche Änderungen vorgenommen werden müssen, außer der Angabe des entsprechenden Laufzeitflags.
Windows Server-Container bieten eine größere Dichte und Leistung, wenn es auf Geschwindigkeit ankommt, z. B. eine geringere Hochfahrzeit und eine schnellere Laufzeitleistung im Vergleich zu geschachtelten Konfigurationen. Die Hyper-V-Isolierung bietet, wie der Name schon sagt, eine stärkere Isolierung, die sicherstellt, dass Code, der in einem Container ausgeführt wird, das Hostbetriebssystem oder andere Container, die auf demselben Host ausgeführt werden, nicht kompromittieren oder beeinträchtigen kann. Dies ist hilfreich für mehrinstanzenfähige Szenarien (mit Anforderungen für das Hosten von nicht vertrauenswürdigem Code), einschließlich SaaS-Anwendungen und Computehosting.
Kann ich Windows-Container unter Windows 10 im prozessisolierten Modus ausführen?
Ab dem Windows 10-Update vom Oktober 2018 können Sie einen Windows-Container mit Prozessisolierung ausführen. Sie müssen jedoch zunächst Prozessisolierung direkt anfordern, indem Sie das Flag --isolation=process verwenden, wenn Sie Ihre Container mit docker run ausführen. Prozessisolierung ist mit Windows 10/11 Pro (oder höher), Windows 10 Enterprise (oder höher), Windows 10 IoT Core und Windows 10 IoT Enterprise (oder höher) kompatibel.
Wenn Sie Ihre Windows-Container auf diese Weise ausführen möchten, müssen Sie sicherstellen, dass auf dem Host Windows 10 Build 17763 und höher ausgeführt wird und Sie über eine Docker-Version mit der Engine 18.09 oder höher verfügen.
Warnung
Abgesehen von IoT Core- und IoT Enterprise-Hosts (nachdem Sie weitere Bestimmungen und Einschränkungen akzeptiert haben) ist dieses Feature nur für Entwicklung und Tests gedacht. Sie sollten weiterhin Windows Server als Host für Produktionsbereitstellungen verwenden. Wenn Sie dieses Feature verwenden, müssen Sie außerdem sicherstellen, dass die Versionstags und Buildnummern von Host und Container übereinstimmen, da andernfalls der Container ggf. nicht gestartet wird oder ein nicht definiertes Verhalten aufweist.
Wie stelle ich meine Containerimages auf Air-Gap-Computern zur Verfügung?
Windows-Containerbasisimages enthalten Artefakte, deren Weitergabe durch eine Lizenz eingeschränkt ist. Wenn Sie mit diesen Images Builds erstellen und sie in eine private oder öffentliche Registrierung pushen, werden Sie feststellen, dass die Basisebene niemals gepusht wird Stattdessen wird das Konzept einer Fremdebene verwendet, die auf die tatsächliche Basisebene im Azure-Cloudspeicher verweist.
Dies kann die Dinge erschweren, wenn Sie einen Air-Gap-Computer verwenden, der nur Images von der Adresse Ihrer privaten Containerregistrierung abrufen kann. In diesem Fall funktioniert es nicht, der Fremdebene zu folgen, um das Basisimage abzurufen. Um das Verhalten der Fremdebene außer Kraft zu setzen, können Sie das --allow-nondistributable-artifacts-Flag im Docker-Daemon verwenden.
Wichtig
Die Verwendung dieses Flags schließt Ihre Verpflichtung nicht aus, die Bedingungen der Lizenz für Windows-Containerbasisimages einzuhalten. Sie dürfen keinen Windows-Inhalt für die öffentliche oder Drittanbieterverteilung bereitstellen. Die Verwendung in ihrer eigenen Umgebung ist zulässig.
Zusätzliches Feedback
Möchten Sie den FAQ etwas hinzufügen? Öffnen Sie im Abschnitt „Kommentare“ ein neues Issue für Feedback, oder richten Sie einen Pull Request für diese Seite mit GitHub ein.