Beheben von Problemen mit Amazon-EKS-Clustern und -Knoten

In diesem Kapitel werden einige häufige Fehler bei der Verwendung von Amazon EKS sowie deren Lösung behandelt. Wenn Sie Probleme in bestimmten Amazon-EKS-Bereichen beheben müssen, lesen Sie die separaten Themen Fehlersuche bei IAM, Fehlerbehebung bei Problemen mit dem Amazon EKS Connector und Fehlerbehebung für ADOT mithilfe von EKS-Add-ons.

Weitere Informationen zur Fehlerbehebung finden Sie in den Knowledge Center-Inhalten zu Amazon Elastic Kubernetes Service auf AWS re:POST.

Unzureichende Kapazität

Wenn beim Versuch, einen Amazon-EKS-Cluster zu erstellen, der folgende Fehler auftritt, verfügt eine der angegebenen Availability Zones nicht über ausreichende Kapazität, um einen Cluster zu unterstützen.

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

Versuchen Sie erneut, den Cluster mit Subnetzen in Ihrer Cluster-VPC zu erstellen, die in den Availability Zones gehostet werden, die diesen Fehler verursacht haben.

Es gibt Availability Zones, in denen sich kein Cluster befinden darf. Vergleichen Sie die Availability Zones, in denen sich Ihre Subnetze befinden, mit der Liste der Availability Zones in den Anforderungen und Überlegungen zu Subnetzen.

Knoten können nicht mit dem Cluster verknüpft werden

Es gibt zwei häufige Gründe, aus denen Knoten nicht mit dem Cluster verknüpft werden können:

Zur Ermittlung und Behebung häufiger Ursachen, die den Beitritt von Worker-Knoten zu einem Cluster verhindern, können Sie das Runbook AWSSupport-TroubleshootEKSWorkerNode verwenden. Weitere Informationen finden Sie AWSSupport-TroubleshootEKSWorkerNode in der Runbook-Referenz für AWS Systems Manager Automation.

Nicht autorisiert oder Zugriff verweigert (kubectl)

Wenn Sie beim Ausführen von kubectl-Befehlen einen der folgenden Fehler erhalten, ist kubectl für Amazon EKS nicht richtig konfiguriert oder die Anmeldeinformationen für den von Ihnen verwendeten IAM-Prinzipal (Rolle oder Benutzer) lassen sich keinem Kubernetes-Benutzernamen zuordnen, der über ausreichende Berechtigungen für Kubernetes-Objekte in Ihrem Amazon-EKS-Cluster verfügt.

Das kann auf eine der folgenden Ursachen zurückzuführen sein:

Wenn Sie die AWS CLI installieren und konfigurieren, können Sie die von Ihnen verwendeten IAM-Anmeldeinformationen konfigurieren. Weitere Informationen finden Sie unter Configuring the AWS CLI im AWS Command Line Interface User Guide. Sie können auch kubectl für die Verwendung einer IAM-Rolle konfigurieren, wenn Sie für den Zugriff auf Kubernetes-Objekte in Ihrem Cluster eine IAM-Rolle annehmen. Weitere Informationen finden Sie unter kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden.

hostname doesn’t match

Die Python-Version Ihres Systems muss 2.7.9 oder höher sein. Andernfalls erhalten Sie hostname doesn’t match Fehler bei AWS CLI-Aufrufen an Amazon EKS. Weitere Informationen finden Sie unter Was sind Fehlermeldungen vom Typ „Host-Name stimmt nicht überein“? in den Häufig gestellten Fragen zu Python-Anfragen.

getsockopt: no route to host

Docker wird im 172.17.0.0/16-CIDR-Bereich in Amazon-EKS-Clustern ausgeführt. Wir empfehlen, dass die VPC-Subnetze Ihres Clusters diesen Bereich nicht überschneiden. Andernfalls erhalten Sie den folgenden Fehler:

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host

Instances failed to join the Kubernetes cluster

