Wie behebe ich Probleme mit dem Amazon VPC CNI-Plugin für Amazon EKS?

Lösung

Amazon EKS benötigt eine korrekte Zuweisung von Pod-IP-Adressen, damit das Container Network Interface (CNI)-Plugin der Amazon Virtual Private Cloud (Amazon VPC) ordnungsgemäß funktioniert. Um Probleme mit dem VPC CNI-Plugin zu beheben, überprüfe die folgenden Konfigurationen:

• AWS Identity and Access Management (IAM)-Berechtigungen, einschließlich AmazonEKS_CNI_Policy, die an die IAM-Rollen deiner Worker-Knoten angehängt ist. Oder IAM-Berechtigungen, die du über IAM-Rollen für Dienstkonten bereitstellst.
• Ein Amazon EKS-API-Serverendpunkt, der vom Worker-Knoten aus erreichbar ist.
• Netzwerkzugriff auf API-Endpunkte für Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR) und Amazon Simple Storage Service (Amazon S3).
• Ausreichend verfügbare IP-Adressen in deinen Subnetzen.
• Ein Kube-Proxy, der erfolgreich ausgeführt wird, damit der AWS-Knoten-Pod in den Status Bereit übergeht.
• Kube-Proxy-Version und VPC CNI-Version, die mit der Version des Amazon EKS-Clusters übereinstimmen.

Führe die folgenden Schritte zur Fehlerbehebung aus, um Probleme mit dem VPC CNI-Plugin zu beheben.

Sicherstellen, dass der aws-node-Pod sich im Status „Läuft“ befindet

Das VPC CNI-Plugin wird als DaemonSet-Pod namens aws-node im Namespace kube-system ausgeführt. Auf jedem Worker-Knoten in deinem Cluster wird ein aws-node-Pod ausgeführt.

1. Um zu überprüfen, ob der aws-node-Pod auf jedem Worker-Knoten ausgeführt wird, führe den folgenden Befehl aus:

   kubectl get pods -n kube-system -l k8s-app=aws-node -o wide

   Hinweis: Ersetze k8s-app=aws-node durch deinen Label-Selektor.

2. Wenn die Befehlsausgabe zeigt, dass der Wert RESTARTS größer als 0 ist, überprüfe den Status der Container oder Fehlermeldungen. Führe den folgenden describe-Befehl aus:

   kubectl describe pod aws-node-pod-name -n kube-system

   Hinweis: Ersetze aws-node-pod-name durch den Namen deines AWS-Knoten-Pods.

3. Wenn der aws-node-Pod im Status ContainerCreating festhängt und die describe-Ausgabe die folgende Fehlermeldung in den Ereignissen zeigt:

   „Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused“

   Führe die Schritte unter Warum steckt mein Amazon-EKS-Pod im Status „ContainerCreating“ mit dem Fehler „Failed to create pod sandbox“ fest? aus.

4. Um die Protokolle des aws-node-Pods anzuzeigen, führe die folgenden logs-Befehle aus:

   kubectl logs daemonset/aws-node -n kube-system

   -oder-

   kubectl logs aws-node-pod-name -n kube-system

   Hinweis: Ersetze aws-node-pod-name durch den Namen deines aws-node-Pods.

5. Überprüfe die Protokolle des VPC CNI-Plugins auf dem Worker-Knoten. Melde dich beim Worker-Knoten an und gehe dann in das Verzeichnis /var/log/aws-routed-eni/. Suche die Dateien plugin.log und ipamd.log und überprüfe anschließend die Protokolle in diesen Dateien.

6. Stelle sicher, dass die Worker-Knoten den API-Server-Endpunkt deines Amazon EKS-Clusters erreichen können. Um dich bei deinem Worker-Knoten anzumelden, verwende SSH oder AWS Systems Manager Session Manager und führe anschließend den folgenden Befehl aus:

   curl -ivk https://eks-api-server-endpoint-url

   Hinweis: Ersetze eks-api-server-endpoint-url durch die Endpunkt-URL deines Amazon EKS-API-Servers.

VPC CNI-Version überprüfen

