Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Windows-Netzwerk

Überblick über das Windows-Container-Netzwerk

Windows-Container unterscheiden sich grundlegend von Linux-Containern. Linux-Container verwenden Linux-Konstrukte wie Namespaces, das Union-Dateisystem und Cgroups. Unter Windows werden diese Konstrukte vom Host Compute Service (HCS) von containerd abstrahiert. https://github.com/microsoft/hcsshim HCS fungiert als API-Ebene, die sich über der Container-Implementierung unter Windows befindet. Windows-Container nutzen auch den Host Network Service (HNS), der die Netzwerktopologie auf einem Knoten definiert.

Aus Netzwerksicht sorgen HCS und HNS dafür, dass Windows-Container wie virtuelle Maschinen funktionieren. Beispielsweise verfügt jeder Container über einen virtuellen Netzwerkadapter (vNIC), der mit einem Hyper-V virtuellen Switch (vSwitch) verbunden ist, wie in der Abbildung oben dargestellt.

Verwaltung von IP-Adressen

Ein Knoten in Amazon EKS verwendet sein Elastic Network Interface (ENI), um eine Verbindung zu einem AWS-VPC-Netzwerk herzustellen. Derzeit wird nur eine einzige ENI pro Windows-Worker-Knoten unterstützt. Die IP-Adressverwaltung für Windows-Knoten wird vom VPC Resource Controller durchgeführt, der auf der Steuerungsebene ausgeführt wird. Weitere Informationen zum Workflow für die IP-Adressverwaltung von Windows-Knoten finden Sie hier.

Die Anzahl der Pods, die ein Windows-Worker-Knoten unterstützen kann, hängt von der Größe des Knotens und der Anzahl der verfügbaren IPv4-Adressen ab. Sie können die auf dem Knoten verfügbare IPv4-Adresse wie folgt berechnen:

Mithilfe der obigen Formel können wir die maximale Anzahl an Pods für einen Windows-Worker berechnen, der auf der Grundlage einer m5.large-Instance nodet, wie folgt:

Weitere Informationen dazu, wie viele IP-Adressen ein Instanztyp unterstützen kann, finden Sie unter IP-Adressen pro Netzwerkschnittstelle pro Instanztyp.

Ein weiterer wichtiger Aspekt ist der Fluss des Netzwerkverkehrs. Unter Windows besteht das Risiko einer Überlastung der Anschlüsse auf Knoten mit mehr als 100 Diensten. Wenn dieser Zustand eintritt, beginnen die Knoten, Fehler mit der folgenden Meldung auszugeben:

„Die Erstellung der Richtlinie ist fehlgeschlagen: HCN CreateLoadBalancer ist in Win32 fehlgeschlagen: Der angegebene Port ist bereits vorhanden.“

Um dieses Problem zu lösen, nutzen wir Direct Server Return (DSR). DSR ist eine Implementierung der asymmetrischen Netzwerklastverteilung. Mit anderen Worten, der Anforderungs- und Antwortverkehr verwendet unterschiedliche Netzwerkpfade. Diese Funktion beschleunigt die Kommunikation zwischen Pods und reduziert das Risiko einer Portüberlastung. Wir empfehlen daher, DSR auf Windows-Knoten zu aktivieren.

DSR ist in Windows Server SAC EKS-optimierten AMIs standardmäßig aktiviert. Für Windows Server 2019 LTSC EKS-optimierte AMIs müssen Sie sie während der Instanzbereitstellung mithilfe des folgenden Skripts aktivieren und Windows Server 2019 Full oder Core als AMI-Familie in der NodeGroup verwenden. eksctl Weitere Informationen finden Sie unter benutzerdefiniertes eksctl-AMI.

nodeGroups:
- name: windows-ng
  instanceType: c5.xlarge
  minSize: 1
  volumeSize: 50
  amiFamily: WindowsServer2019CoreContainer
  ssh:
    allow: false

Um DSR in Windows Server 2019 und höher verwenden zu können, müssen Sie beim Start der Instanz die folgenden Kube-Proxy-Flags angeben. Sie können dies tun, indem Sie das Userdata-Skript anpassen, das der Startvorlage für selbstverwaltete Knotengruppen zugeordnet ist.

