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

Lösung

Berechtigungen und Konfigurationen überprüfen

Damit das Amazon VPC CNI-Plugin funktioniert, musst du die entsprechende Pod-IP-Adresse zuweisen.

Überprüfe, ob du über die folgenden Berechtigungen und Konfigurationen verfügst:

• AWS Identity and Access Management (IAM)-Berechtigungen, einschließlich AmazonEKS_CNI_Policy, die an die IAM-Rollen deines Worker-Knotens angehängt wird. Oder IAM-Berechtigungen, die du über IAM-Rollen für Servicekonten (IRSA) 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-node-Pod in den Status Ready (Bereit) übergehen kann.
• Eine kube-proxy-Version und eine VPC CNI-Version, die mit der Version des Amazon EKS-Clusters übereinstimmen.

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen unter Troubleshooting errors for the AWS CLI (Problembehandlung bei der AWS CLI). Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Den aws-node-Pod-Status und die Protokolle überprüfen

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

Um zu überprüfen, ob der aws-node-Pod auf jedem Worker-Knoten ausgeführt wird, führe den folgenden kubectl-get-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. Informationen zum Befehl get findest du unter kubectl get auf der Kubernetes-Website.

Wenn die Befehlsausgabe zeigt, dass die Anzahl RESTARTS größer als 0 ist, überprüfe den Status von Containern und Fehlermeldungen. Führe den folgenden kubectl-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. Informationen zum Befehl describe findest du unter kubectl describe auf der Kubernetes-Website.

Wenn der aws-node-Pod im Status ContainerCreating feststeckt, zeigt die Ausgabe des Befehls describe möglicherweise die folgende Fehlermeldung an:

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

Um dieses Problem zu beheben, siehe Warum steckt mein Amazon-EKS-Pod im Status „ContainerCreating“ mit dem Fehler „Failed to create pod sandbox“ fest?

Um die Protokolle des aws-node-Pods anzuzeigen und auf Fehler zu überprüfen, führe einen der folgenden kubectl-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. Informationen zum Befehl logs findest du unter kubectl logs auf der Kubernetes-Website.

Um auf Fehler in den Protokollen des VPC CNI-Plugins auf dem Worker-Knoten zu überprüfen, melde dich beim Worker-Knoten an und navigiere zum Verzeichnis /var/log/aws-routed-eni/. Suche die Dateinamen plugin.log und ipamd.log.

Um zu überprüfen, ob die Worker-Knoten den API-Server-Endpunkt deines Amazon EKS-Clusters erreichen können, verwende SSH oder Session Manager, eine Funktion von AWS Systems Manager, um dich bei deinem Worker-Knoten anzumelden.

Führe dann 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.

Die VPC CNI-Version überprüfen

Überprüfe, ob deine Version des VPC CNI-Plugins aktuell und mit deiner Amazon EKS-Clusterversion 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.

Netzwerkkonfiguration und -anforderungen überprüfen

Überprüfe, ob du die Sicherheitsgruppen- und Subnetzkonfigurationen deines Amazon EKS-Clusters korrekt konfiguriert hast.

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 Regeln der Knotengruppe erlauben Port 10250 für eingehenden Datenverkehr von der Sicherheitsgruppe der Steuerebene und Port 443 für ausgehenden Datenverkehr zur Sicherheitsgruppe der Steuerebene. Weitere Informationen findest du unter Network security (Netzwerksicherheit).

Wenn die Pod-Sicherheitsgruppenfunktion aktiv ist, überprüfe, ob du das Sicherheitsgruppenkontingent erreicht hast. Wenn du dein Sicherheitsgruppenkontingent pro Elastic-Netzwerkschnittstelle erreichst, schlägt deine Pod-Netzwerkkonfiguration möglicherweise fehl.

Weitere Informationen zu den erforderlichen Sicherheitsgruppenregeln findest du unter View Amazon EKS security group requirements for clusters (Amazon EKS-Sicherheitsgruppenanforderungen für Cluster anzeigen).

Subnetzkonfiguration überprüfen

Um die verfügbaren IP-Adressen in jedem Subnetz der VPC aufzulisten, führe den folgenden AWS-CLI-Befehl describe-subnets aus:

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

