Wie behebe ich Probleme bei Knoten, die Amazon-EKS-Anywhere-Clustern nicht beitreten können?

Kurzbeschreibung

Bevor du mit der Problembehandlung beginnst, stelle sicher, dass die Konfiguration die folgenden Anforderungen erfüllt:

• Du verfügst über einen Computer mit Administratorrechten, um Cluster-Lebenszyklusvorgänge auszuführen.
• Der Computer mit Administatorrechten, die Steuerebene und die Worker-Knoten befinden sich im selben Layer-2-Netzwerk.
• Dein Netzwerk unterstützt DHCP.
  Hinweis: Es hat sich bewährt, das Netzwerk so zu konfigurieren, dass bestimmte IP-Adressen für die Steuerebene und die Worker-Knoten ausgeschlossen werden.
• Du hast statische IP-Adressen für den Endpunkt der Steuerebene und andere Cluster-Knoten reserviert und statische IP-Adressen aus dem DHCP-Bereich ausgeschlossen.
• Der Server hat mindestens zwei vCPUs, 8 GB RAM und 25 GB Speicher für jeden Knoten.
• Die Elastic-Network-Schnittstelle unterstützt eine Vorbereitungs-Ausführungsumgebung (PXE).
• Du verfügst über VMware vSphere 7 oder 8 und VMware vCenter Server.
• Du hast die Kapazität, 6–10 virtuelle Maschinen (VMs) bereitzustellen. Außerdem führst du einen DHCP-Service im primären VM-Netzwerk für den Workload-Cluster aus.
• Das vSphere-Netzwerk ermöglicht den Zugriff auf vCenter Server, und du hast die erforderlichen IP-Adressen reserviert und aus dem DHCP ausgeschlossen.

Lösung

Fehler bei der Registrierung von Knoten

Du erhältst die folgende Fehlermeldung, wenn du die Konfigurationszuordnung von AWS IAM Authenticator für Kubernetes (aws-auth ConfigMap) nicht auf einen Cluster anwendest:

„Unable to register node with API server err=Unauthorized.“

Hinweis: Die Konfigurationszuordnung bietet die rollenbasierten Zugriffssteuerungsberechtigungen (RBAC) system:bootstrappers und system:nodes für Knoten, um sich im Cluster zu registrieren.

Um einen Fehler bei der Registrierung von Knoten zu beheben, füge deine AWS Identity and Access Management (IAM)-Rolle zur aws-auth ConfigMap hinzu.

Fehler „Unauthorized“

Du erhältst die Fehlermeldung „unauthorized“, wenn du eine verwaltete Knotengruppe löschst und der Knotenrolleneintrag anschließend aus der aws-auth ConfigMap gelöscht wird. Du kannst diesen Fehler identifizieren, wenn du die Kubelet-API-Anforderungen an den API-Server in deinen Kubelet-Protokollen überprüfst.

Um den Fehler „unauthorized“ zu beheben, füge deine IAM-Rolle erneut zur aws-auth ConfigMap hinzu.

Kubelet-Abhängigkeitsfehler

CA Dateifehler

Du erhältst die folgende Fehlermeldung, wenn ein Knoten die Datei der Zertifizierungsstelle (CA) nicht aus einem Cluster abrufen kann oder das Skript /etc/eks/bootstrap.sh ausgeführt wird:

„Failed to construct kubelet dependencies" err="unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory.“

Gehe wie folgt vor, um einen Kubelet-Abhängigkeitsfehler zu beheben:

1. Überprüfe den /var/log/cloud-init-output.log-Stream in den cloud-init-Protokollen auf die folgende Fehlermeldung:
   „Connect timeout on endpoint URL: https://eks.us-east-1.amazonaws.com/clusters/vg-xx-uat Exited with error on line 291“

2. Führe den folgenden curl -vk-Befehl aus, um zu überprüfen, ob du den Amazon-EKS-API-Endpunkt erreichen kannst:

   curl -vk https://eks.us-east-1.amazonaws.com/