Überprüfe, ob deine VPC CNI-Plugin-Version aktuell und mit der Version deines Amazon EKS-Clusters kompatibel ist.

Um die aktuelle VPC CNI-Version zu überprüfen, führe den folgenden Befehl aus:

kubectl describe daemonset aws-node -n kube-system | grep Image | cut -d "/" -f 2

Vergleiche deine aktuelle Version mit der neuesten verfügbaren Version in den Amazon-VPC CNI-Plugin-Versionen auf der GitHub-Website.

Wenn deine Version veraltet ist, aktualisiere das VPC CNI-Plugin auf die neueste Version. Weitere Informationen findest du unter Aktualisieren der Amazon VPC CNI (Amazon EKS-Add-on).

Netzwerkkonfiguration und Anforderungen überprüfen

Überprüfe, ob die Sicherheitsgruppen- und Subnetzkonfigurationen deines Amazon EKS-Clusters korrekt eingerichtet sind.

Sicherheitsgruppenregeln überprüfen

Sicherheitsgruppen müssen Konnektivität zwischen der Steuerebene und der Datenebene zulassen.

Wenn du eine benutzerdefinierte Sicherheitsgruppe für die Worker-Knoten verwendest, überprüfe die Ports. Die minimalen Knotengruppenregeln erlauben Port 10250 eingehend von der Sicherheitsgruppe der Steuerebene und 443 ausgehend zur Sicherheitsgruppe der Steuerebene. Weitere Informationen findest du unter Netzwerksicherheit.

Wenn die Funktion „Pod-Sicherheitsgruppe“ aktiviert ist, überprüfe, ob die Limits der Sicherheitsgruppe erreicht wurden. Wenn du das Limit der Sicherheitsgruppe pro Elastic Network Interface erreichst, kann deine Pod-Netzwerkkonfiguration fehlschlagen. Weitere Informationen findest du unter Amazon VPC-Kontingente.

Weitere Informationen zu erforderlichen Sicherheitsgruppenregeln findest du unter Amazon EKS-Sicherheitsgruppenanforderungen für Cluster anzeigen.

Subnetzkonfiguration überprüfen

Um die verfügbaren IP-Adressen in jedem Subnetz in der Amazon VPC-ID aufzulisten, führe den folgenden Befehl aus:

aws ec2 describe-subnets —filters "Name=vpc-id,Values= VPCID" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'

Stelle sicher, dass die Regeln für die Netzwerk-Zugriffssteuerungsliste deiner Worker-Knoten für deine Subnetze die Kommunikation mit dem Amazon EKS-API-Server erlauben. Weitere Informationen zum Konfigurieren von Network ACLs findest du unter Subnetzverkehr mit Netzwerkzugriffskontrolllisten steuern.

Stelle sicher, dass die Steuerebenensubnetze genügend freie IP-Adressen haben. Jedes Steuerebenensubnetz muss mindestens sechs IP-Adressen haben, die Amazon EKS verwenden kann. AWS empfiehlt jedoch, dass jedes Subnetz mindestens 16 IP-Adressen hat. Der Wert AvailableIpAddressCount muss größer als 0 sein für das Subnetz, in dem die Pods gestartet werden. Weitere Informationen findest du unter Anforderungen und Überlegungen zu Subnetzen.

Sicherstellen, dass der kube-proxy-Pod sich im Status „Läuft“ befindet

Der kube-proxy-Pod muss für eine ordnungsgemäße Netzwerkverbindung ausgeführt werden.

Um zu überprüfen, ob kube-proxy ausgeführt wird, führe den folgenden Befehl aus:

kubectl get pods -n kube-system -l k8s-app=kube-proxy

Stelle sicher, dass sich alle kube-proxy-Pods im Status „Läuft“ befinden. Wenn kube-proxy nicht ausgeführt wird, überprüfe die Pod-Protokolle auf Fehler:

kubectl logs -n kube-system POD-NAME

Hinweis: Ersetze POD-NAME durch den Namen deines kube-proxy-Pods.

Wert von WARM_PREFIX_TARGET überprüfen

Wenn Präfixdelegierung aktiviert ist, überprüfe die Protokolldatei auf die folgende Fehlermeldung:

