Probleme mit EKS Amazon-Clustern und -Knoten beheben

In diesem Kapitel werden einige häufig auftretende Fehler behandelt, die bei der Nutzung von Amazon auftreten können, EKS und wie Sie diese umgehen können. Wenn Sie Probleme in bestimmten EKS Amazon-Bereichen beheben müssen, lesen Sie die separaten Themen Problembehebung IAMProbleme mit Amazon EKS Connector beheben, und Fehlerbehebung für die ADOT Verwendung von EKS Add-Ons.

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

Unzureichende Kapazität

Wenn Sie beim Versuch, einen EKS Amazon-Cluster zu erstellen, die folgende Fehlermeldung erhalten, verfügt eine der von Ihnen angegebenen Availability Zones nicht über ausreichend 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, Ihren Cluster mit Subnetzen in Ihrem Cluster zu erstellenVPC, die in den Availability Zones gehostet werden, die in dieser Fehlermeldung angezeigt wurden.

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 unter Subnetz-Anforderungen und -Überlegungen.

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 unter AWSSupport-TroubleshootEKSWorkerNode in der Referenz zum Automation-Runbook für AWS Systems Manager .

Nicht autorisiert oder Zugriff verweigert (kubectl)

Wenn Sie beim Ausführen von kubectl Befehlen einen der folgenden Fehler erhalten, haben Sie nicht richtig für Amazon kubectl konfiguriert EKS oder die Anmeldeinformationen für den IAM Principal (Rolle oder Benutzer), den Sie verwenden, sind nicht zugeordnet Kubernetes Nutzername, der über ausreichende Berechtigungen verfügt für Kubernetes Objekte in Ihrem EKS Amazon-Cluster.

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

Wenn Sie das installieren und konfigurieren AWS CLI, können Sie die von Ihnen verwendeten IAM Anmeldeinformationen konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der AWS CLI im AWS Command Line Interface -Leitfaden. Sie können auch kubectl die Verwendung einer IAM Rolle konfigurieren, wenn Sie eine IAM Rolle für den Zugriff annehmen Kubernetes Objekte auf Ihrem Cluster. Weitere Informationen finden Sie unter Verbinden kubectl zu einem EKS Cluster durch Erstellen eines kubeconfig file.

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 Anrufen bei AmazonEKS. Weitere Informationen finden Sie auf der Seite mit häufig gestellten Fragen der Python Requests-Website unter What are “hostname doesn’t match” errors?.

getsockopt: no route to host

Docker läuft im 172.17.0.0/16 CIDR Bereich in EKS Amazon-Clustern. Wir empfehlen, dass sich die VPC Subnetze Ihres Clusters nicht mit diesem Bereich ü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 Management Console, dass entweder der private Endpunktzugriff des Clusters aktiviert ist oder dass Sie CIDR Blöcke für den Zugriff auf öffentliche Endpunkte korrekt konfiguriert haben. Weitere Informationen finden Sie unter Steuern Sie den Netzwerkzugriff auf den API Clusterserver-Endpunkt.

Fehlercodes bei verwalteten Knotengruppen

Wenn in Ihrer verwalteten Knotengruppe ein Problem mit dem Hardwarestatus auftritt, EKS gibt Amazon einen Fehlercode zurück, der Ihnen bei der Diagnose des Problems hilft. Diese Gesundheitschecks erkennen keine Softwareprobleme, da sie auf EC2Amazon-Gesundheitschecks 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 AMIum zu starten Windows verwaltete Knotengruppen. Nach der Veröffentlichung neuer Windows AMIs, AWS macht AMIs die, die älter als 4 Monate sind, privat, wodurch sie nicht mehr zugänglich sind. Wenn Ihre verwaltete Knotengruppe eine private Windows AMI, erwägen Sie, Ihre zu aktualisieren Windows verwaltete Knotengruppe. 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, Sicherheitsupdates und AMI IDs im EC2Amazon-Benutzerhandbuch.

Der Knoten befindet sich im NotReady Status

Wenn Ihr Knoten in einen NotReady Status wechselt, deutet dies wahrscheinlich darauf hin, dass der Knoten fehlerhaft ist und nicht für einen neuen Knoten geplant werden kann Pods. Dies kann verschiedene Ursachen haben, z. B. weil dem Knoten nicht genügend RessourcenCPU, Arbeitsspeicher oder verfügbarer Festplattenspeicher fehlen.

