Windows-Knoten auf EKS Clustern bereitstellen - Amazon EKS

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 Fensters im 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 das EKS 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 veralteter IPv4-Regeln an einen älteren Pod mit derselben kube-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

  1. 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. Ersetzen eksClusterRole 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.

  2. 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
  3. 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"
  4. Anwendung der ConfigMap auf Ihren Cluster.

    kubectl apply -f vpc-resource-controller-configmap.yaml
  5. Stellen Sie sicher, dass Ihr eine Zuordnung für die Instanzrolle von aws-auth ConfigMap enthält Windows Knoten, der die eks: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 aktualisieren ConfigMap oder sie so erstellen, dass sie die erforderliche Gruppe enthält. Weitere Informationen zur aws-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.