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

Kurzbeschreibung

Um dem Pod auf Ihrem Worker-Knoten mit Ihrem CNI-Plugin (auf der Kubernetes-Website) eine IP-Adresse zuzuweisen und auszuführen, müssen Sie über die folgenden Konfigurationen verfügen:

• AWS Identity and Access Management (IAM)-Berechtigungen, einschließlich einer CNI-Richtlinie, die der IAM-Rolle Ihres Worker-Knotens zugeordnet ist. Oder IAM-Berechtigungen, die Sie über IAM-Rollen für Dienstkonten bereitstellen.
• 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 Ihrem Subnetz.
• Ein Kube-Proxy, der erfolgreich ausgeführt wird, damit der AWS-Knoten-Pod in den Status Bereit übergeht.
• Die Kube-Proxy-Version und die VPC-CNI-Version, die die Amazon EKS-Version unterstützen.

Behebung

Stellen Sie sicher, dass sich der AWS-Knoten-Pod auf jedem Worker-Knoten im Status Läuft befindet

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob sich der aws-Knoten-Pod auf einem Worker-Knoten im Status Läuft befindet:

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

Wenn die Befehlsausgabe zeigt, dass der RESTARTS-Zähler 0 ist, befindet sich der aws-Knoten-Pod im Status Läuft. Folgen Sie den Schritten im Abschnitt Stellen Sie sicher, dass in Ihrem Subnetz genügend freie IP-Adressen verfügbar sind.

Wenn die Befehlsausgabe zeigt, dass die Anzahl der RESTARTS größer als 0 ist, stellen Sie sicher, dass der Worker-Knoten den API-Serverendpunkt Ihres Amazon EKS-Clusters erreichen kann. Führen Sie folgenden Befehl aus:

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

Überprüfen Sie die Konnektivität zu Ihrem Amazon EKS-Cluster

1.Stellen Sie sicher, dass die Sicherheitsgruppeneinstellungen Ihres Worker-Knotens für Amazon EKS korrekt konfiguriert sind. Weitere Informationen finden Sie unter Anforderungen und Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

2.Stellen Sie sicher, dass die Regeln der Netzwerkzugriffskontrollliste (Netzwerk-ACL) Ihres Worker-Nodes für Ihr Subnetz die Kommunikation mit dem Amazon EKS-API-Serverendpunkt zulassen.

**Wichtig:**Erlauben Sie eingehenden und ausgehenden Verkehr auf Anschluss 443.

3.Stellen Sie sicher, dass sich der Kube-Proxy-Pod auf jedem Worker-Knoten im Status Läuft befindet:

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

4.Stellen Sie sicher, dass Ihr Worker-Knoten auf API-Endpunkte für Amazon EC2, Amazon ECR und Amazon S3 zugreifen kann.

**Hinweis:**Konfigurieren Sie diese Dienste über öffentliche Endpunkte oder AWS PrivateLink.

Stellen Sie sicher, dass in Ihrem Subnetz genügend freie IP-Adressen verfügbar sind

Führen Sie den folgenden Befehl aus, um die verfügbaren IP-Adressen in jedem Subnetz in der Amazon Virtual Private Cloud (Amazon VPC)-ID aufzulisten:

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

**Hinweis:**Der AvailableIpAddressCount muss für das Subnetz, in dem die Pods gestartet werden, größer als 0 sein.

Prüfen Sie, ob Ihre Sicherheitsgruppenlimits erreicht wurden

Wenn Sie die Limiten Ihrer Sicherheitsgruppe pro Elastic Netzwerk-Schnittstelle erreichen, kann Ihre Pod-Netzwerk-Konfiguration fehlschlagen.

Weitere Informationen finden Sie unter Amazon VPC-Kontingente.

Stellen Sie sicher, dass Sie die neueste stabile Version des CNI-Plugins ausführen

Um zu bestätigen, dass Sie über die neueste Version des CNI-Plugins verfügen, siehe Aktualisieren des selbstverwalteten Amazon VPC CNI-Plugins für Kubernetes.

Weitere Informationen zur Problembehandlung finden Sie auf der AWS GitHub-Problemseite und in den Versionshinweisen für das CNI-Plugin.

Überprüfen Sie die Protokolle des VPC-CNI-Plugins auf dem Worker-Knoten

Wenn Sie einen Pod erstellen und dem Container keine IP-Adresse zugewiesen wird, erhalten Sie die folgende Fehlermeldung:

failed to assign an IP address to container

Um die Protokolle zu überprüfen, wechseln Sie in das Verzeichnis /var/log/aws-routed-eni/ und suchen Sie dann nach den Dateinamen plugin.log und ipamd.log.

Stellen Sie sicher, dass Ihr Kubelet die Docker-Container-Images abruft

