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-Knoten auf EKS Clustern bereitstellen
Vor der Bereitstellung Windows Knoten sollten Sie sich der folgenden Überlegungen bewusst sein.
-
Sie können Host-Netzwerke auf Windows-Knoten mithilfe von
HostProcess
-Pods verwenden. Weitere Informationen finden Sie unter Erstellen eines HostProcessPod Fenstersim Kubernetes -Dokumentation. -
EKSAmazon-Cluster müssen einen oder mehrere enthalten Linux oder Fargate-Knoten zum Ausführen des Kernsystems Pods das läuft nur auf Linux, wie beispielsweise CoreDNS.
-
Die
kubelet
kube-proxy
Ereignisprotokolle werden in dasEKS Windows
Ereignisprotokoll umgeleitet und sind auf ein Limit von 200 MB festgelegt. -
Sie können die Option Sicherheitsgruppen einzelnen Pods zuweisen nicht verwenden mit Pods läuft auf Windows Knoten.
-
Sie können benutzerdefinierte Netzwerke nicht verwenden mit Windows Knoten.
-
Du kannst es nicht verwenden
IPv6
mit Windows Knoten. -
Windows Knoten unterstützen eine elastic network interface pro Knoten. Standardmäßig ist die Anzahl der Pods die du ausführen kannst Windows node entspricht der Anzahl der IP-Adressen, die pro elastic network interface für den Instance-Typ des Knotens verfügbar sind, minus eins. Weitere Informationen finden Sie unter IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ im EC2Amazon-Benutzerhandbuch.
-
In einem EKS Amazon-Cluster kann ein einzelner Service mit einem Load Balancer bis zu 1024 Back-End unterstützen Pods. Jeder Pod hat seine eigene eindeutige IP-Adresse. Das bisherige Limit von 64 Pods ist nach einem Windows Server-Update, das mit OS Build 17763.2746
beginnt, nicht mehr der Fall. -
Windows-Container werden für Amazon nicht unterstützt EKS Pods auf Fargate.
-
Sie können keine Logs aus dem
vpc-resource-controller
Pod abrufen. Dies war zuvor möglich, als Sie den Controller auf der Datenebene bereitgestellt haben. -
Es gibt eine Abkühlungsphase, bevor einem neuen Pod eine
IPv4
-Adresse zugewiesen wird. Dadurch wird verhindert, dass Datenverkehr aufgrund veralteterIPv4
-Regeln an einen älteren Pod mit derselbenkube-proxy
-Adresse fließt. -
Die Quelle für den Controller wird verwaltet auf GitHub. Wenn Sie zum Controller beitragen oder Probleme gegen den Controller einreichen möchten, besuchen Sie das Projekt
unter GitHub. -
Bei der Angabe einer benutzerdefinierten AMI ID für Windows verwaltete Knotengruppen, fügen Sie
eks:kube-proxy-windows
sie Ihrer AWS IAM Authenticator-Konfigurationsübersicht hinzu. Weitere Informationen finden Sie unter Einschränkungen und Bedingungen bei der Angabe einer AMI ID. -
Wenn die Beibehaltung Ihrer verfügbaren IPv4 Adressen für Ihr Subnetz von entscheidender Bedeutung ist, finden Sie weitere Informationen im EKSBest Practices Guide — Windows Networking IP Address Management
. -
Einen vorhandenen -Cluster. Auf dem Cluster muss einer der folgenden ausgeführt werden Kubernetes Versionen und Plattformversionen, die in der folgenden Tabelle aufgeführt sind. Any Kubernetes und Plattformversionen, die später als die aufgeführten sind, werden ebenfalls unterstützt.
Kubernetes-Version Plattformversion 1.31
eks.4
1,30
eks.2
1,29
eks.1
1,28
eks.1
1,27
eks.1
1,26
eks.1
1,25
eks.1
1,24
eks.2
-
Ihr Cluster muss mindestens einen haben (wir empfehlen mindestens zwei) Linux Knoten oder Fargate Pod um zu rennen CoreDNS. Wenn Sie Legacy aktivieren Windows Support, Sie müssen einen verwenden Linux Knoten (Sie können kein Fargate verwenden) Pod) zum Laufen CoreDNS.
-
Eine bestehende EKSIAMAmazon-Cluster-Rolle.
Aktivieren Windows Support
-
Wenn Sie keine Amazon Linux-Knoten in Ihrem Cluster haben und Sicherheitsgruppen verwenden für Pods, fahren Sie mit dem nächsten Schritt fort. Ansonsten bestätigen Sie, dass die verwaltete Richtlinie
AmazonEKSVPCResourceController
Ihrer Cluster-Rolle angefügt ist. ErsetzeneksClusterRole
mit Ihrem Cluster-Rollennamen.aws iam list-attached-role-policies --role-name eksClusterRole
Eine Beispielausgabe sieht wie folgt aus.
{ "AttachedPolicies": [ { "PolicyName": "AmazonEKSClusterPolicy", "PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSClusterPolicy" }, { "PolicyName": "AmazonEKSVPCResourceController", "PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSVPCResourceController" } ] }
Wenn die Richtlinie wie in der vorherigen Ausgabe angehängt ist, überspringen Sie den nächsten Schritt.
-
Fügen Sie Ihrer EKSIAMAmazon-Cluster-Rolle die von A mazonEKSVPCResource Controller verwaltete Richtlinie hinzu. Ersetzen
eksClusterRole
mit dem Namen Ihrer Clusterrolle.aws iam attach-role-policy \ --role-name eksClusterRole \ --policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
-
Erstellen Sie eine Datei mit dem Namen
vpc-resource-controller-configmap.yaml
mit dem folgenden Inhalt.apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true"
-
Anwendung der
ConfigMap
auf Ihren Cluster.kubectl apply -f vpc-resource-controller-configmap.yaml
-
Stellen Sie sicher, dass Ihr eine Zuordnung für die Instanzrolle von
aws-auth
ConfigMap
enthält Windows Knoten, der dieeks:kube-proxy-windows
RBAC Berechtigungsgruppe einschließen soll. Prüfen Sie dies durch Ausführung des folgenden Befehls.kubectl get configmap aws-auth -n kube-system -o yaml
Eine Beispielausgabe sieht wie folgt aus.
apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows # This group is required for Windows DNS resolution to work rolearn: arn:aws: iam::111122223333:role/eksNodeRole username: system:node:{{EC2PrivateDNSName}} [...]
eks:kube-proxy-windows
sollte unter „Gruppen“ aufgelistet sein. Wenn die Gruppe nicht angegeben ist, müssen Sie Ihre Gruppe aktualisierenConfigMap
oder sie so erstellen, dass sie die erforderliche Gruppe enthält. Weitere Informationen zuraws-auth
ConfigMap
finden Sie unter Anwenden von aws-authConfigMap auf Ihren Cluster.
Stellen Sie Windows-Pods bereit
Wenn Sie Pods in Ihrem Cluster bereitstellen, müssen Sie das Betriebssystem angeben, das sie verwenden, wenn Sie eine Mischung aus verschiedenen Knotentypen ausführen.
Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Linux Pods, verwenden Sie den folgenden Text zur Knotenauswahl in Ihren Manifesten.
nodeSelector: kubernetes.io/os: linux kubernetes.io/arch: amd64
Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Windows Pods, verwenden Sie den folgenden Knotenauswahltext in Ihren Manifesten.
nodeSelector: kubernetes.io/os: windows kubernetes.io/arch: amd64
Sie können eine Beispielanwendung bereitstellen, um die verwendeten Knotenselektoren zu sehen.
Höhere Support Pod Dichte auf Windows-Knoten
Bei Amazon EKS jeweils Pod wird eine IPv4
Adresse von Ihrem zugewiesenVPC. Aus diesem Grund ist die Anzahl von Pods Die Anzahl der verfügbaren IP-Adressen, die Sie auf einem Knoten bereitstellen können, wird durch die verfügbaren IP-Adressen eingeschränkt, auch wenn genügend Ressourcen vorhanden sind, um mehr zu betreiben Pods auf dem Knoten. Da von einem Windows-Knoten nur eine elastische Netzwerkschnittstelle unterstützt wird, entspricht die maximale Anzahl verfügbarer IP-Adressen auf einem Windows-Knoten standardmäßig:
Number of private IPv4 addresses for each interface on the node - 1
Eine IP-Adresse wird als primäre IP-Adresse der Netzwerkschnittstelle verwendet, sodass sie nicht zugewiesen werden kann Pods.
Sie können höhere Werte aktivieren Pod Dichte auf Windows-Knoten durch Aktivierung der IP-Präfix-Delegierung. Mit diesem Feature können Sie der primären Netzwerkschnittstelle ein /28
-IPv4
-Präfix zuweisen, anstatt sekundäre IPv4
-Adressen zuzuweisen. Durch die Zuweisung eines IP-Präfixes wird die maximale Anzahl verfügbarer IPv4
-Adressen auf dem Knoten auf Folgendes erhöht:
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
Bei dieser erheblich größeren Anzahl verfügbarer IP-Adressen sollten die verfügbaren IP-Adressen Ihre Fähigkeit, die Anzahl der zu skalieren, nicht einschränken Pods auf Ihren Knoten. Weitere Informationen finden Sie unter Weisen Sie EKS Amazon-Knoten mehr IP-Adressen mit Präfixen zu.