**Unterstützung für die Verbesserung dieser Seite beitragen**
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Fehlerbehebung bei Hybridknoten
In diesem Thema werden einige gängige Fehler behandelt, die bei der Verwendung von Amazon EKS Hybrid Nodes auftreten können, sowie deren Behebung. Weitere Informationen zur Fehlerbehebung finden Sie unter [Beheben von Problemen mit Amazon-EKS-Clustern und -Knoten](troubleshooting.md) und dem [Knowledge Center-Tag für Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) auf * AWS re:POST*. Wenn Sie das Problem nicht lösen können, wenden Sie sich an den AWS Support.
**Knoten-Fehlerbehebung mit `nodeadm debug`** Sie können den `nodeadm debug`-Befehl von Ihren Hybridknoten aus ausführen, um zu überprüfen, ob die Netzwerk- und Anforderungen an den Anmeldeinformationen erfüllt sind. Weitere Informationen zum `nodeadm debug`-Befehl finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md).
**Probleme mit Ihren Hybridknoten mithilfe von Cluster-Erkenntnissen erkennen** Amazon EKS Cluster Insights umfasst *Erkenntnisprüfungen*, die gängige Probleme mit der Konfiguration von EKS-Hybridknoten in Ihrem Cluster erkennen. Sie können die Ergebnisse aller Insight-Checks über die AWS-Managementkonsole, AWS CLI und die anzeigen AWS SDKs. Weitere Informationen über Cluster-Erkenntnisse finden Sie unter [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md).
## Fehlerbehebung bei der Installation von Hybridknoten
Die folgenden Themen zur Fehlerbehebung beziehen sich auf die Installation der Abhängigkeiten der Hybridknoten auf Hosts mit dem `nodeadm install`-Befehl.
** `nodeadm`-Befehl fehlgeschlagen `must run as root` **
Der `nodeadm install`-Befehl muss mit einem Benutzer ausgeführt werden, der über Root- oder `sudo`-Berechtigungen auf Ihrem Host verfügt. Wenn Sie `nodeadm install` mit einem Benutzer ausführen, der nicht über Root- oder `sudo`-Berechtigungen verfügt, wird in der `nodeadm`-Ausgabe der folgende Fehler angezeigt.
```
"msg":"Command failed","error":"must run as root"
```
**Verbindung zu Abhängigkeiten nicht möglich**
Der Befehl `nodeadm install` installiert die für Hybridknoten erforderlichen Abhängigkeiten. Zu den Abhängigkeiten der Hybridknoten gehören`containerd`, `kubelet``kubectl`, und AWS SSM- oder AWS IAM Roles Anywhere-Komponenten. Sie müssen von Ihrem Ausführungsstandort von `nodeadm install` aus Zugriff haben, um diese Abhängigkeiten herunterzuladen. Weitere Informationen zur Liste der Speicherorte, auf die Sie zugreifen können müssen, finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md). Wenn Sie keinen Zugriff haben, werden in der `nodeadm install`-Ausgabe Fehlermeldungen ähnlich den folgenden angezeigt.
```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```
**Paket-Manager konnte nicht aktualisiert werden**
Der Befehl `nodeadm install` führt `apt update` oder `yum update` oder `dnf update` aus, bevor die Abhängigkeiten der Hybridknoten installiert werden. Wenn dieser Schritt nicht erfolgreich ist, werden möglicherweise Fehler ähnlich den folgenden angezeigt. Zur Behebung können Sie `apt update` oder `yum update` oder `dnf update` ausführen, bevor Sie `nodeadm install` ausführen, oder Sie können versuchen, `nodeadm install` erneut auszuführen.
```
failed to run update using package manager
```
**Zeitüberschreitung oder Kontext-Frist überschritten**
Wenn beim Ausführen von `nodeadm install` in verschiedenen Phasen des Installationsprozesses Probleme mit Fehlern auftreten, die auf eine Zeitüberschreitung oder eine überschrittene Kontextfrist hinweisen, liegt dies möglicherweise an einer langsamen Verbindung, welche die Installation der Abhängigkeiten der Hybridknoten vor Ablauf der Zeitüberschreitungen verhindert. Um diese Probleme zu umgehen, können Sie versuchen, das `--timeout`-Flag in `nodeadm` zu verwenden, um die Dauer der Zeitüberschreitungen für das Herunterladen der Abhängigkeiten zu verlängern.
```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
```
## Fehlerbehebung beim Verbinden von Hybridknoten
Die Themen zur Fehlerbehebung in diesem Abschnitt beziehen sich auf den Prozess der Verbindung von Hybridknoten mit EKS-Clustern mithilfe des `nodeadm init`-Befehls.
**Betriebsfehler oder nicht unterstütztes Schema**
Wenn Sie bei der Ausführung von `nodeadm init` Fehler im Zusammenhang mit `operation error` oder `unsupported scheme` entdecken, überprüfen Sie Ihr `nodeConfig.yaml`, um sicherzustellen, dass es richtig formatiert und an `nodeadm` übergeben wird. Weitere Informationen zum Format und den Optionen für `nodeConfig.yaml` finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md).
```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```
**Für die IAM-Rolle für Hybridknoten fehlen Berechtigungen für die `eks:DescribeCluster`-Aktion**
`nodeadm`Versucht bei der Ausführung`nodeadm init`, Informationen über Ihren EKS-Cluster zu sammeln, indem die `DescribeCluster` EKS-Aktion aufgerufen wird. Wenn Ihre IAM-Rolle Hybrid Nodes nicht über die Berechtigung für die `eks:DescribeCluster` Aktion verfügt, müssen Sie Ihren Kubernetes-API-Endpunkt, das Cluster-CA-Bundle und den IPv4 Service-CIDR in der Knotenkonfiguration übergeben, an die Sie bei der Ausführung übergeben`nodeadm`. `nodeadm init` Weitere Informationen zu den erforderlichen Berechtigungen für die IAM-Rolle für Hybridknoten finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```
**Für die IAM-Rolle für Hybridknoten fehlen Berechtigungen für die `eks:ListAccessEntries`-Aktion**
`nodeadm`Versucht bei der Ausführung zu überprüfen`nodeadm init`, ob Ihr EKS-Cluster über einen Zugriffseintrag des Typs verfügt, der mit der IAM-Rolle Hybrid Nodes `HYBRID_LINUX` verknüpft ist, indem die EKS-Aktion aufgerufen wird. `ListAccessEntries` Wenn Ihre Hybrid Nodes IAM-Rolle nicht über die Berechtigung für die `eks:ListAccessEntries` Aktion verfügt, müssen Sie das `--skip cluster-access-validation` Flag übergeben, wenn Sie den Befehl ausführen. `nodeadm init` Weitere Informationen zu den erforderlichen Berechtigungen für die IAM-Rolle für Hybridknoten finden Sie unter [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```
**Knoten-IP nicht im CIDR des Fern-Knotennetzwerks**
Bei der Ausführung kann ein Fehler auftreten`nodeadm init`, wenn sich die IP-Adresse des Knotens nicht im angegebenen Remote-Knoten-Netzwerk CIDRs befindet. Der Fehler sieht in etwa wie im folgenden Beispiel aus:
```
node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]
```
Dieses Beispiel zeigt einen Knoten mit IP 10.18.0.1, der versucht, einem Cluster mit dem Remote-Netzwerk CIDRs 10.0.0.0/16 und 192.168.0.0/16 beizutreten. Der Fehler tritt auf, weil 10.18.0.1 nicht in einem der Bereiche liegt.
Bestätigen Sie, dass Sie Ihr `RemoteNodeNetworks` richtig konfiguriert haben, um alle Knoten-IP-Adressen einzuschließen. Weitere Informationen zur Netzwerkkonfiguration finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md).
+ Führen Sie den folgenden Befehl in der Region aus, in der sich Ihr Cluster befindet, um Ihre `RemoteNodeNetwork`-Konfigurationen zu überprüfen. Überprüfen Sie, ob die in der Ausgabe aufgeführten CIDR-Blöcke den IP-Bereich Ihres Knotens enthalten und mit den in der Fehlermeldung aufgeführten CIDR-Blöcken übereinstimmen. Wenn sie nicht übereinstimmen, stellen Sie sicher, dass der Cluster-Name und die Region in Ihrem `nodeConfig.yaml` mit dem gewünschten Cluster übereinstimmen.
```
aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Überprüfen Sie, ob Sie mit dem gewünschten Knoten arbeiten:
+ Bestätigen Sie, dass Sie sich auf dem richtigen Knoten befinden, indem Sie prüfen, ob dessen Hostname und IP-Adresse mit denen übereinstimmen, die Sie beim Cluster registrieren möchten.
+ Bestätigen Sie, dass sich dieser Knoten im korrekten On-Premises-Netzwerk befindet (das Netzwerk, dessen CIDR-Bereich während der Cluster-Einrichtung als `RemoteNodeNetwork` registriert wurde).
Wenn Ihre Knoten-IP immer noch nicht Ihren Erwartungen entspricht, überprüfen Sie Folgendes:
+ Wenn Sie IAM Roles Anywhere verwenden, führt `kubelet` eine DNS-Abfrage für IAM Roles Anywhere `nodeName` durch und verwenden Sie eine mit dem Knotennamen verknüpfte IP-Adresse, sofern verfügbar. Wenn Sie DNS-Einträge für Ihre Knoten verwalten, stellen Sie sicher, dass diese Einträge auf Ihr Remote-Knotennetzwerk verweisen. IPs CIDRs
+ Wenn Ihr Knoten über mehrere Netzwerkschnittstellen verfügt, wählen Sie `kubelet` möglicherweise standardmäßig eine Schnittstelle mit einer IP-Adresse außerhalb Ihres Remote-Knoten-Netzwerks CIDRs aus. Um eine andere Schnittstelle zu verwenden, geben Sie deren IP-Adresse mithilfe des Flags `--node-ip` `kubelet` in Ihrem `nodeConfig.yaml` an. Weitere Informationen finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). Sie können die Netzwerkschnittstellen und IP-Adressen Ihres Knotens anzeigen, indem Sie den folgenden Befehl auf Ihrem Knoten ausführen:
```
ip addr show
```
**Hybridknoten werden im EKS-Cluster nicht angezeigt**
Wenn Sie `nodeadm init` ausgeführt haben und es abgeschlossen wurde, Ihre Hybridknoten jedoch nicht in Ihrem Cluster angezeigt werden, liegen möglicherweise Probleme mit der Netzwerkverbindung zwischen Ihren Hybridknoten und der EKS-Steuerebene vor. Möglicherweise haben Sie die erforderlichen Sicherheitsgruppenberechtigungen nicht konfiguriert oder Sie verfügen möglicherweise nicht über die erforderliche Zuordnung Ihrer IAM-Rolle für Hybridknoten zur rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes. Sie können den Debugging-Prozess starten, indem Sie den Status von `kubelet` und die `kubelet`-Protokolle mit den folgenden Befehlen überprüfen. Führen Sie die folgenden Befehle von den Hybridknoten aus, die Ihrem Cluster nicht beitreten konnten.
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Kommunikation mit Cluster nicht möglich**
Wenn Ihr Hybridknoten nicht mit der Cluster-Steuerebene kommunizieren konnte, werden möglicherweise Protokolle ähnlich den folgenden angezeigt.
```
"Failed to ensure lease exists, will retry" err="Get ..."
```
```
"Unable to register node with API server" err="Post ..."
```
```
Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout
```
Wenn diese Meldungen angezeigt werden, überprüfen Sie Folgendes, um sicherzustellen, dass die in [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md) aufgeführten Anforderungen für Hybridknoten erfüllt werden.
+ Vergewissern Sie sich, dass die an den EKS-Cluster übergebene VPC Routen zu Ihrem Transit Gateway (TGW) oder Virtual Private Gateway (VGW) für Ihren lokalen Knoten und optional Ihren Pod hat. CIDRs
+ Vergewissern Sie sich, dass Sie über eine zusätzliche Sicherheitsgruppe für Ihren EKS-Cluster verfügen, die Regeln für eingehenden Datenverkehr für Ihren lokalen Knoten und optional für den Pod enthält. CIDRs CIDRs
+ Bestätigen Sie, dass Ihr On-Premises-Router so konfiguriert ist, dass er den Datenverkehr zur und von der EKS-Steuerebene zulässt.
**Nicht autorisiert**
Wenn Ihr Hybridknoten mit der EKS-Steuersebene kommunizieren konnte, sich jedoch nicht registrieren konnte, werden möglicherweise Protokolle angezeigt, die den folgenden ähneln. Beachten Sie, dass der wesentliche Unterschied in den folgenden Protokollmeldungen der `Unauthorized`-Fehler ist. Dies weist darauf hin, dass der Knoten seine Aufgaben nicht ausführen konnte, da er nicht über die erforderlichen Berechtigungen verfügt.
```
"Failed to ensure lease exists, will retry" err="Unauthorized"
```
```
"Unable to register node with API server" err="Unauthorized"
```
```
Failed to contact API server when waiting for CSINode publishing: Unauthorized
```
Wenn Sie diese Meldungen sehen, überprüfen Sie Folgendes, um sicherzustellen, dass die Anforderungen für Hybridknoten in [Vorbereitung der Anmeldeinformationen für Hybridknoten](hybrid-nodes-creds.md) und [Vorbereitung des Cluster-Zugriffs für Hybridknoten](hybrid-nodes-cluster-prep.md) erfüllt werden.
+ Bestätigen Sie, dass die Identität der Hybridknoten mit Ihrer erwarteten IAM-Rolle für Hybridknoten übereinstimmt. Dies kann durch Ausführen von `sudo aws sts get-caller-identity` von Ihren Hybridknoten aus erfolgen.
+ Bestätigen Sie, dass Ihre IAM-Rolle für Hybridknoten über die erforderlichen Berechtigungen verfügt.
+ Vergewissern Sie sich, dass Sie in Ihrem Cluster einen EKS-Zugriffseintrag für Ihre Hybrid Nodes IAM-Rolle haben, oder vergewissern Sie sich, dass Sie `aws-auth` ConfigMap einen Eintrag für Ihre Hybrid Nodes IAM-Rolle haben. Wenn Sie EKS-Zugriffseinträge verwenden, bestätigen Sie, dass Ihr `HYBRID_LINUX`-Zugriffseintrag für Ihre IAM-Rolle für Hybridknoten den Zugriffstyp hat. Wenn Sie die verwenden, stellen Sie sicher `aws-auth` ConfigMap, dass Ihr Eintrag für die IAM-Rolle Hybrid Nodes die unter beschriebenen Anforderungen und Formatierungen erfüllt. [Vorbereitung des Cluster-Zugriffs für Hybridknoten](hybrid-nodes-cluster-prep.md)
### Hybridknoten sind beim EKS-Cluster registriert, zeigen aber den Status `Not Ready` an
Wenn Ihre Hybridknoten erfolgreich bei Ihrem EKS-Cluster registriert wurden, die Hybridknoten jedoch den Status `Not Ready` anzeigen, müssen Sie zunächst den Status Ihrer Container Networking Interface (CNI) überprüfen. Wenn Sie kein CNI installiert haben, wird erwartet, dass Ihre Hybridknoten den Status `Not Ready` haben. Sobald ein CNI installiert ist und erfolgreich ausgeführt wird, werden die Knoten auf den Status `Ready` aktualisiert. Wenn Sie versucht haben, ein CNI zu installieren, es aber nicht erfolgreich ausgeführt wird, finden Sie weitere Informationen unter [CNI-Fehlerbehebung bei Hybridknoten](#hybrid-nodes-troubleshooting-cni) auf dieser Seite.
**Anfragen zum Signieren von Zertifikaten (CSRs) bleiben hängen. Ausstehend**
Wenn Sie nach dem Verbinden der Hybridknoten mit Ihrem EKS-Cluster feststellen, dass noch ausstehende Knoten CSRs für Ihre Hybridknoten vorliegen, erfüllen Ihre Hybridknoten nicht die Anforderungen für die automatische Genehmigung. CSRs für Hybridknoten werden automatisch genehmigt und ausgestellt, wenn die CSRs vier Hybridknoten von einem Knoten mit `eks.amazonaws.com/compute-type: hybrid` Bezeichnung erstellt wurden und der CSR die folgenden alternativen Subject Names (SANs) hat: mindestens ein DNS-SAN, das dem Knotennamen und der IP entspricht, SANs gehört zum Netzwerk CIDRs des Remote-Knotens.
**Hybridprofil ist bereits vorhanden**
Wenn Sie Ihre `nodeadm`-Konfiguration geändert haben und versuchen, den Knoten mit der neuen Konfiguration erneut zu registrieren, wird möglicherweise ein Fehler angezeigt, der besagt, dass das Hybrid-Profil bereits vorhanden ist, sich sein Inhalt jedoch geändert hat. Anstatt zwischen Konfigurationsänderungen `nodeadm init` auszuführen, führen Sie `nodeadm uninstall` gefolgt von `nodeadm install` und `nodeadm init` aus. Dadurch wird eine ordnungsgemäße Bereinigung der Konfigurationsänderungen sichergestellt.
```
"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"
```
**Hybridknoten konnte die private API nicht auflösen**
Wenn nach dem Ausführen von `nodeadm init` in den `kubelet`-Protokollen ein Fehler angezeigt wird, der auf Fehler beim Kontaktieren des EKS Kubernetes-API-Servers aufgrund von `no such host` hinweist, müssen Sie möglicherweise Ihren DNS-Eintrag für den EKS Kubernetes-API-Endpunkt in Ihrem On-Premises-Netzwerk oder auf Host-Ebene ändern. Weitere Informationen finden Sie [in der * AWS Route53-Dokumentation* unter Weiterleiten eingehender DNS-Abfragen an Ihre VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html).
```
Failed to contact API server when waiting for CSINode publishing: Get ... no such host
```
**Hybridknoten können in der EKS-Konsole nicht angezeigt werden**
Wenn Sie Ihre Hybridknoten registriert haben, diese aber nicht in der EKS-Konsole anzeigen können, überprüfen Sie die Berechtigungen des IAM-Prinzipals, das Sie zum Anzeigen der Konsole verwenden. Der von Ihnen verwendete IAM-Prinzipal muss über bestimmte Mindestberechtigungen für IAM und Kubernetes verfügen, um Ressourcen in der Konsole anzuzeigen. Weitere Informationen finden Sie unter [Kubernetes-Ressourcen anzeigen in der AWS-Managementkonsole](view-kubernetes-resources.md).
## Fehlerbehebung beim Ausführen von Hybridknoten
Wenn Ihre Hybridknoten bei Ihrem EKS-Cluster registriert waren, den Status `Ready` hatten und dann in den Status `Not Ready` übergingen, gibt es eine Vielzahl von Problemen, die zu diesem fehlerhaften Status geführt haben könnten, z. B. der Mangel an ausreichenden Ressourcen für CPU, Arbeitsspeicher oder verfügbaren Speicherplatz auf dem Knoten oder die Trennung des Knotens von der EKS-Steuerebene. Sie können die folgenden Schritte verwenden, um Probleme mit Ihren Knoten zu beheben. Wenn Sie das Problem nicht lösen können, wenden Sie sich an den AWS Support.
Führen Sie `nodeadm debug` von Ihren Hybridknoten aus, um zu überprüfen, ob die Netzwerk- und Anmeldeinformationen erfüllt sind. Weitere Informationen zum `nodeadm debug`-Befehl finden Sie unter [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md).
**Knotenstatus abrufen**
```
kubectl get nodes -o wide
```
**Knoten-Bedingungen und -ereignisse prüfen**
```
kubectl describe node NODE_NAME
```
**Pod-Status abrufen**
```
kubectl get pods -A -o wide
```
**Pod-Bedingungen und -ereignisse prüfen**
```
kubectl describe pod POD_NAME
```
**Pod-Protokolle prüfen**
```
kubectl logs POD_NAME
```
**`kubectl`-Protokolle überprüfen**
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Pod-Aktivitätsprüfungen schlagen fehl oder Webhooks funktionieren nicht**
Wenn Anwendungen, Add-Ons oder Webhooks, die in Ihren Hybridknoten ausgeführt werden, nicht ordnungsgemäß starten, liegen möglicherweise Netzwerkprobleme vor, welche die Kommunikation mit den Pods blockieren. Damit die EKS-Steuerebene Webhooks kontaktieren kann, die auf Hybridknoten ausgeführt werden, müssen Sie Ihren EKS-Cluster mit einem Remote-Pod-Netzwerk konfigurieren und Routen für Ihren lokalen Pod-CIDR in Ihrer VPC-Routingtabelle haben, wobei das Ziel Ihr Transit Gateway (TGW), Virtual Private Gateway (VGW) oder ein anderes Gateway ist, das Sie verwenden, um Ihre VPC mit Ihrem lokalen Netzwerk zu verbinden. Weitere Informationen zu den Netzwerkanforderungen für Hybridknoten finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md). Sie müssen diesen Datenverkehr zusätzlich in Ihrer On-Premises-Firewall zulassen und sicherstellen, dass Ihr Router ordnungsgemäß an Ihre Pods weiterleiten kann. Weitere Informationen zu den Anforderungen für die Ausführung von Webhooks auf Hybridknoten finden Sie unter [Konfiguration von Webhooks für Hybridknoten](hybrid-nodes-webhooks.md).
Eine allgemeine Pod-Protokollnachricht für dieses Szenario wird unten angezeigt, wobei „ip-address“ die Cluster-IP für den Kubernetes-Service ist.
```
dial tcp :443: connect: no route to host
```
**`kubectl logs`oder Befehle funktionieren nicht (API-Befehle) `kubectl exec` `kubelet`**
Wenn bei Befehlen `kubectl attach` `kubectl cp``kubectl exec`,`kubectl logs`, und ein `kubectl port-forward` Timeout auftritt, während andere `kubectl` Befehle erfolgreich sind, hängt das Problem wahrscheinlich mit der Remote-Netzwerkkonfiguration zusammen. Diese Befehle stellen über den Cluster eine Verbindung zum `kubelet`-Endpunkt auf dem Knoten her. Weitere Informationen finden Sie unter [`kubelet`-Endpunkt](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api).
Stellen Sie sicher, dass Ihr Node IPs und Ihr Pod in das für Ihren Cluster CIDRs konfigurierte Remote-Knoten-Netzwerk und das Remote-Pod-Netzwerk IPs fallen. Verwenden Sie die folgenden Befehle, um die IP-Zuweisungen zu überprüfen.
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
Vergleichen Sie diese IPs mit Ihrem konfigurierten Remote-Netzwerk CIDRs , um sicherzustellen, dass das Routing korrekt ist. Die Anforderungen für die Netzwerkkonfiguration finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md).
## CNI-Fehlerbehebung bei Hybridknoten
Wenn beim ersten Starten von Cilium oder Calico mit Hybridknoten Probleme auftreten, liegt dies meistens an Netzwerkproblemen zwischen Hybridknoten oder den auf Hybridknoten ausgeführten CNI-Pods und der EKS-Steuerebene. Stellen Sie sicher, dass Ihre Umgebung die Anforderungen unter „Netzwerk für Hybridknoten vorbereiten“ erfüllt. Es ist sinnvoll, das Problem in Teilbereiche zu unterteilen.
EKS-Cluster-Konfiguration
Sind die RemotePodNetwork Konfigurationen RemoteNodeNetwork und korrekt?
VPC-Konfiguration
Gibt es Routen für das RemoteNodeNetwork und RemotePodNetwork in der VPC-Routingtabelle mit dem Ziel des Transit Gateway oder Virtual Private Gateways?
Sicherheitsgruppenkonfiguration
Gibt es Regeln für eingehenden und ausgehenden Datenverkehr? RemoteNodeNetwork RemotePodNetwork
On-Premises-Netzwerk
Gibt es Routen und Zugriff von und zur EKS-Steuerebene sowie von und zu den Hybridknoten und den in Hybridknoten ausgeführten Pods?
CNI-Konfiguration
Wenn Sie ein Overlay-Netzwerk verwenden, stimmt die IP-Pool-Konfiguration für das CNI mit der für den EKS-Cluster RemotePodNetwork konfigurierten überein, wenn Webhooks verwendet werden?
**Der Hybridknoten hat den Status `Ready` ohne installiertes CNI**
Wenn Ihre Hybridknoten den Status `Ready` anzeigen, Sie aber kein CNI auf Ihrem Cluster installiert haben, ist es möglich, dass sich auf Ihren Hybridknoten alte CNI-Artefakte befinden. Wenn Sie Cilium und Calico mit Tools wie Helm deinstallieren, werden die Ressourcen auf der Festplatte standardmäßig nicht von Ihren physischen oder virtuellen Rechnern entfernt. Darüber hinaus sind die benutzerdefinierten Ressourcendefinitionen (CRDs) für diese CNIs möglicherweise noch aus einer alten Installation auf Ihrem Cluster vorhanden. Weitere Informationen finden Sie in den Abschnitten „Cilium löschen“ und „Calico löschen“ unter [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md).
**Fehlerbehebung bei Cilium**
Wenn Sie Probleme bei der Ausführung von Cilium in Hybridknoten haben, lesen Sie [die Schritte zur Fehlerbehebung](https://docs.cilium.io/en/stable/operations/troubleshooting/) in der Cilium-Dokumentation. Die folgenden Abschnitte behandeln Probleme, die speziell bei der Bereitstellung von Cilium in Hybridknoten auftreten können.
**Cilium startet nicht**
Wenn die auf jedem Hybridknoten ausgeführten Cilium-Agenten nicht starten, überprüfen Sie die Protokolle der Cilium-Agent-Pods auf Fehler. Der Cilium-Agent benötigt eine Verbindung zum EKS-Kubernetes-API-Endpunkt, um zu starten. Der Startup des Cilium-Agenten schlägt fehl, wenn diese Konnektivität nicht richtig konfiguriert ist. In diesem Fall werden in den Pod-Protokollen des Cilium-Agenten Protokollmeldungen ähnlich den folgenden angezeigt.
```
msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
```
Der Cilium-Agent wird im Host-Netzwerk ausgeführt. Ihr EKS-Cluster muss für die Cilium-Konnektivität mit `RemoteNodeNetwork` konfiguriert sein. Bestätigen Sie, dass Sie über eine zusätzliche Sicherheitsgruppe für Ihren EKS-Cluster mit einer eingehenden Regel für Ihr `RemoteNodeNetwork` verfügen, dass Sie Routen in Ihrem VPC für Ihr `RemoteNodeNetwork` haben und dass Ihr On-Premises-Netzwerk richtig konfiguriert ist, um die Verbindung zur EKS-Steuerebene zu ermöglichen.
Wenn der Cilium-Operator läuft und einige Ihrer Cilium-Agenten laufen, aber nicht alle, stellen Sie sicher, dass Sie über einen verfügbaren Pod verfügen, IPs den Sie allen Knoten in Ihrem Cluster zuweisen können. Sie konfigurieren die Größe Ihres zuweisbaren Pods, CIDRs wenn Sie den Clusterpool IPAM mit in Ihrer Cilium-Konfiguration verwenden. `clusterPoolIPv4PodCIDRList` Die CIDR-Größe pro Knoten wird mit der Einstellung `clusterPoolIPv4MaskSize` in Ihrer Cilium-Konfiguration konfiguriert. Weitere Informationen finden Sie unter [Erweiterung des Cluster-Pools](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) in der Cilium-Dokumentation.
**Cilium BGP funktioniert nicht**
Wenn Sie die Cilium BGP-Steuerebene verwenden, um Ihre Pod- oder Service-Adressen in Ihrem On-Premises-Netzwerk bekannt zu geben, können Sie die folgenden Cilium-CLI-Befehle verwenden, um zu überprüfen, ob BGP die Routen zu Ihren Ressourcen bekannt gibt. Die Schritte zur Installation der Cilium-CLI finden Sie unter [Installation der Cilium-CLI](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) in der Cilium-Dokumentation.
Wenn BGP ordnungsgemäß funktioniert, sollten Ihre Hybridknoten den Sitzungsstatus `established` in der Ausgabe haben. Möglicherweise müssen Sie mit Ihrem Netzwerk-Team zusammenarbeiten, um die korrekten Werte für die lokalen AS, Peer-AS und Peer-Adressen Ihrer Umgebung zu ermitteln.
```
cilium bgp peers
```
```
cilium bgp routes
```
Wenn Sie Cilium BGP verwenden, um die IPs Dienste mit Typ zu bewerben`LoadBalancer`, müssen Sie sowohl auf Ihrem Dienst als auch auf Ihrem Dienst dieselbe Bezeichnung haben, die in Ihrem `CiliumLoadBalancerIPPool` Selektor verwendet werden sollte. `CiliumBGPAdvertisement` Es folgt ein Beispiel. Beachten Sie, dass, wenn Sie Cilium BGP verwenden, um die Dienste mit Typ zu bewerben LoadBalancer, die BGP-Routen während IPs des Neustarts des Cilium-Agenten unterbrochen werden können. Weitere Informationen finden Sie unter [Fehlerszenarien](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) in der Cilium-Dokumentation.
**Service**
```
kind: Service
apiVersion: v1
metadata:
name: guestbook
labels:
app: guestbook
spec:
ports:
- port: 3000
targetPort: http-server
selector:
app: guestbook
type: LoadBalancer
```
**CiliumLoadBalancerIPPool**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
name: guestbook-pool
labels:
app: guestbook
spec:
blocks:
- cidr:
serviceSelector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**CiliumBGPAdvertisement**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
name: bgp-advertisements-guestbook
labels:
advertise: bgp
spec:
advertisements:
- advertisementType: "Service"
service:
addresses:
- ExternalIP
- LoadBalancerIP
selector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**Calico-Fehlerbehebung**
Wenn Sie Probleme bei der Ausführung von Calico in Hybridknoten haben, lesen Sie die [Schritte zur Fehlerbehebung](https://docs.tigera.io/calico/latest/operations/troubleshoot/) in der Calico-Dokumentation. Die nachfolgenden Abschnitte behandeln Probleme, die speziell bei der Bereitstellung von Calico in Hybridknoten auftreten können.
Die nachfolgende Tabelle fasst die Calico-Komponenten zusammen und gibt an, ob sie standardmäßig im Knoten- oder Pod-Netzwerk ausgeführt werden. Wenn Sie Calico für die Verwendung von NAT für ausgehenden Pod-Datenverkehr konfiguriert haben, muss Ihr On-Premises-Netzwerk so konfiguriert sein, dass der Datenverkehr an die CIDR Ihres On-Premises-Knotens weitergeleitet wird. Außerdem müssen Ihre VPC-Routing-Tabellen mit einer Route für die CIDR Ihres On-Premises-Knotens konfiguriert sein, wobei Ihr Transit-Gateway (TGW) oder Ihr Virtual Private Gateway (VGW) als Ziel angegeben ist. Wenn Sie Calico nicht für die Verwendung von NAT für ausgehenden Pod-Datenverkehr konfigurieren, muss Ihr On-Premises-Netzwerk so konfiguriert sein, dass der Datenverkehr an Ihre On-Premises-Pod-CIDR weitergeleitet wird. Außerdem müssen Ihre VPC-Routing-Tabellen mit einer Route für Ihre On-Premises-Pod-CIDR konfiguriert sein, wobei Ihr Transit-Gateway (TGW) oder Ihr Virtual Private Gateway (VGW) als Ziel angegeben ist.
| Komponente | Netzwerk |
| --- | --- |
| Calico-API-Server | Knoten |
| Calico-Controller für Kubernetes | Pod |
| Calico-Knoten-Agent | Knoten |
| Calico `typha` | Knoten |
| Calico-CSI-Knoten-Treiber | Schote |
| Calico-Operator | Knoten |
**Calico-Ressourcen sind geplant oder werden in abgesperrten Knoten ausgeführt**
Die Calico-Ressourcen, die nicht als A ausgeführt werden, DaemonSet verfügen standardmäßig über flexible Toleranzen, sodass sie auf gesperrten Knoten geplant werden können, die noch nicht für die Planung oder Ausführung von Pods bereit sind. Sie können die Toleranzen für Ressourcen, die nicht zu DaemonSet Calico gehören, verschärfen, indem Sie Ihre Betreiberinstallation dahingehend ändern, dass sie Folgendes beinhaltet.
```
installation:
...
controlPlaneTolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
calicoKubeControllersDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
typhaDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
```
## Fehlerbehebung bei Anmeldeinformationen
Sowohl bei AWS SSM-Hybrid-Aktivierungen als auch bei AWS IAM Roles Anywhere können Sie überprüfen, ob die Anmeldeinformationen für die IAM-Rolle Hybrid Nodes auf Ihren Hybridknoten korrekt konfiguriert sind, indem Sie den folgenden Befehl von Ihren Hybridknoten aus ausführen. Überprüfen Sie, ob der Knotenname und der Name der IAM-Rolle für Hybridknoten Ihren Erwartungen entsprechen.
```
sudo aws sts get-caller-identity
```
```
{
"UserId": "ABCDEFGHIJKLM12345678910:",
"Account": "",
"Arn": "arn:aws: sts:::assumed-role/"
}
```
** Fehlerbehebung für AWS Systems Manager (SSM)**
Wenn Sie AWS SSM-Hybrid-Aktivierungen für Ihre Anmeldeinformationen für Hybridknoten verwenden, beachten Sie die folgenden SSM-Verzeichnisse und -Artefakte, die von auf Ihren Hybridknoten installiert werden. `nodeadm` Weitere Informationen zum SSM-Agenten finden Sie unter [Arbeiten mit dem SSM-Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) im * AWS Systems Manager Manager-Benutzerhandbuch*.
| Description | Speicherort |
| --- | --- |
| SSM-Agent | Ubuntu — `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL und — AL2023 `/usr/bin/amazon-ssm-agent` |
| SSM-Agent-Protokolle | `/var/log/amazon/ssm` |
| AWS Anmeldeinformationen | `/root/.aws/credentials` |
| CLI für SSM-Einrichtung | `/opt/ssm/ssm-setup-cli` |
**Neustart des SSM-Agenten**
Einige Probleme können durch einen Neustart des SSM-Agenten behoben werden. Verwenden Sie die folgenden Befehle, um das System neu zu starten.
**AL2023 und andere Betriebssysteme**
```
systemctl restart amazon-ssm-agent
```
**Ubuntu **
```
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
**Konnektivität zu SSM-Endpunkten überprüfen**
Bestätigen Sie, dass Sie von Ihren Hybridknoten aus eine Verbindung zu den SSM-Endpunkten herstellen können. Eine Liste der SSM-Endpunkte finden Sie unter [AWS -Systems-Manager-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Ersetzen Sie `us-west-2` den folgenden Befehl durch die AWS Region für Ihre AWS SSM-Hybrid-Aktivierung.
```
ping ssm.us-west-2.amazonaws.com
```
**Verbindungsstatus registrierter SSM-Instances anzeigen**
Sie können den Verbindungsstatus der Instances, die mit SSM-Hybrid-Aktivierungen registriert sind, mit dem folgenden AWS CLI-Befehl überprüfen. Ersetzen Sie die Rechner-ID durch die Rechner-ID Ihrer Instance.
```
aws ssm get-connection-status --target mi-012345678abcdefgh
```
**CLI-Prüfsummen-Fehlanpassung bei SSM-Einrichtung**
Wenn Sie beim Ausführen von `nodeadm install` ein Problem mit einer nicht übereinstimmenden `ssm-setup-cli`-Prüfsumme feststellen, sollten Sie sicherstellen, dass auf Ihrem Host keine älteren SSM-Installationen vorhanden sind. Wenn auf Ihrem Host ältere SSM-Installationen vorhanden sind, entfernen Sie diese und führen Sie `nodeadm install` erneut aus, um das Problem zu beheben.
```
Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.
```
**SSM `InvalidActivation` **
Wenn bei der Registrierung Ihrer Instance bei AWS SSM ein Fehler auftritt, überprüfen Sie, ob die Werte `region``activationCode`, und `activationId` in Ihrem `nodeConfig.yaml` richtig sind. Die AWS Region für Ihren EKS-Cluster muss mit der Region Ihrer SSM-Hybrid-Aktivierung übereinstimmen. Wenn diese Werte falsch konfiguriert sind, wird möglicherweise ein Fehler ähnlich dem folgenden angezeigt.
```
ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation
```
**SSM `ExpiredTokenException`: Das in der Anfrage enthaltene Sicherheits-Token ist abgelaufen**
Wenn der SSM-Agent die Anmeldeinformationen nicht aktualisieren kann, wird möglicherweise ein `ExpiredTokenException` angezeigt. Wenn Sie in diesem Szenario von Ihren Hybridknoten aus eine Verbindung zu den SSM-Endpunkten herstellen können, müssen Sie den SSM-Agenten möglicherweise neu starten, um eine Aktualisierung der Anmeldeinformationen zu erzwingen.
```
"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"
```
**SSM-Fehler beim Ausführen des Befehls „Rechner registrieren“**
Wenn beim Registrieren des Rechners bei SSM ein Fehler auftritt, müssen Sie `nodeadm install` möglicherweise erneut ausführen, um sicherzustellen, dass alle SSM-Abhängigkeiten ordnungsgemäß installiert sind.
```
"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"
```
**SSM `ActivationExpired` **
Wenn bei der Ausführung von `nodeadm init` ein Fehler bei der Registrierung der Instance bei SSM aufgrund einer abgelaufenen Aktivierung auftritt, müssen Sie eine neue SSM-Hybridaktivierung erstellen, `nodeConfig.yaml` mit `activationCode` und `activationId` Ihrer neuen SSM-Hybridaktivierung aktualisieren und `nodeadm init` erneut ausführen.
```
"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"
```
```
ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired
```
**SSM konnte zwischengespeicherte Anmeldeinformationen nicht aktualisieren**
Wenn beim Aktualisieren der zwischengespeicherten Anmeldeinformationen ein Fehler auftritt, wurde die `/root/.aws/credentials`-Datei möglicherweise auf Ihrem Host gelöscht. Überprüfen Sie zunächst Ihre SSM-Hybridaktivierung und stellen Sie sicher, dass sie aktiv ist und Ihre Hybridknoten für die Verwendung der Aktivierung korrekt konfiguriert sind. Überprüfen Sie die SSM-Agent-Protokolle unter `/var/log/amazon/ssm` und führen Sie den `nodeadm init`-Befehl erneut aus, sobald Sie das Problem auf der SSM-Seite behoben haben.
```
"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"
```
**SSM bereinigen**
Um den SSM-Agenten von Ihrem Host zu entfernen, können Sie die folgenden Befehle ausführen.
```
dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey
```
** Fehlerbehebung für AWS IAM Roles Anywhere**
Wenn Sie AWS IAM Roles Anywhere für Ihre Anmeldeinformationen für Hybridknoten verwenden, beachten Sie die folgenden Verzeichnisse und Artefakte, die auf Ihren Hybridknoten von installiert werden. `nodeadm` Weitere Informationen zur Problembehandlung bei IAM Roles Anywhere finden Sie unter [Problembehandlung bei Identität und Zugriff auf AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) im * AWS IAM Roles* Anywhere-Benutzerhandbuch.
| Description | Speicherort |
| --- | --- |
| CLI für IAM Roles Anywhere | `/usr/local/bin/aws_signing_helper` |
| Standard-Speicherort und -Name des Zertifikats | `/etc/iam/pki/server.pem` |
| Standard-Speicherort und -Name der Schlüssel | `/etc/iam/pki/server.key` |
**IAM Roles Anywhere konnte die zwischengespeicherten Anmeldeinformationen nicht aktualisieren**
Wenn beim Aktualisieren der zwischengespeicherten Anmeldeinformationen ein Fehler auftritt, überprüfen Sie den Inhalt von `/etc/aws/hybrid/config` und bestätigen Sie, dass IAM Roles Anywhere in Ihrer `nodeadm`-Konfiguration richtig konfiguriert wurde. Bestätigen Sie, dass `/etc/iam/pki` vorhanden ist. Jeder Knoten muss über ein eindeutiges Zertifikat und einen eindeutigen Schlüssel verfügen. Wenn Sie IAM Roles Anywhere als Anmeldeinformationsanbieter verwenden, verwendet `nodeadm` standardmäßig `/etc/iam/pki/server.pem` für den Speicherort und Namen des Zertifikats und `/etc/iam/pki/server.key` für den privaten Schlüssel. Möglicherweise müssen Sie die Verzeichnisse erstellen, bevor Sie die Zertifikate und Schlüssel in den Verzeichnissen mit `sudo mkdir -p /etc/iam/pki` platzieren. Sie können den Inhalt Ihres Zertifikats mit dem folgenden Befehl überprüfen.
```
openssl x509 -text -noout -in server.pem
```
```
open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}
```
**IAM Roles Anywhere ist nicht autorisiert, `sts:AssumeRole` auszuführen **
Wenn Sie in den `kubelet`-Protokollen ein Problem mit einer Zugriffsverweigerung für die `sts:AssumeRole`-Operation bei Verwendung von IAM Roles Anywhere feststellen, überprüfen Sie die Vertrauensrichtlinie Ihrer IAM-Rolle für Hybridknoten, um sicherzustellen, dass der Service-Prinzipal von IAM Roles Anywhere die IAM-Rolle für Hybridknoten übernehmen darf. Bestätigen Sie außerdem, dass der Trust-Anchor-ARN in Ihrer Vertrauensrichtlinie für die IAM-Rolle für Hybridknoten ordnungsgemäß konfiguriert ist und dass Ihre IAM-Rolle für Hybridknoten zu Ihrem IAM–Roles-Anywhere-Profil hinzugefügt wurde.
```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```
**IAM Roles Anywhere ist nicht autorisiert, `roleSessionName` festzulegen **
Wenn Sie in den `kubelet`-Protokollen ein Problem mit einer Zugriffsverweigerung für die Einstellung von `roleSessionName` feststellen, überprüfen Sie, ob Sie `acceptRoleSessionName` für Ihr IAM-Roles-Anywhere-Profil auf „true“ gesetzt haben.
```
AccessDeniedException: Not authorized to set roleSessionName
```
## Fehlerbehebung beim Betriebssystem
### RHEL
**Fehler bei der Registrierung des Berechtigungs- oder Abonnement-Managers**
Wenn Sie `nodeadm install` ausführen und die Installation der Hybridknoten-Abhängigkeiten aufgrund von Problemen bei der Berechtigungsregistrierung fehlschlägt, stellen Sie sicher, dass Sie Ihren Red-Hat-Benutzernamen und Ihr Kennwort auf Ihrem Host richtig eingerichtet haben.
```
This system is not registered with an entitlement server
```
### Ubuntu
**GLIBC nicht gefunden**
Wenn Sie Ubuntu als Betriebssystem und IAM Roles Anywhere als Anmeldeinformationsanbieter mit Hybridknoten verwenden und ein Problem mit „GLIBC nicht gefunden“ feststellen, können Sie diese Abhängigkeit manuell installieren, um das Problem zu beheben.
```
GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)
```
Führen Sie die folgenden Befehle aus, um die Abhängigkeit zu installieren:
```
ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source
```
### Bottlerocket
Wenn Sie den Bottlerocket-Admin-Container aktiviert haben, können Sie mit SSH darauf zugreifen, um erweitertes Debugging und Fehlerbehebung mit erhöhten Berechtigungen durchzuführen Die folgenden Abschnitte enthalten Befehle, die im Kontext des Bottlerocket-Hosts ausgeführt werden müssen. Sobald Sie sich im Admin-Container befinden, können Sie `sheltie` ausführen, um eine vollständige Root-Shell im Bottlerocket-Host zu erhalten.
```
sheltie
```
Sie können die Befehle in den folgenden Abschnitten auch von der Admin-Container-Shell aus ausführen, indem Sie jedem Befehl ein `sudo chroot /.bottlerocket/rootfs` voranstellen.
```
sudo chroot /.bottlerocket/rootfs
```
**Verwendung von logdog zur Protokoll-Erfassung**
Bottlerocket bietet ein Service-Programm `logdog` zur effizienten Erfassung von Protokollen und Systeminformationen für die Fehlerbehebung.
```
logdog
```
Das Service-Programm `logdog` erfasst Protokolle von verschiedenen Speicherorten auf einem Bottlerocket-Host und fasst sie in einem Tarball zusammen. Standardmäßig wird das Tarball-Archiv unter `/var/log/support/bottlerocket-logs.tar.gz` erstellt und ist von Host-Containern unter `/.bottlerocket/support/bottlerocket-logs.tar.gz` zugänglich.
**Zugriff auf Systemprotokolle mit journalctl**
Sie können den Status der verschiedenen System-Services wie `kubelet`, `containerd`, usw. überprüfen und ihre Protokolle mit den folgenden Befehlen anzeigen. Das `-f`-Flag wird die Protokolle in Echtzeit verfolgen.
Um den Status des `kubelet`-Services zu überprüfen und `kubelet`-Protokolle abzurufen, können Sie folgenden Befehl ausführen:
```
systemctl status kubelet
journalctl -u kubelet -f
```
Um den Status des `containerd`-Services zu überprüfen und die Protokolle für die orchestrierte `containerd`-Instance abzurufen, können Sie folgenden Befehl ausführen:
```
systemctl status containerd
journalctl -u containerd -f
```
Um den Status des `host-containerd`-Services zu überprüfen und die Protokolle für die `containerd`-Host-Instance abzurufen, können Sie folgenden Befehl ausführen:
```
systemctl status host-containerd
journalctl -u host-containerd -f
```
Um die Protokolle für die Bootstrap-Container und Host-Container abzurufen, können Sie folgenden Befehl ausführen:
```
journalctl _COMM=host-ctr -f
```