Für Amazon EKS optimiert Windows AMIs, es gibt keine Reservierung für Rechenressourcen, die standardmäßig in der kubelet Konfiguration angegeben sind. Um Ressourcenproblemen vorzubeugen, können Sie Rechenressourcen für Systemprozesse reservieren, indem Sie die kubelet Konfigurationswerte für kube-reservedund/oder angeben system-reserved. Dazu verwenden Sie den -KubeletExtraArgs Befehlszeilenparameter im Bootstrap-Skript. Weitere Informationen finden Sie unter Reservieren von Rechenressourcen für System-Daemons im Kubernetes Dokumentation und Bootstrap-Skriptkonfigurationsparameter in diesem Benutzerhandbuch.

CNITool zum Sammeln von Protokollen

Das Tool Amazon VPC CNI plugin for Kubernetes hat ein eigenes Fehlerbehebungsskript, das auf Knoten unter verfügbar ist/opt/cni/bin/aws-cni-support.sh. 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 /opt/cni/bin/aws-cni-support.sh

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

Das Skript sammelt die folgenden Diagnoseinformationen: Die CNI Version, die Sie bereitgestellt haben, kann älter als die Skriptversion sein.

      This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami

Trying to collect common operating system logs... 
Trying to collect kernel logs... 
Trying to collect mount points and volume information... 
Trying to collect SELinux status... 
Trying to collect iptables information... 
Trying to collect installed packages... 
Trying to collect active system services... 
Trying to collect Docker daemon information... 
Trying to collect kubelet information... 
Trying to collect L-IPAMD information... 
Trying to collect sysctls information... 
Trying to collect networking information... 
Trying to collect CNI configuration information... 
Trying to collect running Docker containers and gather container data... 
Trying to collect Docker daemon logs... 
Trying to archive gathered information... 

	Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Die Diagnoseinformationen werden gesammelt und gespeichert unter:

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

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:

TLSHandshake-Timeout

Wenn ein Knoten keine Verbindung zum Endpunkt des öffentlichen API Servers herstellen kann, wird möglicherweise ein Fehler angezeigt, der dem folgenden Fehler ähnelt.

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 kontinuierlich neu gestartet und der API Serverendpunkt getestet. 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 verwenden Pod oder in einem Cluster in China DaemonSet AWS-Region bereitgestellt und die AWS_DEFAULT_REGION Umgebungsvariable nicht in der Spezifikation festgelegt wurde, Pod oder DaemonSet es wird möglicherweise der folgende Fehler 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 hinzufügen Pod oder DaemonSet Spezifikation, wie im folgenden Beispiel gezeigt Pod spezifikation.

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 übereinstimmen Kubernetes Version vor dem Upgrade der Steuerungsebene

Bevor Sie eine Steuerungsebene auf eine neue aktualisieren Kubernetes Version, die Nebenversion der verwalteten Knoten und der Fargate-Knoten in Ihrem Cluster muss mit der Version der aktuellen Version Ihrer Kontrollebene identisch sein. Amazon EKS update-cluster-version API lehnt Anfragen ab, bis Sie alle von Amazon EKS verwalteten Knoten auf die aktuelle Cluster-Version aktualisiert haben. Amazon EKS bietet APIs die Möglichkeit, verwaltete Knoten zu aktualisieren. Für Informationen zum Upgrade einer verwalteten Knotengruppe Kubernetes Version finden Sie unterAktualisieren Sie eine verwaltete Knotengruppe für Ihren Cluster. Um die Version eines Fargate-Knotens zu aktualisieren, löschen Sie den pod das wird durch den Knoten repräsentiert, und stellen Sie das erneut bereit pod nachdem Sie Ihre Steuerungsebene aktualisiert haben. Weitere Informationen finden Sie unter Aktualisieren Sie den vorhandenen Cluster auf die neue Kubernetes-Version.

Beim Starten vieler Knoten gibt es Too Many Requests-Fehler

Wenn Sie viele Knoten gleichzeitig starten, wird in den Ausführungsprotokollen der EC2Amazon-Benutzerdaten möglicherweise eine Fehlermeldung angezeigt, die besagtToo Many Requests. 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 EKS Amazon-optimiertenLinux/enthalten ist Bottlerocket AMI.

HTTP401 unautorisierte Fehlerantwort auf Kubernetes APIServeranfragen

Sie sehen diese Fehler, wenn PodDas Dienstkonto-Token ist auf einem Cluster abgelaufen.