<powershell>
[string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS"
[string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1'
[string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName"
(Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile
& $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1
</powershell>

Die DSR-Aktivierung kann anhand der Anweisungen im Microsoft Networking-Blog und in den Windows-Containern auf AWS Lab überprüft werden.

Wenn die Beibehaltung Ihrer verfügbaren IPv4-Adressen und die Minimierung von Verschwendung für Ihr Subnetz von entscheidender Bedeutung sind, wird generell empfohlen, den Präfix-Delegationsmodus nicht zu verwenden, wie unter Präfixmodus für Windows — Wann zu vermeiden beschrieben. Wenn die Präfixdelegierung dennoch gewünscht wird, können Sie Maßnahmen ergreifen, um die IPv4-Adressnutzung in Ihrem Subnetz zu optimieren. Eine detaillierte Anleitung zur Feinabstimmung des IPv4-Adressanforderungs- und -zuweisungsprozesses finden Sie unter Parameter für die Präfixdelegierung konfigurieren. Durch die Anpassung dieser Konfigurationen können Sie ein Gleichgewicht zwischen der Beibehaltung von IPv4-Adressen und den Vorteilen der Präfixdelegierung für die Pod-Dichte finden.

Wenn Sie die Standardeinstellung für die Zuweisung sekundärer IPv4-Adressen verwenden, werden derzeit keine Konfigurationen unterstützt, um zu manipulieren, wie der VPC Resource Controller IPv4-Adressen anfordert und zuweist. Genauer gesagt, minimum-ip-target und warm-ip-target werden nur für den Präfix-Delegationsmodus unterstützt. Beachten Sie auch, dass der VPC Resource Controller im sekundären IP-Modus je nach den verfügbaren IP-Adressen auf der Schnittstelle in Ihrem Namen in der Regel 3 ungenutzte IPv4-Adressen auf dem Knoten zuweist, um Warm-IPs für schnellere Pod-Startzeiten aufrechtzuerhalten. Wenn Sie die IP-Verschwendung ungenutzter warmer IP-Adressen minimieren möchten, könnten Sie versuchen, mehr Pods auf einem bestimmten Windows-Knoten zu planen, sodass Sie so viel IP-Adresskapazität der ENI wie möglich nutzen. Genauer gesagt, Sie könnten warme, ungenutzte IP-Adressen vermeiden, wenn alle IP-Adressen auf dem ENI bereits vom Knoten und den laufenden Pods verwendet werden. Eine weitere Problemumgehung, die Ihnen hilft, Einschränkungen bei der Verfügbarkeit von IP-Adressen in Ihren Subnetzen zu lösen, könnte darin bestehen, die Größe Ihres Subnetzes zu erhöhen oder Ihre Windows-Knoten in ihre eigenen dedizierten Subnetze zu unterteilen.

Darüber hinaus ist es wichtig zu beachten, dass IPv6 derzeit auf Windows-Knoten nicht unterstützt wird.

Optionen für das Container Network Interface (CNI)

Das AWSVPC CNI ist das De-facto-CNI-Plugin für Windows- und Linux-Worker-Knoten. Das AWSVPC CNI erfüllt zwar die Bedürfnisse vieler Kunden, dennoch kann es vorkommen, dass Sie Alternativen wie ein Overlay-Netzwerk in Betracht ziehen müssen, um eine IP-Erschöpfung zu vermeiden. In diesen Fällen kann das Calico CNI anstelle des AWSVPC CNI verwendet werden. Project Calico ist Open-Source-Software, die von Tigera entwickelt wurde. https://www.tigera.io/ Diese Software beinhaltet ein CNI, das mit EKS funktioniert. Anweisungen zur Installation von Calico CNI in EKS finden Sie auf der Installationsseite von Project Calico EKS.

Netzwerk-Richtlinien

Es wird als bewährte Methode angesehen, vom Standardmodus der offenen Kommunikation zwischen Pods in Ihrem Kubernetes-Cluster zur Beschränkung des Zugriffs auf der Grundlage von Netzwerkrichtlinien zu wechseln. Das Open-Source-Projekt Calico unterstützt nachdrücklich Netzwerkrichtlinien, die sowohl mit Linux- als auch mit Windows-Knoten funktionieren. Diese Funktion ist separat und nicht von der Verwendung des Calico CNI abhängig. Wir empfehlen daher, Calico zu installieren und für die Verwaltung von Netzwerkrichtlinien zu verwenden.

Anweisungen zur Installation von Calico auf Amazon EKS finden Sie unter Installieren von Calico auf Amazon EKS auf der Tigera-Website.

Darüber hinaus gelten die Hinweise im Amazon EKS-Leitfaden für Best Practices for Security — Network Section auch für EKS-Cluster mit Windows-Worker-Knoten. Einige Funktionen wie „Sicherheitsgruppen für Pods“ werden jedoch derzeit von Windows nicht unterstützt.