Hinweis: Ersetze VPCID durch deine VPC-ID.

Überprüfe, ob die Regeln der Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) deines Worker-Knotens für deine Subnetze die Kommunikation mit dem Amazon EKS-API-Server zulassen. Weitere Informationen zur Konfiguration von Netzwerk-ACLs findest du unter Control subnet traffic with network access control lists (Subnetzverkehr mit Netzwerkzugriffskontrolllisten steuern).

Überprüfe, ob deine Steuerebenen-Subnetze über ausreichend IP-Adressen verfügen. Jedes Steuerebenen-Subnetz muss über mindestens sechs IP-Adressen verfügen, die Amazon EKS verwenden kann. Es wird empfohlen, mindestens 16 IP-Adressen für jedes Subnetz zu konfigurieren. Der Wert für AvailableIpAddressCount muss für das Subnetz, in dem du die Pods startest, größer als 0 sein. Weitere Informationen findest du unter Subnet requirements and considerations (Anforderungen und Überlegungen zu Subnetzen).

Bestätigen, dass sich der kube-proxy-Pod im Status „Running“ (Läuft) befindet

Der kube-proxy-Pod muss für die Netzwerkkonnektivität ausgeführt werden.

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

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

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.

Den Wert für WARM_PREFIX_TARGET überprüfen

Wenn du Präfix-Delegierung aktiviert hast, ü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 dieses Problem zu beheben, setze WARM_PREFIX_TARGET auf einen Wert, der größer oder gleich 1 ist. Wenn du die Präfix-Delegierung aktiviert hast und der Wert von WARM_PREFIX_TARGET 0 ist, führe den folgenden Befehl aus, um den Wert auf mindestens 1 zu aktualisieren:

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

Den reservierten Speicherplatz im Subnetz überprüfen

Nachdem du die Präfix-Delegierung aktiviert hast, überprüfe, ob in deinen Subnetzen ausreichend /28 IP-CIDR-Blöcke verfügbar sind. Alle 16 IP-Adressen müssen zusammenhängend sein.

Überprüfe außerdem die Protokolldatei auf die folgende Fehlermeldung:

„InsufficientCidrBlocks“

Um dieses Problem zu beheben, erstelle ein neues Subnetz und starte dann die Pods in dem neuen Subnetz. Verwende eine Subnetz-CIDR-Reservierung in Amazon EC2, um Speicherplatz in einem Subnetz mit einem zugewiesenen Präfix zu reservieren.

Die benutzerdefinierte Netzwerkkonfiguration überprüfen

Um zu bestimmen, ob das benutzerdefinierte Netzwerk für deinen Amazon EKS-Cluster aktiv 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.metadata.name}')

Wenn diese Variable auf True (Wahr) gesetzt ist, ist das benutzerdefinierte Netzwerk aktiv.

Wenn das benutzerdefinierte Netzwerk aktiv ist, musst du die ENIConfig-CRDs so konfigurieren, dass sie den Netzwerkanforderungen des Clusters entsprechen.

Führe den folgenden Befehl aus, um eine Liste aller ENIConfig-CRDs abzurufen:

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 deinen ENIConfig-Namen.

Überprüfe, ob jede ENIConfig die korrekte Subnetz- und Sicherheitsgruppenkonfiguration für jede Availability Zone aufweist.

Bestätige, dass das in der ENIConfig angegebene Subnetz mit der Availability Zone deiner Worker-Knoten übereinstimmt.

Weitere Informationen zu benutzerdefinierten Netzwerken findest du unter Deploy Pods in alternate subnets with custom networking (Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk bereitstellen).

Konfliktlösung konfigurieren, um Rollbacks zu verhindern

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

Wähle eine der folgenden Methoden:

• Wenn du keine Methode definierst, 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 selbstverwalteten zu Amazon EKS-verwalteten Add-ons wechselst.
• Verwende die PRESERVE-Methode, wenn du benutzerdefinierte Konfigurationen wie WARM_IP_TARGET oder benutzerdefinierte Netzwerke verwendest.

Zur Konfiguration von Konfliktlösungsmethoden siehe Update add-on (AWS Console) (Ein Add-on aktualisieren (AWS-Konsole))