Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

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 und im Tag „Wissenszentrum“ für Amazon EKS 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.

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 Erkenntnisprüfungen über die AWS-Managementkonsole, die AWS-CLI und die AWS-SDKs anzeigen. Weitere Informationen über Cluster-Erkenntnisse finden Sie unter Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken.

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 Komponenten von containerd, kubelet, kubectl und AWS SSM oder AWS IAM Roles Anywhere. 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. 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.

"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

Beim Ausführen von nodeadm init, versucht nodeadm durch Aufrufen von „Cluster beschreiben“ Informationen zu Ihrem EKS-Cluster zu erfassen. Wenn Ihre IAM-Rolle für Hybridknoten über keine Berechtigung für eks:DescribeCluster verfügt. Weitere Informationen zu den erforderlichen Berechtigungen für die IAM-Rolle für Hybridknoten finden Sie unter Vorbereitung der Anmeldeinformationen für Hybridknoten.

"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"

Knoten-IP nicht im CIDR des Fern-Knotennetzwerks

Bei der Ausführung von nodeadm init kann ein Fehler auftreten, wenn die IP-Adresse des Knotens nicht innerhalb der angegebenen CIDRs des Remote-Knotennetzwerks liegt. 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 der IP 10.18.0.1, der versucht, einem Cluster mit den Fern-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.

aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks

Wenn Ihre Knoten-IP immer noch nicht Ihren Erwartungen entspricht, überprüfen Sie Folgendes:

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 <ip address>: i/o timeout

Wenn diese Meldungen angezeigt werden, überprüfen Sie Folgendes, um sicherzustellen, dass die in Vorbereitung der Vernetzung für Hybridknoten aufgeführten Anforderungen für Hybridknoten erfüllt werden.

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 und Vorbereitung des Cluster-Zugriffs für Hybridknoten erfüllt werden.

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 auf dieser Seite.

Zertifikat-Signierungsanforderungen (CSRs) sind in der Warteschlange

Wenn Sie nach dem Verbinden von Hybridknoten mit Ihrem EKS-Cluster feststellen, dass für Ihre Hybridknoten ausstehende CSRs vorhanden sind, erfüllen Ihre Hybridknoten nicht die Anforderungen für die automatische Genehmigung. CSRs für Hybridknoten werden automatisch genehmigt und ausgestellt, wenn die CSRs für Hybridknoten von einem Knoten mit Label eks.amazonaws.com/compute-type: hybrid erstellt wurden und die CSR die folgenden Subject Alternative Names (SANs) enthält: mindestens ein DNS-SAN, das dem Knotennamen entspricht, und die IP-SANs gehören zu den CIDRs des Fern-Knote-Netzwerks.

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 unter Weiterleiten eingehender DNS-Abfragen an Ihre VPC in der AWS-Route53-Dokumentation.

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 in AWS-Managementkonsole anzeigen.

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. Befolgen Sie die folgenden Schritte, um Probleme mit Ihren Knoten zu beheben. Sollte das Problem weiterhin bestehen, 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.

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 auf Hybridknoten ausgeführten Webhooks kontaktieren kann, müssen Sie Ihren EKS-Cluster mit einem Fern-Pod-Netzwerk konfigurieren und Routen für Ihr On-Premises-Pod-CIDR in Ihrer VPC-Routing-Tabelle haben, mit dem Ziel als Ihr Transit Gateway (TGW), Virtual Private Gateway (VPW) oder anderes Gateway, das Sie zum Verbinden Ihres VPC mit Ihrem On-Premises-Netzwerk verwenden. Weitere Informationen zu den Netzwerkanforderungen für Hybridknoten finden Sie unter Vorbereitung der Vernetzung für Hybridknoten. 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.

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 <ip-address>:443: connect: no route to host

kubectl logs oder kubectl exec-Befehle funktionieren nicht

Wenn bei den Befehlen kubectl logs oder kubectl exec eine Zeitüberschreitung auftritt, während andere kubectl-Befehle erfolgreich sind, hängt das Problem wahrscheinlich mit der Fern-Netzwerkkonfiguration zusammen. Diese Befehle stellen über den Cluster eine Verbindung zum kubelet-Endpunkt auf dem Knoten her. Weitere Informationen finden Sie unter kubelet-Endpunkt.

