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 und dem Knowledge Center-Tag 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 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.

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örencontainerd, kubeletkubectl, 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. 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

nodeadmVersucht bei der Ausführungnodeadm 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 übergebennodeadm. 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.

"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

nodeadmVersucht bei der Ausführung zu überprüfennodeadm 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.

"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 auftretennodeadm 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.

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.

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.

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.

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.

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 logsoder kubectl exec Befehle, die nicht funktionieren (kubeletAPI-Befehle)

Wenn bei Befehlen kubectl attach kubectl cpkubectl 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.

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.

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

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 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 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 Dienste mit Typ zu bewerbenLoadBalancer, 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 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 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:<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-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 im AWS Systems Manager 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 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 regionactivationCode, 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 im AWS IAM Roles Anywhere-Benutzerhandbuch.

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