Wenn Sie den Fehler Instances failed to join the Kubernetes cluster in der erhalten, stellen Sie sicher AWS-Managementkonsole, dass entweder der private Endpunktzugriff des Clusters aktiviert ist oder dass Sie die CIDR-Blöcke für den Zugriff auf öffentliche Endpunkte korrekt konfiguriert haben. Weitere Informationen finden Sie unter Cluster-API-Server-Endpunkt.

Fehlercodes bei verwalteten Knotengruppen

Wenn bei Ihrer verwaltete Knotengruppe ein Hardwarezustandsproblem auftritt, gibt Amazon EKS einen Fehlercode zurück, der Ihnen bei der Diagnose des Problems hilft. Diese Zustandsprüfungen erkennen keine Softwareprobleme, da sie auf Amazon-EC2-Zustandsprüfungen basieren. Die Fehlercodes sind in der folgenden Liste beschrieben.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl describe clusterrole eks:node-manager

kubectl describe clusterrolebinding eks:node-manager

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl apply -f eks-node-manager-role.yaml

Not authorized for images

Eine mögliche Ursache für eine Not authorized for images-Fehlermeldung ist die Verwendung eines privaten Amazon-EKS-Windows-AMI zum Starten von Windows-verwalteten Knotengruppen. Nach der Veröffentlichung neuer Windows-Versionen werden AWS Dateien AMIs, AMIs die älter als 4 Monate sind, privat, sodass nicht mehr darauf zugegriffen werden kann. Wenn Ihre verwaltete Knotengruppe ein privates Windows-AMI verwendet, sollten Sie eine Aktualisierung Ihrer verwalteten Windows-Knotengruppe in Betracht ziehen. Wir können zwar nicht garantieren, dass wir Zugriff auf privat gemachte AMIs Inhalte gewähren können, aber du kannst den Zugriff beantragen, indem du ein Ticket beim AWS Support einreichst. Weitere Informationen finden Sie unter Patches im Amazon-EC2-Benutzerhandbuch.

Knoten befindet sich im NotReady-Zustand

Wenn Ihr Knoten in einen NotReady-Status wechselt, deutet dies wahrscheinlich darauf hin, dass der Knoten nicht ordnungsgemäß funktioniert und für die Planung neuer Pods nicht verfügbar ist. Dies kann verschiedene Ursachen haben, beispielsweise wenn dem Knoten ausreichende Ressourcen für CPU, Arbeitsspeicher oder verfügbaren Festplattenspeicher fehlen.

Für Amazon EKS-optimiertes Windows gibt es keine Reservierung für Rechenressourcen AMIs, die standardmäßig in der kubelet Konfiguration angegeben sind. Um Ressourcenprobleme zu vermeiden, können Sie Rechenressourcen für Systemprozesse reservieren, indem Sie die kubelet Konfigurationswerte für kube-reserved system-reserved and/or angeben. Dies tun Sie mithilfe des -KubeletExtraArgs-Befehlszeilen-Parameters im Bootstrap-Skript. Weitere Informationen finden Sie unter Reservieren von Rechenressourcen für System Daemons in der Kubernetes-Dokumentation und Bootstrap-Skript-Konfigurationsparameter in diesem Benutzerhandbuch.

EKS-Protokollsammler

Zur Fehlerbehebung bei Problemen mit Amazon-EKS-Knoten steht auf den Knoten unter /etc/eks/log-collector-script/eks-log-collector.sh ein vorgefertigtes Skript zur Verfügung. Sie können das Skript verwenden, um Diagnoseprotokolle für Support-Fälle und allgemeine Fehlerbehebung zu sammeln.

Mit dem folgenden Befehl können Sie das Skript auf dem Knoten ausführen:

sudo bash /etc/eks/log-collector-script/eks-log-collector.sh

curl -O https://amazon-eks.s3.amazonaws.com/support/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

Das Skript sammelt die folgenden Diagnoseinformationen:

$ sudo bash /etc/eks/log-collector-script/eks-log-collector.sh

      This is version 0.7.8. New versions can be found at https://github.com/awslabs/amazon-eks-ami/blob/main/log-collector-script/

Trying to collect common operating system logs...
Trying to collect kernel logs...
Trying to collect mount points and volume information...
...
...

	Done... your bundled logs are located in /var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz

Die Diagnoseinformationen werden gesammelt und gespeichert unter:

/var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz

Weitere Informationen zum Abrufen des Protokollpakets für Bottlerocket-Knoten finden Sie im Bottlerocket-Protokoll.

Container-Laufzeitnetzwerk nicht bereit

Möglicherweise erhalten Sie einen Container runtime network not ready-Fehler und einen Autorisierungsfehler, die den folgenden ähneln:

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized
4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

Dieses Problem kann folgende Ursachen haben:

TLS-Handshake-Zeitüberschreitung

Wenn ein Knoten nicht in der Lage ist, eine Verbindung zum öffentlichen API-Server-Endpunkt herzustellen, erhalten Sie möglicherweise einen Fehler ähnlich dem folgenden.

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post  net/http: TLS handshake timeout\""

Der kubelet-Prozess wird weiter fortgesetzt und testet den API-Server-Endpunkt. Der Fehler kann auch vorübergehend während jeder Prozedur auftreten, die eine laufende Aktualisierung des Clusters auf der Steuerungsebene durchführt, z. B. eine Konfigurationsänderung oder eine Versionsaktualisierung.

Um das Problem zu beheben, überprüfen Sie die Routing-Tabelle und die Sicherheitsgruppen, um sicherzustellen, dass der Datenverkehr von den Knoten den öffentlichen Endpunkt erreichen kann.

InvalidClientTokenId

Wenn Sie IAM-Rollen für Dienstkonten für einen Pod verwenden oder in einem Cluster in einer AWS Region China DaemonSet bereitgestellt sind und die AWS_DEFAULT_REGION Umgebungsvariable nicht in der Spezifikation festgelegt haben, wird für den Pod oder die DaemonSet folgende Fehlermeldung angezeigt:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

Um das Problem zu beheben, müssen Sie die AWS_DEFAULT_REGION Umgebungsvariable zu Ihrem Pod oder Ihrer DaemonSet Spezifikation hinzufügen, wie in der folgenden Beispiel-Pod-Spezifikation gezeigt.

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: AWS_DEFAULT_REGION
      value: "region-code"

Knotengruppen müssen vor dem Upgrade der Steuerebene mit der Kubernetes-Version übereinstimmen

Bevor Sie eine Steuerebene auf eine neue Kubernetes-Version aktualisieren, muss die Nebenversion der verwalteten und Fargate-Knoten in Ihrem Cluster mit der Version der aktuellen Version Ihrer Steuerebene übereinstimmen. Die Amazon EKS-update-cluster-version-API akzeptiert keine Anforderungen, bis für alle von Amazon EKS verwalteten Knoten ein Upgrade auf die aktuelle Cluster-Version durchgeführt wurde. Amazon EKS bietet APIs die Möglichkeit, verwaltete Knoten zu aktualisieren. Informationen zum Upgrade der Kubernetes-Version einer verwalteten Knotengruppe finden Sie unter Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren. Löschen Sie zum Upgraden der Version eines Fargate-Knotens den Pod, der durch den Knoten dargestellt wird, und stellen Sie den Pod erneut bereit, nachdem Sie das Upgrade für Ihre Steuerebene durchgeführt haben. Weitere Informationen finden Sie unter Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version.

Beim Starten vieler Knoten gibt es Too Many Requests-Fehler

Wenn Sie viele Knoten gleichzeitig starten, wird möglicherweise die Fehlermeldung Too Many Requests in den Ausführungsprotokollen für die Amazon-EC2-Benutzerdaten angezeigt. Dies kann auftreten, weil die Steuerebene mit describeCluster-Aufrufen überlastet wird. Die Überladung führt zu einer Drosselung, Knoten, die das Bootstrap-Skript nicht ausführen können, und Knoten, die dem Cluster insgesamt nicht beitreten können.

Stellen Sie sicher, dass die Argumente --apiserver-endpoint, --b64-cluster-ca und --dns-cluster-ip an das Bootstrap-Skript des Knotens übergeben werden. Wenn Sie diese Argumente einschließen, muss das Bootstrap-Skript keinen describeCluster-Aufruf ausführen, wodurch verhindert wird, dass die Steuerebene überlastet wird. Weitere Informationen finden Sie unter Geben Sie Benutzerdaten an, um Argumente an die bootstrap.sh Datei zu übergeben, die in einem Amazon EKS-optimierten Linux/Bottlerocket AMI enthalten ist.