Stellen Sie sicher, dass Ihre Knoten-IPs und Pod-IPs innerhalb der für Ihren Cluster konfigurierten CIDRs des Fern-Knotennetzwerks und des Fern-Pod-Netzwerks liegen. 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 den von Ihnen konfigurierten CIDRs des Fern-Netzwerks, um ein korrektes Routing sicherzustellen. Die Anforderungen für die Netzwerkkonfiguration finden Sie unter Vorbereitung der Vernetzung für Hybridknoten.

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.

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 können die benutzerdefinierten Ressourcendefinitionen (CRDs) für diese CNIs aus einer alten Installation weiterhin in Ihrem Cluster vorhanden sein. Weitere Informationen finden Sie in den Abschnitten „Cilium löschen“ und „Calico löschen“ unter CNI für Hybridknoten konfigurieren.

Fehlerbehebung bei Cilium

Wenn Sie Probleme bei der Ausführung von Cilium in Hybridknoten haben, lesen Sie die Schritte zur Fehlerbehebung 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://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>: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 ausgeführt wird und einige, aber nicht alle Ihrer Cilium-Agenten ausgeführt werden, bestätigen Sie, dass Sie über verfügbare Pod-IPs verfügen, die Sie allen Knoten in Ihrem Cluster zuweisen können. Sie konfigurieren die Größe Ihrer zuweisbaren Pod-CIDRs, wenn Sie Cluster-Pool-IPAM mit clusterPoolIPv4PodCIDRList in Ihrer Cilium-Konfiguration verwenden. 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 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 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 von Services vom Typ LoadBalancer bekannt zu geben, müssen Sie sowohl für Ihren CiliumLoadBalancerIPPool als auch für Ihren Service dasselbe Label verwenden, das im Selektor Ihres CiliumBGPAdvertisement verwendet werden sollte. Es folgt ein Beispiel. Beachten Sie, dass bei Verwendung von Cilium BGP zur Veröffentlichung der IPs von Services vom Typ LoadBalancer die BGP-Routen während des Neustarts des Cilium-Agenten unterbrochen werden können. Weitere Informationen finden Sie unter Fehlerszenarien 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: <CIDR to advertise>
  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 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.

Calico-Ressourcen sind geplant oder werden in abgesperrten Knoten ausgeführt

Die Calico-Ressourcen, die nicht als DaemonSet ausgeführt werden, verfügen standardmäßig über flexible Toleranzen, die es ermöglichen, sie auf abgesperrten Knoten zu planen, die nicht für die Planung oder Ausführung von Pods bereit sind. Sie können die Toleranzen für die Calico-Ressourcen, die nicht zu DaemonSet gehören, verschärfen, indem Sie Ihre Operator-Installation so ändern, dass Folgendes enthalten ist.

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

Sie können sowohl für AWS-SSM-Hybridaktivierungen als auch für AWS IAM Roles Anywhere überprüfen, ob die Anmeldeinformationen für die IAM-Rolle für Hybridknoten 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:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws:sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}

Fehlerbehebung für AWS Systems Manager (SSM)

Wenn Sie AWS-SSM-Hybridaktivierungen für die Anmeldeinformationen Ihrer Hybridknoten verwenden, beachten Sie die folgenden SSM-Verzeichnisse und Artefakte, die von nodeadm auf Ihren Hybridknoten installiert werden. Weitere Informationen zum SSM-Agenten finden Sie unter Arbeiten mit dem SSM-Agenten im AWS-Systems-Manager-Benutzerhandbuch.

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. Ersetzen Sie us-west-2 im folgenden Befehl durch die AWS-Region für Ihre AWS-SSM-Hybridaktivierung.

ping ssm.us-west-2.amazonaws.com

Verbindungsstatus registrierter SSM-Instances anzeigen

Sie können den Verbindungsstatus der Instances, die bei SSM-Hybridaktivierungen 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 beim Registrieren Ihrer Instance bei AWS SSM ein Fehler auftritt, bestätigen Sie, dass region, activationCode und activationId in Ihrem nodeConfig.yaml korrekt sind. Die AWS-Region für Ihren EKS-Cluster muss mit der Region Ihrer SSM-Hybridaktivierung ü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 die Anmeldeinformationen Ihrer Hybridknoten verwenden, achten Sie auf die folgenden Verzeichnisse und Artefakte, die von nodeadm auf Ihren Hybridknoten installiert werden. Weitere Informationen zur Fehlerbehebung bei IAM Roles Anywhere finden Sie unter Fehlerbehebung für Identität und Zugriff bei AWS IAM Roles Anywhere im Benutzerhandbuch zu AWS IAM Roles Anywhere.

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 <command>

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