3. Lösche den Amazon-EKS-Endpunkt.

Wenn du den Endpunkt nicht erreichen kannst, ergreife die folgenden Maßnahmen:

• Füge bei privaten Endpunkten den Knoten in derselben Virtual Private Cloud (VPC) oder in demselben verbundenen Netzwerk ein. Private Endpunkte sind nicht öffentlich zugänglich.
• Konfiguriere die Sicherheitsgruppen, Routing-Tabellen und die Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) für öffentliche Endpunkte. Sicherheitsgruppen, Routing-Tabellen und Netzwerk-ACLs müssen ausgehenden HTTPS-Datenerkehr (TCP 443) zum Amazon-EKS-Endpunkt zulassen. Weitere Informationen findest du unter Überlegungen zu VPC und Subnetzen.
• Stelle für Knoten in privaten Subnetzen sicher, dass du über ein NAT-Gateway oder einen VPC-Endpunkt für den ausgehenden Internetzugang verfügst.
• Setze enableDnsHostnames and enableDnsSupport in der VPC auf wahr.
• Stelle sicher, dass der DHCP-Optionssatz AmazonProvidedDNS enthält.

Fehler bei der Validierung

Du erhältst die folgende Validierungsfehlermeldung, wenn Kubernetes die Ressource der Steuerebene „kubeadmcontrolplanes.controlplane.cluster.x-k8s.io“ im Workload-Cluster nicht finden kann:

„Validation failed: kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 'eksa-sit' not found; no CAPI cluster objects present on workload cluster 'eksa-sit'...“

Gehe wie folgt vor, um einen Validierungsfehler zu beheben:

1. Greife auf den Knoten der Steuerebene zu, auf dem der kubeadm-Prozess ausgeführt wird.

2. Führe den folgenden journalctl-Befehl aus, um Informationen zur Problembehandlung aus den kubelet-Serviceprotokollen abzurufen:

   journalctl -u kubelet -f

3. Identifiziere in der Protokollausgabe die Cluster-Komponente, die den Validierungsfehler verursacht.

Bootstrap-Token-Fehler

Aufgrund eines Bugs in Version 1.0.2 der Amazon-EKS-Anywhere-Cluster tritt ein Bootstrap-Token-Fehler auf. Weitere Informationen findest du unter bootstrap tokens can expire before they can be used if the bootstrap cluster's time is sufficiently behind the workload cluster (Bootstrap-Tokens können ablaufen, bevor sie verwendet werden können, wenn die Zeit des Bootstrap-Clusters ausreichend hinter dem Workload-Cluster liegt) auf der GitHub-Website .

Weitere Informationen zur Behebung dieses Fehler findest du unter Fix to enable bootstrap secret rotation if the secret itself missing (Fix, um die Rotation von Bootstrap-Secrets zu ermöglichen, wenn das Secret selbst fehlt) auf der GitHub-Website.

Fehler bei fehlendem Bootstrap-Token-Secret

Du kannst eine Fehlermeldung erhalten, wenn du den Befehl eksctl anywhere upgrade cluster -f cluster.yaml ausführst. Der Fehler tritt auf, weil ein Bootstrap-Token-Secret aufgrund eines Fehlers im Workflow fehlt. Der Bug blockiert neue Knoten, die versuchen, deinem Cluster beizutreten.

Führe die folgenden Schritte aus, um diesen Fehler zu beheben:

1. Lösche die neu bereitgestellte Maschine manuell, um das Bootstrap-Token zu aktualisieren.
2. Wenn sich der Cluster in einem fehlerfreien Zustand befindet, sichere die Kubernetes-Cluster-API (CAPI) und verschiebe die CAPI-Komponenten in den Verwaltungscluster. Anweisungen findest du unter Cluster-Upgrade schlägt mit Verwaltungskomponenten auf dem Bootstrap-Cluster fehl.

Interne Fehler

Du erhältst die folgende interne Fehlermeldung, wenn der Webhook-Validierungs.Service Konnektivitätsprobleme hat:

„Error from server (InternalError): Internal error occurred: failed calling webhook...“

Gehe wie folgt vor, um einen internen Fehler zu beheben:

1. Führe den folgenden kubectl get pods-Befehl aus, um deinen eks-controller-manager-Pod zu finden:

   kubectl get pods -n kube-system | grep eks-controller-manager

2. Führe den folgenden kubectl logs-Befehl aus, um die Protokolle für den Pod anzuzeigen:

   kubectl logs eksa-controller-manager-pod-name -n kube-system

   Hinweis: Ersetze eksa-controller-manager-pod-name durch den Namen deines eksa-controller-manager-Pods.

3. Verwende die Informationen aus der Protokollausgabe, um das Problem zu beheben.

Du erhältst die folgende interne Fehlermeldung, wenn der Prozess zur Leader-Auswahl in der Kubernetes-Steuerebene zeitlich abgelaufen ist:

„Failed to update lock: etcdserver: request timed out failed to renew lease eksa-system/f64ae69e.eks.amazonaws.com: timed out waiting for the condition Error setup problem running manager {'error': 'leader election lost'}...“

Du kannst diese Fehlermeldung auch erhalten, wenn der Prozess zur Leader-Auswahl das Leasing aufgrund einer Ressourcensperre in etcd nicht verlängert.

Zu den Grundursachen des Fehlers gehören Netzwerkverzögerungen, Nichtverfügbarkeit des etcd oder Probleme mit Ressourcenkonflikten.

Um diesen internen Fehler zu beheben, lösche den eksa-controller-manager-Pod. Ein Ersatz-Pod wird gestartet und wechselt in den Status Wird ausgeführt.

Hinweis: Interne Fehler können in Versionen 1.21 oder früher von Amazon-EKS-Anywhere-Clustern auftreten. Um diesen Fehler zu vermeiden, empfiehlt es sich, den Cluster auf die neueste Kubernetes-Version zu aktualisieren.

PLEG-Fehler

Du erhältst die folgende Fehlermeldung, wenn der Pod Lifecycle Event Generator (PLEG) ein Problem hat:

„PLEG is not healthy: pleg was last seen active.“

Gehe wie folgt vor, um einen PLEG-Fehler zu beheben:

• Suche nach Container-Laufzeitlatenzen oder Timeouts wie Leistungseinbußen, Deadlocks oder Bugs, die bei Remote-Anforderungen auftreten, und behebe diese.
• Vermeide zu viele ausgeführte Pods für Hostressourcen oder zu viele ausgeführte Pods auf Hosts mit hohen Anforderungen.
• Behebe Ressourcenprobleme im Knoten.

Weitere Informationen zu PLEG findest du unter Pod Lifecycle Event Generator: Understanding the "PLEG is not healthy" issue in Kubernetes (Pod Lifecycle Event Generator:: Informationen zum Problem „PLEG ist nicht fehlerfrei“ in Kubernetes) auf der Red Hat Developer-Website.

Fehler „NotReady,SchedulingDisabled“

Du erhältst eine Fehlermeldung, wenn sich einer der Knoten im Amazon-EKS-Anywhere-Cluster im Status NotReady,SchedulingDisabled befindet. Dies liegt daran, dass die physische Maschine, auf der die vSphere-VM ausgeführt wurde, nicht mehr existiert. Der Cluster steckt in der Skalierungsphase fest und die neuen Knoten können nicht hochgefahren werden.

Gehe wie folgt vor, um den Statusfehler NotReady,SchedulingDisabled zu beheben:

1. Entferne den Finalizer der Maschine.
2. Führe den folgenden Befehl kubectl delete node aus, um den ausstehenden Amazon-EKS-Knoten zu löschen und einen neuen Knoten hochfahren zu lassen:

   kubectl delete node your_node_name

   Hinweis: Ersetze your_node_name durch den Namen des Knotens, den du löschen möchtest.

Ähnliche Informationen

Was ist EKS Anywhere?

Container-Laufzeit-Netzwerk nicht bereit