Unautorisierte Fehlerantwort (HTTP 401) bei Kubernetes-API-Serveranfragen

Diese Fehler werden angezeigt, wenn das Servicekonto-Token eines Pods in einem Cluster abgelaufen ist.

Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters lehnt Anfragen mit Tokens ab, die älter als 90 Tage sind. In früheren Kubernetes-Versionen hatten Token kein Ablaufdatum. Clients, die diese Tokens verwenden, müssen die Tokens nun innerhalb einer Stunde aktualisieren. Um zu verhindern, dass der Kubernetes-API-Server Ihre Anfrage aufgrund eines ungültigen Tokens ablehnt, muss die von Ihrem Workload verwendete Kubernetes-Client-SDK-Version dieselbe oder höher als die folgenden Versionen sein:

Sie können alle vorhandenen Pods in Ihrem Cluster ermitteln, die veraltete Token verwenden. Weitere Informationen finden Sie unter Servicekonto-Tokens.

Die Amazon-EKS-Plattformversion liegt mehr als zwei Versionen hinter der aktuellen Plattformversion

Dies kann passieren, wenn Amazon EKS die Plattformversion Ihres Clusters nicht automatisch aktualisieren kann. Obwohl es dafür viele Ursachen gibt, folgen einige der häufigsten Ursachen. Wenn Ihr Cluster von einem dieser Probleme betroffen ist, funktioniert er möglicherweise immer noch, aber seine Plattformversion wird nicht von Amazon EKS aktualisiert.

Problem

Die Cluster-IAM-Rolle wurde gelöscht – Diese Rolle wurde beim Erstellen des Clusters angegeben. Sie können mit dem folgenden Befehl überprüfen, welche Rolle angegeben wurde. Ersetzen Sie my-cluster mit dem Namen Ihres Clusters.

aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2

Eine Beispielausgabe sieht wie folgt aus.

eksClusterRole

Lösung

Erstellen einer neuen Cluster-IAM-Rolle mit demselben Namen.

Problem

Ein bei der Clustererstellung festgelegtes Subnetz wurde gelöscht – Die mit dem Cluster zu verwendenden Subnetze wurden bei der Clustererstellung angegeben. Sie können mit dem folgenden Befehl überprüfen, welche Subnetze angegeben wurden. Ersetzen Sie my-cluster mit dem Namen Ihres Clusters.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.subnetIds

Eine Beispielausgabe sieht wie folgt aus.

[
"subnet-EXAMPLE1",
"subnet-EXAMPLE2"
]

Lösung

Bestätigen Sie, ob das Subnetz in Ihrem Konto IDs vorhanden ist.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"

Eine Beispielausgabe sieht wie folgt aus.

[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]

Wenn das in der Ausgabe IDs zurückgegebene Subnetz nicht mit dem Subnetz übereinstimmt IDs , das bei der Erstellung des Clusters angegeben wurde, müssen Sie, wenn Amazon EKS den Cluster aktualisieren soll, die vom Cluster verwendeten Subnetze ändern. Dies liegt daran, dass Amazon EKS, wenn Sie bei der Erstellung Ihres Clusters mehr als zwei Subnetze angegeben haben, nach dem Zufallsprinzip Subnetze auswählt, die Sie für die Erstellung neuer Elastic-Network-Schnittstellen angegeben haben. Diese Netzwerkschnittstellen ermöglichen es der Steuerebene, mit Ihren Knoten zu kommunizieren. Amazon EKS aktualisiert den Cluster nicht, wenn das von ihm ausgewählte Subnetz nicht vorhanden ist. Sie haben keine Kontrolle darüber, in welchem der Subnetze, die Sie bei der Clustererstellung angegeben haben, Amazon EKS wählt, um eine neue Netzwerkschnittstelle zu erstellen.

Wenn Sie eine Kubernetes-Versionsaktualisierung für Ihren Cluster initiieren, kann die Aktualisierung aus dem gleichen Grund fehlschlagen.

Problem

Eine bei der Clustererstellung angegebene Sicherheitsgruppe wurde gelöscht — Wenn Sie bei der Clustererstellung Sicherheitsgruppen angegeben haben, können Sie diese IDs mit dem folgenden Befehl einsehen. Ersetzen Sie my-cluster mit dem Namen Ihres Clusters.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds

Eine Beispielausgabe sieht wie folgt aus.

[
    "sg-EXAMPLE1"
]

Wenn [] zurückgegeben wird, wurden beim Erstellen des Clusters keine Sicherheitsgruppen angegeben und eine fehlende Sicherheitsgruppe ist nicht das Problem. Wenn Sicherheitsgruppen zurückgegeben werden, vergewissern Sie sich, dass die Sicherheitsgruppen in Ihrem Konto vorhanden sind.

Lösung

Bestätigen Sie, ob diese Sicherheitsgruppen in Ihrem Konto vorhanden sind.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"

Eine Beispielausgabe sieht wie folgt aus.

[
"sg-EXAMPLE2"
]

Wenn die in der Ausgabe IDs zurückgegebene Sicherheitsgruppe nicht mit der Sicherheitsgruppe übereinstimmt IDs , die bei der Erstellung des Clusters angegeben wurde, müssen Sie, wenn Amazon EKS den Cluster aktualisieren soll, die vom Cluster verwendeten Sicherheitsgruppen ändern. Amazon EKS aktualisiert einen Cluster nicht, wenn die bei der Clustererstellung IDs angegebene Sicherheitsgruppe nicht existiert.

Wenn Sie eine Kubernetes-Versionsaktualisierung für Ihren Cluster initiieren, kann die Aktualisierung aus dem gleichen Grund fehlschlagen.

FAQs Cluster-Integritäts- und Fehlercodes mit Lösungspfaden

Amazon EKS erkennt Probleme mit Ihren EKS-Clustern und der Cluster-Infrastruktur und speichert diese im Objekt Integrität Ihrer EKS-Cluster-Ressource. Mithilfe von Cluster-Integritätsinformationen können Sie Cluster-Probleme schneller erkennen, behandeln und beheben. Auf diese Weise können Sie Anwendungsumgebungen erstellen, die sicherer und sicherer sind up-to-date. Darüber hinaus kann es vorkommen, dass Sie aufgrund von Problemen mit der erforderlichen Infrastruktur oder Cluster-Konfiguration kein Upgrade auf neuere Versionen von Kubernetes durchführen können oder dass Amazon EKS keine Sicherheitsaktualisierungen auf einem beeinträchtigten Cluster installieren kann. Es kann drei Stunden dauern, bis Amazon EKS Probleme erkennt oder feststellt, dass ein Problem behoben wurde.

Amazon EKS und die Benutzer sind gemeinsam für die Integrität eines Amazon EKS-Clusters verantwortlich. Sie selbst sind für die erforderliche Infrastruktur von IAM-Rollen und Amazon VPC-Subnetzen sowie für andere notwendige Infrastrukturkomponenten verantwortlich, die im Voraus bereitgestellt werden müssen. Amazon EKS erkennt Änderungen an der Konfiguration dieser Infrastruktur und des Clusters.

Um den Status Ihres Clusters in der Amazon-EKS-Konsole anzuzeigen, suchen Sie in der Registerkarte Cluster-Integritätsprobleme des Beobachtbarkeits-Dashboards, das Sie über die Amazon-EKS-Cluster-Detailseite aufrufen können, nach einer Tabelle mit dem Namen Integritätsprobleme. Diese Daten sind auch verfügbar, wenn die DescribeCluster Aktion in der EKS-API aufgerufen wird, beispielsweise von der AWS Befehlszeilenschnittstelle aus.

Die ersten beiden Spalten werden für API-Antwortwerte benötigt. Das dritte Feld des ClusterIssueHealth-Objekts ist ResourceIds, dessen Rückgabe vom Problemtyp abhängt.