Wenn Ihr Kubelet die Docker-Container-Images für die Container Kube-Proxy und amazon-k8s-cni nicht abruft, erhalten Sie die folgende Fehlermeldung:

network plugin is not ready: cni config uninitialized

Stellen Sie sicher, dass Sie den Amazon EKS-API-Serverendpunkt vom Worker-Knoten aus erreichen können.

Stellen Sie sicher, dass der WARM_PREFIX_TARGET-Wert richtig gesetzt ist

**Hinweis:**Dies gilt nur, wenn die Präfixdelegierung aktiviert ist. Wenn die Präfixdelegierung aktiviert ist, überprüfen Sie, ob die folgende protokollierte Fehlermeldung angezeigt wird:

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

WARM_PREFIX_TARGET muss auf einen Wert größer oder gleich 1 gesetzt werden. Wenn es auf 0 gesetzt ist, erhalten Sie die folgende Fehlermeldung:

Weitere Informationen finden Sie unter CNI-Konfigurationsvariablen auf der GitHub-Website.

Überprüfen Sie den reservierten Speicherplatz im Subnetz

**Hinweis:**Dies gilt nur, wenn die Präfixdelegierung aktiviert ist. Wenn die Präfixdelegierung aktiviert ist, überprüfen Sie, ob die folgende protokollierte Fehlermeldung angezeigt wird:

InsufficientCidrBlocks

Stellen Sie sicher, dass ausreichend /28 IP-CIDR-Blöcke (16 IPs) im Subnetz verfügbar sind. Alle 16 IPs müssen zusammenhängend sein. Wenn Sie keinen /28-Bereich kontinuierlicher IPs haben, erhalten Sie den Fehler InsufficientCidrBlocks.

Um den Fehler zu beheben, erstellen Sie ein neues Subnetz und starten Sie die Pods von dort aus. Verwenden Sie außerdem eine Amazon EC2-Subnetz-CIDR-Reservierung, um Speicherplatz in einem Subnetz mit einem zugewiesenen Präfix zu reservieren. Weitere Informationen finden Sie unter Verwenden von Subnetz-CIDR-Reservierungen.

Aktualisierungen, die mit Infrastructure as Code (IaC) vorgenommen wurden, werden bei Konflikten rückgängig gemacht

Wenn Sie von Amazon EKS verwaltete Add-Ons verwenden, werden die Aktualisierungsfehler, die die folgenden Dienste verwenden, rückgängig gemacht, wenn die Konfliktmethode nicht definiert ist:

• AWS Cloud Development Kit (AWS CDK)
• AWS CloudFormation
• eksctl (von der eksctl-Website)

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.
• Verwenden Sie die Overwrite-Methode, um die Standardkonfiguration für die Add-Ons festzulegen. Sie müssen OVERWRITE verwenden; wenn Sie von selbstverwalteten zu Amazon EKS-verwalteten Add-Ons wechseln.
• Verwenden Sie die PRESERVE-Methode, wenn Sie benutzerdefinierte Konfigurationen wie WARM_IP_TARGET oder benutzerdefiniertes Networking verwenden.

Knoten befinden sich im Status NotReady

Wenn Sie AWS-Knoten haben, die sich nicht im Status Läuft befinden, ist es üblich, dass sich Knoten im Status NotReady befinden. Weitere Informationen finden Sie unter Wie kann ich den Status meiner Knoten vom Status NotReady oder Unknown in den Status Ready ändern?

Herausforderungen bei der benutzerdefinierten Networking-Konfiguration

Wenn benutzerdefiniertes Networking für das VPC-CNI aktiv ist, müssen die benutzerdefinierten Ressourcendefinitionen (CRDs) von ENIConfig das richtige Subnetz und die richtigen Sicherheitsgruppen definieren.

Um zu überprüfen, ob benutzerdefiniertes Networking aktiv ist, beschreiben Sie den aws-Knoten-Pod im Kube-System-Namespace. Prüfen Sie dann, ob die folgende Umgebungsvariable auf true gesetzt ist:

AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG

Wenn benutzerdefiniertes Networking aktiv ist, überprüfen Sie, ob die CRDs richtig konfiguriert sind.

kubectl get ENIConfig -A -o yaml

Beschreiben Sie jeden Eintrag, der dem Namen der Availability Zone entspricht. Die Subnetz-IDs stimmen mit der Platzierung der VPC und des Worker-Knotens überein. Die Sicherheitsgruppen sind zugänglich oder werden mit der Cluster-Sicherheitsgruppe gemeinsam genutzt. Weitere Informationen zu bewährten Methoden finden Sie in den Amazon EKS Best Practices Guides auf der GitHub-Website.

---