„Error: Setting WARM_PREFIX_TARGET = 0 is not supported while WARM_IP_TARGET/MINIMUM_IP_TARGET is not set. Please configure either one of the WARM_{PREFIX/IP}_TARGET or MINIMUM_IP_TARGET env variable“

Um den Fehler zu beheben, muss WARM_PREFIX_TARGET auf einen Wert größer oder gleich 1 gesetzt sein. Wenn die Präfixdelegierung aktiviert ist und WARM_PREFIX_TARGET auf 0 gesetzt ist, aktualisiere den Wert auf mindestens 1:

kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1

Reservierten Speicherplatz im Subnetz überprüfen

Wenn die Präfixdelegierung aktiviert ist, stelle sicher, dass deine Subnetze genügend /28 IP-CIDR-Blöcke verfügbar haben. Alle 16 IP-Adressen müssen zusammenhängend sein. Wenn Präfixdelegierung aktiviert ist, überprüfe die Protokolldatei auf die folgende Fehlermeldung:

„InsufficientCidrBlocks“

Um den Fehler zu beheben, erstelle ein neues Subnetz und starte die Pods aus dem neuen Subnetz. Verwende eine Amazon EC2-Subnetz-CIDR-Reservierung, um Speicherplatz in einem Subnetz mit einem zugewiesenen Präfix zu reservieren. Weitere Informationen findest du unter Subnetz-CIDR-Reservierungen.

Benutzerdefinierte Netzwerkkonfiguration überprüfen

Um festzustellen, ob benutzerdefiniertes Networking für deinen Amazon EKS-Cluster aktiviert ist, führe den folgenden Befehl aus:

kubectl describe pod -n kube-system $(kubectl get pods -n kube-system -l k8s-app=aws-node -o jsonpath='{.items[0].metadata.name}')

Wenn diese Variable auf True gesetzt ist, ist benutzerdefiniertes Networking aktiviert.

Wenn benutzerdefiniertes Networking aktiviert ist, müssen die ENIConfig-CRDs korrekt konfiguriert sein, um den Netzwerkanforderungen des Clusters zu entsprechen. Führe den folgenden Befehl aus, um eine Liste abzurufen und alle ENIConfig-CRDs zu überprüfen:

kubectl get ENIConfig -A -o yaml

Um eine bestimmte ENIConfig zu beschreiben, führe den folgenden Befehl aus:

kubectl describe ENIConfig eni-config-name

Hinweis: Ersetze Eni-config-name durch den Namen deiner ENIConfig.

Stelle sicher, dass jede ENIConfig die richtige Subnetz- und Sicherheitsgruppenkonfiguration für jede Availability Zone enthält.

Stelle sicher, dass das in der ENIConfig angegebene Subnetz zur Availability Zone deiner Worker-Knoten passt.

Weitere Informationen zu benutzerdefiniertem Networking findest du unter Pods mit benutzerdefiniertem Networking in alternativen Subnetzen bereitstellen.

Konfliktlösung konfigurieren, um Rollbacks zu verhindern

Wenn du AWS Cloud Development Kit (AWS CDK), AWS CloudFormation oder eksctl mit verwalteten Add-ons verwendest, definiere eine Konfliktlösungsmethode, um Rollbacks zu verhindern.

Die richtigen Methoden sind NONE, OVERWRITE oder PRESERVE.

• Wenn keine Methode definiert ist, ist die Standardeinstellung NONE. Wenn das System Konflikte erkennt, wird das Update des CloudFormation-Stacks rückgängig gemacht, und es werden keine Änderungen vorgenommen.
• Verwende die Overwrite-Methode, um die Standardkonfiguration für die Add-Ons festzulegen. Du musst OVERWRITE verwenden, wenn du von selbst verwalteten Add-ons zu Amazon EKS-verwalteten Add-ons wechselst.
• Verwende die Methode PRESERVE, wenn du benutzerdefinierte Konfigurationen verwendest, wie WARM_IP_TARGET oder benutzerdefiniertes Networking.

Weitere Informationen zum Festlegen von Konfliktlösungsmethoden findest du unter Amazon EKS-Add-on aktualisieren.