Bereitstellung von Windows-Knoten in EKS-Clustern - Amazon EKS
ÜberlegungenVoraussetzungenWindows-Support aktivierenWindows-Pods bereitstellenUnterstützung einer höheren Pod-Dichte in Windows-Knoten

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Bereitstellung von Windows-Knoten in EKS-Clustern

Erfahren Sie, wie Sie den Windows-Support für Ihren Amazon-EKS-Cluster aktivieren und verwalten, um Windows-Container neben Linux-Containern auszuführen.

Überlegungen

Beachten Sie vor der Bereitstellung von Windows-Knoten die folgenden Überlegungen.

  • EKS Auto Mode unterstützt keine Windows-Knoten

  • Sie können Host-Netzwerke auf Windows-Knoten mithilfe von HostProcess-Pods verwenden. Weitere Informationen finden Sie unter Erstellen eines Windows HostProcessPod in der Kubernetes-Dokumentation.

  • Amazon-EKS-Cluster müssen einen oder mehrere Linux- oder Fargate-Knoten enthalten, um Kernsystem-Pods auszuführen, die nur unter Linux, z. B. CoreDNS, ausgeführt werden.

  • Die Ereignisprotokolle kubelet und kube-proxy werden in das EKS Windows-Ereignisprotokoll umgeleitet und auf 200 MB begrenzt.

  • Sie können nicht dieselbe IAM-Rolle sowohl für Linux- als auch für Windows-Knoten verwenden.

  • Sie können Sicherheitsgruppen nicht einzelnen Pods zuweisen, wenn Pods in Windows-Knoten ausgeführt werden.

  • Sie können benutzerdefinierte Netzwerke nicht mit Windows-Knoten benutzen.

  • Sie können IPv6 nicht mit Windows-Knoten verwenden.

  • Windows-Knoten unterstützen eine Elastic-Network-Schnittstelle pro Knoten. Die Anzahl der Pods, die Sie pro Windows-Knoten ausführen können, entspricht standardmäßig der Anzahl der IP-Adressen, die pro Elastic-Network-Schnittstelle 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 Amazon-EC2-Benutzerhandbuch.

  • In einem Amazon-EKS-Cluster kann ein einzelner Service mit einem Load Balancer bis zu 1 024 Backend-Pods unterstützen. Jeder Pod hat seine eigene eindeutige IP-Adresse. Das bisherige Limit von 64 Pods trifft nicht mehr zu, nachdem ein Windows-Server-Update beginnend mit Betriebssystem-Build 17763.2746 durchgeführt wurde.

  • Windows-Container werden in Fargate für Amazon-EKS-Pods nicht unterstützt.

  • Es ist nicht möglich, Amazon EKS Hybrid Nodes mit Windows als Betriebssystem für den Host zu verwenden.

  • Sie können keine Protokolle 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 auf GitHub verwaltet. Um zum Controller beizutragen oder Probleme gegen den Controller einzureichen, besuchen Sie das Projekt auf GitHub.

  • Wenn Sie eine benutzerdefinierte AMI-ID für verwaltete Windows-Knotengruppen angeben, fügen Sie eks:kube-proxy-windows zu Ihrer AWS-IAM-Authenticator-Konfigurationszuordnung hinzu. Weitere Informationen finden Sie unter Grenzen 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 Handbuch zu bewährte Methoden für EKS – IP-Adressverwaltung im Windows-Netzwerk.

  • Überlegungen zu EKS-Zugriffseinträgen

    • Zugriffseinträge zur Verwendung mit Windows-Knoten erfordern den Typ EC2_WINDOWS. Weitere Informationen finden Sie unter Zugriffseinträge erstellen.

      So erstellen Sie einen Zugriffseintrag für einen Windows-Knoten:

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/<role-name> --type EC2_Windows

Voraussetzungen

  • Einen vorhandenen -Cluster.

  • Ihr Cluster muss mindestens einen (wir empfehlen mindestens zwei) Linux-Knoten oder Fargate-Pod haben, um CoreDNS auszuführen. Wenn Sie den veralteten System-Windows-Support aktivieren, müssen Sie einen Linux-Knoten verwenden (Sie können keinen Fargate-Pod verwenden), um CoreDNS auszuführen.

  • Ein vorhandener Amazon-EKS-Cluster-IAM-Rolle.

