Helfen Sie mit, diese Seite zu verbessern
Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.
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.
WindowsKnoten auf EKS-Clustern bereitstellen
Beachten Sie vor der Bereitstellung von Windows-Knoten die folgenden Überlegungen.
Überlegungen
-
Sie können Host-Netzwerke auf Windows-Knoten mithilfe von
HostProcess
-Pods verwenden. Weitere Informationen finden Sie unter Ein WindowsHostProcess
Pod erstellenin 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
undkube-proxy
werden in dasEKS
-Windows-Ereignisprotokoll umgeleitet und auf 200 MB begrenzt. -
Sie können Sicherheitsgruppen für Pods nicht mit Pods verwenden, die auf Windows-Knoten ausgeführt werden.
-
Sie können benutzerdefinierte Netzwerke nicht mit Windows-Knoten verwenden.
-
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 EC2-Benutzerhandbuch.
-
In einem Amazon-EKS-Cluster kann ein einzelner Service mit einem Load Balancer bis zu 1024 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 in Amazon-EKS-Pods nicht unterstützt.
-
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 veralteterIPv4
-Regeln an einen älteren Pod mit derselbenkube-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 Windows verwaltete Knotengruppen angeben, fügen Sie
eks:kube-proxy-windows
diese Ihrer AWS IAM Authenticator-Konfigurationsübersicht 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 EKS Best Practices Guide — Windows Networking IP Address Management
.
Voraussetzungen
-
Einen vorhandenen -Cluster. Auf dem Cluster muss eine der in der folgenden Tabelle aufgeführten Kubernetes-Versionen und Plattform-Versionen ausgeführt werden. Alle Kubernetes- und Plattformversionen, die über die aufgeführten hinausgehen, werden ebenfalls unterstützt. Wenn Ihre Cluster- oder Plattformversion früher als eine der folgenden Versionen ist, müssen Sie Legacy-System-Windows-Support auf der Datenebene Ihres Clusters aktivieren. Sobald sich Ihr Cluster in einer der folgenden Kubernetes- und Plattformversionen oder höher befindet, können Sie Legacy-System-Windows-Support entfernen und Windows-Support auf Ihrer Steuerebene aktivieren.
Kubernetes-Version Plattformversion 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 (wir empfehlen mindestens zwei) Linux-Knoten oder Fargate-Pod haben, um CoreDNS auszuführen. Wenn Sie den Legacy-System-Windows-Support aktivieren, müssen Sie einen Linux-Knoten verwenden (Sie können keinen Fargate-Pod verwenden), um CoreDNS auszuführen.
-
Eine vorhandene Amazon-EKS-Cluster-IAM-Rolle.
Aktivieren des Windows-Supports
Wenn Ihr Cluster nicht eine der, oder höhere, Kubernetes- und Plattformversionen aufweist, die in den Voraussetzungen aufgelistet sind, müssen Sie stattdessen den Support für die ältere Windows aktivieren. Weitere Informationen finden Sie unter Aktivieren des Legacy-System-Windows-Supports.
Wenn Sie den Windows-Support für Ihren Cluster noch nie aktiviert haben, fahren Sie mit dem nächsten Schritt fort.
Wenn Sie den Windows-Support für einen Cluster aktiviert haben, der älter als eine der Kubernetes- oder Plattformversionen ist, die in den Voraussetzungen aufgelistet sind, dann müssen Sie zuerst den vpc-resource-controller und vpc-admission-webhook von Ihrer Datenebene entfernen. Sie sind veraltet und werden nicht mehr benötigt.
Aktivieren Sie den Windows-Support für Ihren Cluster
-
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 den
durch Ihren Clusterrollennamen.eksClusterRole
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.
-
Hängen Sie die von AmazonEksVPC ResourceController verwaltete Richtlinie an Ihre an. Amazon-EKS-Cluster-IAM-Rolle Ersetzen Sie den
durch Ihren Clusterrollennamen.eksClusterRole
aws iam attach-role-policy \ --role-name
eksClusterRole
\ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController -
Erstellen Sie eine Datei mit dem Namen
und dem folgenden Inhalt.vpc-resource-controller-configmap.yaml
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 Ihre
aws-auth
ConfigMap
eine Zuordnung für die Instance-Rolle des Windows-Knotens enthält, sodass sie die RBAC-Berechtigungsgruppeeks:kube-proxy-windows
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 IhreConfigMap
aktualisieren 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.
Entfernen des Legacy-System-Windows-Supports von Ihrer Datenebene
Wenn Sie den Windows-Support für einen Cluster aktiviert haben, der älter als eine der Kubernetes- oder Plattformversionen ist, die in den Voraussetzungen aufgelistet sind, dann müssen Sie zuerst den vpc-resource-controller
und vpc-admission-webhook
von Ihrer Datenebene entfernen. Sie sind veraltet und werden nicht mehr benötigt, da die von ihnen bereitgestellte Funktionalität jetzt auf der Steuerebene aktiviert ist.
-
Deinstallieren Sie das
vpc-resource-controller
mit dem folgenden Befehl. Verwenden Sie diesen Befehl unabhängig davon, mit welchem Tool Sie ihn ursprünglich installiert haben. Ersetzen Sie
(nur die Instance des betreffenden Textes nachregion-code
/manifests/
) durch die AWS-Region , in der sich Ihr Cluster befindet.kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/
region-code
/vpc-resource-controller/latest/vpc-resource-controller.yaml -
Deinstallieren Sie das
vpc-admission-webhook
anhand der Anweisungen für das Tool, mit dem Sie es installiert haben. -
Aktivieren des Windows-Supports für Ihren Cluster auf der Steuerebene.
Deaktivieren des Windows-Supports
So deaktivieren Sie den Windows-Support für Ihren Cluster
-
Wenn Ihr Cluster Amazon-Linux-Knoten enthält und Sie Sicherheitsgruppen für Pods mit ihnen verwenden, überspringen Sie dann diesen Schritt.
Entfernen Sie die
AmazonVPCResourceController
-verwaltete IAM-Richtlinie von Ihrer Cluster-Rolle. Ersetzen Sie
durch den Namen Ihrer Clusterrolle undeksClusterRole
durch Ihre Konto-ID.111122223333
aws iam detach-role-policy \ --role-name
eksClusterRole
\ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController -
Deaktivieren Sie Windows IPAM in der
amazon-vpc-cni
ConfigMap.kubectl patch configmap/amazon-vpc-cni \ -n kube-system \ --type merge \ -p '{"data":{"enable-windows-ipam":"false"}}'
Bereitstellen von Pods
Wenn Sie Pods in Ihrem Cluster bereitstellen, müssen Sie das Betriebssystem angeben, das sie verwenden, wenn Sie eine Mischung 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 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.
Aktivieren des Legacy-System-Windows-Supports
Wenn Ihr Cluster eine der, oder spätere, Kubernetes- und Plattformversionen hat, die in den Voraussetzungen aufgelistet sind, wird empfohlen, den Windows-Support stattdessen auf der Steuerebene zu aktivieren. Weitere Informationen finden Sie unter Aktivieren des Windows-Supports.
Die folgenden Schritte helfen Ihnen, den Legacy-System-Windows-Support für die Datenebene Ihres Amazon-EKS-Clusters zu aktivieren, wenn Ihre Cluster- oder Plattformversion älter als die Versionen ist, die in den Voraussetzungen aufgelistet sind. Sobald Ihre Cluster- und Plattformversion gleich einer, oder höher als eine, Version ist, die in den Voraussetzungen aufgelistet ist, empfehlen wir Ihnen, dass Sie den Legacy-System-Windows-Support entfernen und ihn für die Steuerebene aktivieren.
Sie können eksctl
, einen Windows-Client oder einen macOS- oder Linux-Client verwenden, um den Legacy-System-Windows-Support für Ihren Cluster zu aktivieren.
Erneuerung des VPC-Zulassungs-Webhook-Zertifikats
Das vom VPC-Zulassungswebhook verwendete Zertifikat läuft ein Jahr nach der Ausstellung ab. Um Ausfallzeiten zu vermeiden, ist es wichtig, dass Sie das Zertifikat vor Ablauf erneuern. Sie können das Ablaufdatum Ihres aktuellen Zertifikats mit dem folgenden Befehl überprüfen.
kubectl get secret \ -n kube-system \ vpc-admission-webhook-certs -o json | \ jq -r '.data."cert.pem"' | \ base64 -decode | \ openssl x509 \ -noout \ -enddate | \ cut -d= -f2
Eine Beispielausgabe sieht wie folgt aus.
May 28 14:23:00 2022 GMT
Sie können das Zertifikat mit eksctl
oder einem Windows- oder Linux/macOS-Computer erneuern. Befolgen Sie die Anweisungen für das Tool, mit dem Sie den VPC-Zulassungswebhook ursprünglich installiert haben. Wenn Sie beispielsweise den VPC-Zulassungswebhook ursprünglich mit eksctl
installiert haben, sollten Sie das Zertifikat gemäß den Anweisungen auf der Registerkarte eksctl
erneuern.
Unterstützung einer höheren Pod-Dichte auf Windows-Knoten
In Amazon EKS wird jedem Pod eine IPv4
-Adresse von Ihrer VPC zugewiesen. Aus diesem Grund wird die Anzahl der Pods-Geräte, die Sie auf einem Knoten bereitstellen können, durch die verfügbaren IP-Adressen begrenzt, auch wenn auf dem Knoten genügend Ressourcen vorhanden sind, um mehr Pods 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 auf 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 Erhöhen Sie die Anzahl der verfügbaren IP-Adressen für Ihre Amazon-EC2-Knoten.