Die Ihres EKS Amazon-Clusters Kubernetes APIDer Server lehnt Anfragen ab, deren Token älter als 90 Tage sind. In der Vergangenheit Kubernetes In den Versionen hatten Tokens kein Ablaufdatum. Clients, die diese Tokens verwenden, müssen die Tokens nun innerhalb einer Stunde aktualisieren. Um das zu verhindern Kubernetes APIdass der Server Ihre Anfrage aufgrund eines ungültigen Tokens ablehnt, Kubernetes Die von Ihrem Workload verwendete SDK Client-Version muss dieselbe oder eine neuere Version als die folgenden Versionen sein:

Sie können alle vorhandenen identifizieren Pods in Ihrem Cluster, die veraltete Token verwenden. Weitere Informationen finden Sie unter Kubernetes Dienstkonten.

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

Dies kann passieren, wenn Amazon die Plattformversion Ihres Clusters EKS nicht automatisch aktualisieren kann. Obwohl es dafür viele Ursachen gibt, folgen einige der häufigsten Ursachen. Wenn eines dieser Probleme auf Ihren Cluster zutrifft, funktioniert er möglicherweise immer noch, seine Plattformversion wird nur nicht von Amazon aktualisiertEKS.

Problem

Die IAMClusterrolle wurde gelöscht — Diese Rolle wurde bei der Erstellung des Clusters angegeben. Sie können mit dem folgenden Befehl überprüfen, welche Rolle angegeben wurde. Ersetzen 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 Sie eine neue IAMClusterrolle 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 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 existiert.

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 übereinstimmtIDs, das bei der Erstellung des Clusters angegeben wurde, müssen Sie die vom Cluster verwendeten Subnetze ändern, wenn Sie möchten, dass Amazon EKS den Cluster aktualisiert. Das liegt daran, dass Amazon, wenn Sie bei der Erstellung Ihres Clusters mehr als zwei Subnetze angegeben haben, EKS nach dem Zufallsprinzip Subnetze auswählt, in denen Sie neue elastische Netzwerkschnittstellen erstellt haben. Diese Netzwerkschnittstellen ermöglichen es der Steuerebene, mit Ihren Knoten zu kommunizieren. Amazon aktualisiert den Cluster EKS nicht, wenn das ausgewählte Subnetz nicht existiert. Sie haben keine Kontrolle darüber, in welchem der Subnetze, die Sie bei der Cluster-Erstellung angegeben EKS haben, Amazon eine neue Netzwerkschnittstelle erstellt.

Wenn Sie eine initiieren Kubernetes Versionsupdate für Ihren Cluster, das Update kann aus demselben 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 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 übereinstimmtIDs, die bei der Erstellung des Clusters angegeben wurde, müssen Sie die vom Cluster verwendeten Sicherheitsgruppen ändern, wenn Sie möchten, dass Amazon EKS den Cluster aktualisiert. Amazon aktualisiert einen Cluster EKS nicht, wenn die bei der Clustererstellung IDs angegebene Sicherheitsgruppe nicht existiert.

Wenn Sie eine initiieren Kubernetes Versionsupdate für Ihren Cluster, das Update kann aus demselben Grund fehlschlagen.

FAQsCluster-Integritäts- und Fehlercodes mit Lösungspfaden

Amazon EKS erkennt Probleme mit Ihren EKS Clustern und der Cluster-Infrastruktur und speichert sie im Cluster-Status. 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 ist es für Sie möglicherweise unmöglich, auf neuere Versionen von zu aktualisieren Kubernetes oder für AmazonEKS, um Sicherheitsupdates auf einem heruntergestuften Cluster zu installieren, der aufgrund von Problemen mit der erforderlichen Infrastruktur oder Clusterkonfiguration beeinträchtigt wurde. Es EKS kann 3 Stunden dauern, bis Amazon Probleme erkennt oder feststellt, dass ein Problem gelöst wurde.

Die Integrität eines EKS Amazon-Clusters liegt in der gemeinsamen Verantwortung von Amazon EKS und seinen Benutzern. Sie sind verantwortlich für die erforderliche Infrastruktur von IAM Rollen und VPC Amazon-Subnetzen sowie für andere notwendige Infrastrukturen, die im Voraus bereitgestellt werden müssen. Amazon EKS erkennt Änderungen an der Konfiguration dieser Infrastruktur und des Clusters.

Um in der EKS Amazon-Konsole auf den Status Ihres Clusters zuzugreifen, suchen Sie auf der Registerkarte Übersicht der EKS Amazon-Cluster-Detailseite nach einem Abschnitt mit dem Namen Health Issues. Diese Daten sind auch verfügbar, wenn Sie die DescribeCluster Aktion im aufrufen EKSAPI, z. B. von der aus AWS Command Line Interface.

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