Windows-Support aktivieren

  1. Wenn Sie keine Amazon-Linux-Knoten in Ihrem Cluster haben und Sicherheitsgruppen für Pods verwenden, fahren Sie mit dem nächsten Schritt fort. Ansonsten bestätigen Sie, dass die verwaltete Richtlinie AmazonEKSVPCResourceController Ihrer Cluster-Rolle angefügt ist. Ersetzen Sie eksClusterRole mit dem Namen Ihrer Clusterrolle.

    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 die verwaltete Richtlinie AmazonEKSVPCResourceController zu Ihrer IAM-Rolle für den Amazon-EKS-Cluster hinzu. Ersetzen Sie eksClusterRole mit dem Namen Ihrer Clusterrolle.

    aws iam attach-role-policy \
  --role-name eksClusterRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController

  3. Aktualisieren Sie die VPC CNI ConfigMap, um Windows IPAM zu aktivieren. Beachten Sie: Wenn die VPC CNI mithilfe eines Helm-Charts oder als Amazon-EKS-Add-On auf Ihrem Cluster installiert ist, können Sie die ConfigMap möglicherweise nicht direkt ändern. Informationen zur Konfiguration von Amazon-EKS-Add-Ons finden Sie unter Felder für die Anpassung von Amazon-EKS-Add-On festlegen.

    1. Erstellen Sie eine Datei mit dem Namen vpc-resource-controller-configmap.yaml mit dem folgendem Inhalt.

      apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

    2. Anwendung der ConfigMap auf Ihren Cluster.

      kubectl apply -f vpc-resource-controller-configmap.yaml

  4. Wenn in Ihrem Cluster der Authentifizierungsmodus so eingestellt ist, dass die aws-auth-Konfigurationszuordnung aktiviert wird:

    • Stellen Sie sicher, dass Ihre aws-auth ConfigMap eine Zuordnung für die Instance-Rolle des Windows-Knotens enthält, sodass sie die eks:kube-proxy-windows-RBAC-Berechtigungsgruppe einschließt. 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 ConfigMap aktualisieren 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.

  5. Wenn in Ihrem Cluster der Authentifizierungsmodus so eingestellt ist, dass die aws-auth-Konfigurationszuordnung deaktiviert wird, können Sie EKS-Zugriffseinträge verwenden. Erstellen Sie eine neue Knoten-Rolle für die Verwendung mit Windows-Instances, und EKS erstellt automatisch einen Zugriffseintrag vom Typ EC2_WINDOWS.

Windows-Pods bereitstellen

Wenn Sie Pods in Ihrem Cluster bereitstellen, müssen Sie das Betriebssystem angeben, das sie verwenden, wenn Sie eine Kombination aus Knotentypen ausführen.

Verwenden Sie für Linux-Pods den folgenden Knotenauswahltext in Ihren Manifesten.

nodeSelector:
        kubernetes.io/os: linux
        kubernetes.io/arch: amd64

Verwenden Sie für Windows-Pods den folgenden Knoten-Auswahltext in Ihren Manifesten.

nodeSelector:
        kubernetes.io/os: windows
        kubernetes.io/arch: amd64

Sie können eine Beispielanwendung bereitstellen, um die verwendeten Knotenselektoren zu sehen.

Unterstützung einer höheren Pod-Dichte in Windows-Knoten

In Amazon EKS wird jedem Pod eine IPv4-Adresse aus Ihrer VPC zugewiesen. Aus diesem Grund ist die Anzahl der Pods, die Sie in einem Knoten bereitstellen können, durch die verfügbaren IP-Adressen begrenzt, selbst wenn genügend Ressourcen vorhanden sind, um mehr Pods auf dem Knoten auszuführen. 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 und kann daher Pods nicht zugewiesen werden.

Sie können eine höhere Pod-Dichte in Windows-Knoten aktivieren, indem Sie die IP-Präfix-Delegierung aktivieren. 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

Angesichts dieser deutlich größeren Anzahl verfügbarer IP-Adressen sollten verfügbare IP-Adressen Ihre Fähigkeit, die Anzahl der Pods auf Ihren Knoten zu skalieren, nicht einschränken. Weitere Informationen finden Sie unter Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten.