Wie behebe ich Fehler bei der Erstellung von verwalteten Amazon-EKS-Knotengruppen?

Lösung

Verwendung des Automatisierungs-Runbooks, um häufig auftretende Probleme zu identifizieren

Verwende das Runbook AWSSupport-TroubleshootEKSWorkerNode, um häufig auftretende Probleme zu finden.

Wichtig: Damit die Automatisierung funktioniert, müssen die Worker-Knoten berechtigt sein, auf den AWS Systems Manager zuzugreifen, und der Systems Manager muss ausgeführt werden. Um die Genehmigung zu erteilen, hänge die von AWS verwaltete Richtlinie AmazonSSMManagedInstanceCore an die AWS Identity and Access Management (IAM, Identitäts- und Zugriffsmanagement)-Rolle an, die deinem Amazon Elastic Compute Cloud (EC2)-Instance-Profil entspricht. Dies ist die Standardkonfiguration für von Amazon EKS verwaltete Knotengruppen, die über eksctl erstellt werden.

Führe die folgenden Schritte aus:

1. Öffne das Runbook.
2. Vergewissere dich, dass die AWS-Region in der AWS-Managementkonsole auf dieselbe Region wie dein Cluster eingestellt ist.
   Hinweis: Weitere Informationen zum Runbook findest du im Abschnitt Runbook-Details des Runbooks.
3. Gib im Abschnitt Eingabeparameter den Namen deines Clusters im Feld ClusterName und die Instance-ID im Feld WorkerID an.
4. (Optional) Gib im Feld AutomationAssumeRole die IAM-Rolle an, damit Systems Manager Aktionen ausführen kann. Wird nichts angegeben, werden die IAM-Berechtigungen der aktuellen IAM-Entität verwendet, um die Aktionen im Runbook auszuführen.
5. Wähle Ausführen.
6. Im Abschnitt Ausgaben erfährst du, warum dein Worker-Knoten deinem Cluster nicht beitreten kann und welche Schritte du ergreifen kannst, um den Fehler zu beheben.

Überprüfen der Anforderungen an den Datenverkehr für Worker-Knoten

Vergewissere dich, dass die Sicherheitsgruppe und die Worker-Node-Sicherheitsgruppe der Steuerebene mit den Anforderungen für eingehenden und ausgehenden Datenverkehr konfiguriert sind. Standardmäßig wendet Amazon EKS die Cluster-Sicherheitsgruppe auf die Instances in der Knotengruppe an, um die Kommunikation zwischen Knoten und der Steuerebene zu erleichtern. Wenn du in der Startvorlage für deine verwaltete Knotengruppe benutzerdefinierte Sicherheitsgruppen angibst, fügt Amazon EKS die Cluster-Sicherheitsgruppe nicht hinzu.

Überprüfen der IAM-Berechtigungen des Worker-Knotens

Stelle sicher, dass der IAM-Instance-Rolle, die dem Worker-Knoten zugeordnet ist, die Richtlinien AmazonEKSWorkerNodePolicy und AmazonEC2ContainerRegistryReadOnly angehängt sind.

Hinweis: Du musst die von Amazon verwaltete Richtlinie AmazonEKS_CNI_Policy an eine IAM-Rolle anhängen. Du kannst sie an die Knoten-Instance-Rolle anhängen. Es ist jedoch eine bewährte Methode, die Richtlinie einer Rolle zuzuordnen, die mit dem aws-node-Kubernetes-Servicekonto im kube-system-Namespace verknüpft ist. Weitere Informationen findest du unter Amazon VPC CNI-Plug-ins für die Verwendung von IRSA konfigurieren.

Sicherstellen, dass die Amazon VPC für deinen Cluster einen DNS-Hostnamen und eine DNS-Auflösung unterstützt

Nachdem du den privaten Zugriff für den EKS-Cluster-Endpunkt konfiguriert hast, musst du einen DNS-Hostnamen und eine DNS-Auflösung für die Amazon Virtual Private Cloud (Amazon VPC) aktivieren. Wenn du den privaten Endpunktzugriff aktivierst, erstellt Amazon EKS eine private gehostete Amazon Route 53-Zone für dich. Anschließend verknüpft Amazon EKS diese mit der Amazon VPC deines Clusters. Weitere Informationen findest du unter Steuern des Netzwerkzugriffs auf den Cluster-API-Serverendpunkt.

Aktualisieren der ConfigMap aws-auth mit der NodeInstanceRole deiner Worker-Knoten

Stelle sicher, dass die ConfigMap aws-auth korrekt mit der IAM-Rolle deiner Worker-Knoten konfiguriert ist und nicht mit dem Instance-Profil.

Festlegen der Tags für deine Worker-Knoten

Lege für die Tag-Eigenschaft deiner Worker-Knoten den Schlüssel auf kubernetes.io/cluster/clusterName und den Wert auf owned fest.

Sicherstellen, dass die Amazon-VPC-Subnetze für den Worker-Knoten über verfügbare IP-Adressen verfügen

Wenn deiner Amazon VPC die IP-Adressen ausgehen, ordne deiner bestehenden Amazon VPC ein sekundäres CIDR zu. Weitere Informationen findest du unter Amazon EKS-Netzwerkanforderungen für VPC und Subnetze anzeigen.

Sicherstellen, dass die Amazon EKS-Worker-Knoten den API-Serverendpunkt für den Cluster erreichen können

Du kannst Worker-Knoten in jedem Subnetz innerhalb deiner Cluster-VPC oder deines Peering-Subnetzes starten, wenn eine Internet-Route über die folgenden Gateways besteht:

• NAT
• Internet
• Transit

Wenn deine Worker-Knoten in einem eingeschränkten privaten Netzwerk gestartet werden, überprüfe, ob deine Worker-Knoten den Amazon-EKS-API-Serverendpunkt erreichen können. Weitere Informationen findest du in den Anforderungen für die Ausführung von Amazon EKS in einem privaten Cluster ohne ausgehenden Internetzugang.

Hinweis: Es hat sich bewährt, das NAT-Gateway in einem öffentlichen Subnetz für Knoten zu erstellen, die sich in einem privaten Subnetz befinden, das von einem NAT-Gateway unterstützt wird.

Wenn du keine AWS PrivateLink-Endpunkte verwendest, überprüfe den Zugriff auf API-Endpunkte über einen Proxyserver für die folgenden AWS-Services:

• Amazon EC2
• Amazon ECR
• Amazon S3

Um zu überprüfen, ob der Worker-Knoten Zugriff auf den API-Server hat, verwende SSH, um eine Verbindung herzustellen, und führe dann den folgenden netcat-Befehl aus:

nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443

Hinweis: Ersetze 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com durch deinen API-Serverendpunkt.

Überprüfe die kubelet-Protokolle, während du noch mit deiner Instance verbunden bist:

journalctl -f -u kubelet

Wenn die kubelet-Protokolle keine Informationen zur Ursache des Problems enthalten, überprüfe den Status des **kubelets ** auf dem Worker-Knoten:

sudo systemctl status kubelet

Sammle die Amazon-EKS-Protokolle und die Betriebssystemprotokolle für weitere Problembehebungen.

Sicherstellen, dass die API-Endpunkte die AWS-Region erreichen können

Verwende SSH, um eine Verbindung zu einem der Worker-Knoten herzustellen, und führe dann die folgenden Befehle für die einzelnen Services aus:

$ nc -vz ec2.region.amazonaws.com 443
$ nc -vz ecr.region.amazonaws.com 443
$ nc -vz s3.region.amazonaws.com 443

Hinweis: Ersetze die region durch die AWS-Region für deinen Worker-Knoten.

Konfigurieren der Benutzerdaten für deinen Worker-Knoten

Für Startvorlagen für verwaltete Knotengruppen mit einem bestimmten AMI musst du Bootstrap-Befehle für Worker-Knoten angeben, damit sie deinem Cluster beitreten können. Amazon EKS führt die Standard-Bootstrap-Befehle nicht mit deinen Benutzerdaten zusammen. Weitere Informationen findest du unter Einführung von Startvorlagen und benutzerdefinierter AMI-Unterstützung in verwaltete Knotengruppen in Amazon EKS und Spezifizieren eines AMI.

Beispiel für eine Startvorlage mit Bootstrap-Befehlen:

#!/bin/bashset -o xtrace/etc/eks/bootstrap.sh
${ClusterName} ${BootstrapArguments}

Hinweis: Ersetze ${ClusterName} durch den Namen deines Amazon-EKS-Clusters. Ersetze ${BootstrapArguments} bei Bedarf durch zusätzliche Bootstrap-Werte.

Ähnliche Informationen

Probleme mit Amazon EKS-Clustern und -Knoten beheben

Wie bringe ich meine Worker-Knoten dazu, meinem Amazon EKS-Cluster beizutreten?