Amazon-EKS-Fehlerbehebung

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, Beheben von Problemen in Amazon EKS Connector und Beheben von Problemen im Add-on ADOT Amazon EKS.

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.

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:

• Die Datei aws-auth-cm.yaml enthält nicht den korrekten ARN der IAM-Rolle für Ihre Knoten. Stellen Sie sicher, dass der ARN der Knoten-IAM-Rolle (nicht der ARN des Instances-Profils) in Ihrer Datei aws-auth-cm.yaml enthalten ist. Weitere Informationen finden Sie unter Starten selbstverwalteter Amazon Linux-Knoten.

• Der ClusterName in der AWS CloudFormation-Vorlage Ihres Knotens stimmt nicht genau mit dem Namen des Clusters überein, den Sie mit Ihren Knoten verknüpfen möchten. Wenn Sie einen falschen Wert an dieses Feld übergeben, führt dies zu Fehlern in der Konfiguration der /var/lib/kubelet/kubeconfig-Datei des Knotens und dieser kann nicht mit dem Cluster verknüpft werden.

• Der Knoten ist nicht als Eigentum des Clusters gekennzeichnet. Auf Ihre Worker-Knoten muss die folgende Markierung angewendet werden, wobei my-cluster durch den Namen des Clusters ersetzt wird.

  Schlüssel	Wert
  kubernetes.io/cluster/my-cluster	owned

• Die Knoten können möglicherweise nicht über eine öffentliche IP-Adresse auf den Cluster zugreifen. Stellen Sie sicher, dass den Knoten, die in öffentlichen Subnetzen bereitgestellt werden, eine öffentliche IP-Adresse zugewiesen wird. Ist dies nicht der Fall, können Sie einem Knoten eine Elastic-IP-Adresse nach dem Start zuordnen. Weitere Informationen dazu finden Sie unter Zuordnen einer Elastic-IP-Adresse zu einer laufenden Instance oder einer Netzwerkschnittstelle. Wenn das öffentliche Subnetz nicht so eingestellt ist, dass es Instances, die es nutzen, automatisch öffentliche IP-Adressen zuweist, empfehlen wir, diese Einstellung zu aktivieren. Weitere Informationen finden Sie unter Ändern des öffentlichen IPv4-Adressierungsattributs für Ihr Subnetz. Wenn der Arbeitsknoten in einem privaten Subnetz bereitgestellt wird, muss das Subnetz über eine Route zu einem NAT-Gateway verfügen, dem eine öffentliche IP-Adresse zugewiesen ist.

• Der STS-Endpunkt für die AWS-Region, in der Sie die Knoten bereitstellen, ist für Ihr Konto nicht aktiviert. Informationen zum Aktivieren der Region finden Sie unter Aktivieren und Deaktivieren von AWS STS in einer AWS-Region.

• Der Worker-Knoten hat keinen privaten DNS-Eintrag, was dazu führt, dass das kubelet-Protokoll einen node "" not found-Fehler enthält. Stellen Sie sicher, dass die VPC, auf der der Worker-Knoten erstellt wird, Werte für domain-name und domain-name-servers als Options in einem DHCP options set festgelegt hat. Die Standard-Werte sind domain-name:<region>.compute.internal und domain-name-servers:AmazonProvidedDNS. Weitere Informationen dazu finden Sie unter DHCP-Optionsgruppen im Amazon VPC Benutzerhandbuch.

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, ist Ihre kubectl nicht richtig für Amazon EKS konfiguriert oder die von Ihnen verwendeten IAM-Prinzipal-Anmeldeinformationen sind keinem RBAC-Benutzer mit ausreichenden Berechtigungen in Ihrem -Cluster zugeordnet.

• could not get token: AccessDenied: Access denied

• error: You must be logged in to the server (Unauthorized)

• error: the server doesn't have a resource type "svc"

Dies könnte daran liegen, dass das Cluster mit Anmeldeinformationen für einen IAM-Prinzip erstellt wurde und kubectl Anmeldeinformationen für einen anderen IAM-Prinzipal verwendet.

Wenn ein Amazon-EKS-Cluster erstellt wird, wird der IAM-Prinzipal, der den Cluster erstellt, als Administrator (mit system:masters-Berechtigungen) zur Kubernetes-RBAC-Autorisierungstabelle hinzugefügt. Anfänglich kann nur dieser Prinzipal Aufrufe an den Kubernetes-API-Server mit kubectl tätigen. Weitere Informationen finden Sie unter IAM-Prinzipal-Zugriff auf Ihrem Cluster aktivieren. Wenn Sie die Konsole zum Erstellen des Clusters verwenden, stellen Sie sicher, dass sich dieselben IAM-Anmeldeinformationen in der AWS-SDK-Anmeldeinformationskette befinden, wenn Sie kubectl-Befehle auf Ihrem Cluster ausführen.

Wenn Sie die AWS CLI installieren und konfigurieren, können Sie die IAM-Anmeldeinformationen konfigurieren, die Sie verwenden. Weitere Informationen dazu finden Sie unter Konfigurieren der AWS CLI im AWS Command Line Interface-Benutzerhandbuch.

Wenn Sie eine Rolle angenommen haben, um den Amazon-EKS-Cluster zu erstellen, müssen Sie sicherstellen, dass kubectl für das Annehmen derselben Rolle konfiguriert ist. Verwenden Sie den folgenden Befehl, um Ihre kubeconfig-Datei für die Verwendung einer IAM-Rolle zu aktualisieren. Weitere Informationen finden Sie unter Erstellen oder Aktualisieren einer kubeconfig-Datei für einen Amazon-EKS-Cluster.

aws eks update-kubeconfig \
    --region region-code \
    --name my-cluster \
    --role-arn arn:aws:iam::111122223333:role/role_name

Um einen IAM-Prinzipal einem Kubernetes-RBAC-Benutzer zuzuordnen, lesen Sie IAM-Prinzipal-Zugriff auf Ihrem Cluster aktivieren.

aws-iam-authenticator nicht gefunden

Wenn der Fehler "aws-iam-authenticator": executable file not found in $PATH angezeigt wird, ist Ihr kubectl nicht für Amazon EKS konfiguriert. Weitere Informationen finden Sie unter Installieren von aws-iam-authenticator.

Anmerkung

Die aws-iam-authenticator ist nicht erforderlich, wenn Sie die AWS CLI-Version 1.16.156 oder höher installiert haben.

hostname doesn't match

Die Python-Version Ihres Systems muss 2.7.9 oder höher sein. Andernfalls werden bei Amazon EKS-Aufrufen mit AWS CLI hostname doesn't match-Fehler angezeigt. Weitere Informationen dazu finden Sie unter Was sind „Hostname stimmt nicht überein“-Fehler? in den häufig gestellten Fragen auf der Python Requests-Website.

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 die Fehlermeldung Instances failed to join the kubernetes cluster in der AWS Management Console angezeigt wird, stellen Sie sicher, dass entweder der private Endpunktzugriff des Clusters aktiviert ist oder dass Sie CIDR-Blöcke für den öffentlichen Endpunktzugriff korrekt konfiguriert haben. Weitere Informationen finden Sie unter Zugriffskontrolle für den Amazon-EKS-Cluster-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 basiert sind. Die Fehlercodes sind in der folgenden Liste beschrieben.

• AccessDenied: Amazon EKS oder ein oder mehrere Ihrer verwalteten Knoten kann nicht mit Ihrem Kubernetes-Cluster-API-Server authentifizieren oder autorisieren. Weitere Informationen zum Beheben einer häufigen Ursache finden Sie unter Behebung einer häufigen Ursache für AccessDenied-Fehler bei verwalteten Knotengruppen. Neben der Fehlermeldung Not authorized for images können private Windows-AMIs auch diesen Fehlercode verursachen. Weitere Informationen finden Sie unter Not authorized for images.

• AmiIdNotFound: Die AAMI-ID, die Ihrer Startvorlage zugeordnet ist, konnte nicht gefunden werden. Stellen Sie sicher, dass das AMI vorhanden ist und für Ihr Konto freigegeben ist.

• AutoScalingGroupNotFound: Die Auto-Scaling-Gruppe, die der verwalteten Knotengruppe zugeordnet ist, konnte nicht gefunden werden. Möglicherweise können Sie eine Auto-Scaling-Gruppe mit den gleichen Einstellungen zur Wiederherstellung erstellen.

• ClusterUnreachable: Amazon EKS oder ein oder mehrere Ihrer verwalteten Knoten kann nicht mit Ihrem Kubernetes-Cluster-API-Server kommunizieren. Dies kann passieren, wenn Netzwerkunterbrechungen auftreten oder wenn API-Server eine Zeitüberschreitung für die Verarbeitung von Anforderungen vornehmen.

• EC2SecurityGroupNotFound: Die Cluster-Sicherheitsgruppe für den Cluster konnte nicht gefunden werden. Sie müssen Ihren Cluster neu erstellen.

• EC2SecurityGroupDeletionFailure: Die RAS-Sicherheitsgruppe für Ihre verwaltete Knotengruppe konnte nicht gelöscht werden. Entfernen Sie alle Abhängigkeiten aus der Sicherheitsgruppe.

• Ec2LaunchTemplateNotFound: Die Amazon-EC2-Startvorlage für Ihre verwaltete Knotengruppe konnte nicht gefunden werden. Sie müssen Ihre Knotengruppe neu erstellen, um sie wiederherzustellen.

• Ec2LaunchTemplateVersionMismatch: Die Amazon-EC2-Startvorlagenversion für Ihre verwaltete Knotengruppe stimmt nicht mit der von Amazon EKS erstellten Version überein. Möglicherweise können Sie zu der Version zurückkehren, die Amazon EKS für die Wiederherstellung erstellt hat.

• IamInstanceProfileNotFound: Das IAM-Instance-Profil für Ihre verwaltete Knotengruppe konnte nicht gefunden werden. Möglicherweise können Sie erneut ein Instance-Profil mit den gleichen Einstellungen zur Wiederherstellung erstellen.

• IamNodeRoleNotFound: Die IAM-Rolle für Ihre verwaltete Knotengruppe konnte nicht gefunden werden. Möglicherweise können Sie erneut eine IAM-Rolle mit den gleichen Einstellungen zur Wiederherstellung erstellen.

• AsgInstanceLaunchFailures: Beim Versuch, Instances zu starten, treten in Ihrer Auto-Scaling-Gruppe Fehlfunktionen auf.

• NodeCreationFailure: Ihre gestarteten Instances können sich nicht bei Ihrem Amazon-EKS-Cluster registrieren. Häufige Ursachen für diesen Fehler sind unzureichende Knoten-IAM-Rollen-Berechtigungen oder fehlender ausgehender Internetzugriff für die Knoten. Ihre Knoten müssen eine der folgenden Anforderungen erfüllen:

  • Kann über eine öffentliche IP-Adresse auf das Internet zugreifen. Die Sicherheitsgruppe, die mit dem Subnetz verknüpft ist, in dem sich der Knoten befindet, muss die Kommunikation zulassen. Weitere Informationen finden Sie unter Subnetz-Anforderungen und -Überlegungen und Anforderungen und Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

  • Ihre Knoten und Ihre VPC müssen die Anforderungen in Anforderungen an private Cluster erfüllen.

• InstanceLimitExceeded: Ihr AWS-Konto kann keine weiteren Instances des angegebenen Instance-Typs starten. Möglicherweise können Sie eine Erhöhung des Amazon-EC2-Instance-Limits zur Wiederherstellung anfordern.

• InsufficientFreeAddresses: Ein oder mehrere der Subnetze, die Ihrer verwalteten Knotengruppe zugeordnet sind, verfügen nicht über genügend verfügbare IP-Adressen für neue Knoten.

• InternalFailure: Diese Fehler werden normalerweise durch ein serverseitiges Amazon-EKS-Problem verursacht.

Behebung einer häufigen Ursache für AccessDenied-Fehler bei verwalteten Knotengruppen

Die häufigste Ursache für AccessDenied-Fehler beim Ausführen von Vorgängen auf verwalteten Knotengruppen ist das Fehlen von eks:node-manager, ClusterRole oder ClusterRoleBinding. Amazon EKS richtet diese Ressourcen in Ihrem Cluster als Teil des Onboarding mit verwalteten Knotengruppen ein, die für die Verwaltung der Knotengruppen erforderlich sind.

Die ClusterRole kann sich im Laufe der Zeit ändern, sollte aber dem folgenden Beispiel ähneln:

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               
            

Die ClusterRoleBinding kann sich im Laufe der Zeit ändern, sollte aber dem folgenden Beispiel ähneln:

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

Stellen Sie sicher, dass die Ressource eks:node-manager ClusterRole besteht.

kubectl describe clusterrole eks:node-manager

Wenn bestehend, vergleichen Sie die Ausgabe mit dem vorherigen ClusterRole-Beispiel.

Stellen Sie sicher, dass die Ressource eks:node-manager ClusterRoleBinding besteht.

kubectl describe clusterrolebinding eks:node-manager

Wenn bestehend, vergleichen Sie die Ausgabe mit dem vorherigen ClusterRoleBinding-Beispiel.

Wenn Sie einen fehlenden oder defekten ClusterRole oder ClusterRoleBinding als Ursache eines AcessDenied-Fehlers beim Anfordern verwalteter Knotengruppenoperationen finden, können Sie sie wiederherstellen. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen eks-node-manager-role.yaml.

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

Wenden Sie die Datei an.

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

Wiederholen Sie den Vorgang der Knotengruppe, um festzustellen, ob das Problem dadurch behoben wurde.

Not authorized for images

Eine mögliche Ursache für die Fehlermeldung Not authorized for images ist die Verwendung eines privaten Windows-AMI von Amazon EKS zum Starten verwalteter Windows-Knotengruppen. Nach der Veröffentlichung neuer Windows-AMIs stellt AWS Windows-AMIs, die älter als drei Monate sind, innerhalb von 10 Tagen auf privat um. Wenn Ihre verwaltete Knotengruppe ein privates Windows-AMI von Amazon EKS verwendet, sollten Sie erwägen, Ihre verwaltete Windows-Knotengruppe zu aktualisieren. Weitere Informationen finden Sie unter Patches, Sicherheitsupdates und AMI-IDs im Amazon-EC2-Benutzerhandbuch für Windows-Instances.

CNI-Protokollerfassungstool

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

Anmerkung

Wenn das Skript an diesem Speicherort nicht vorhanden ist, konnte der CNI-Container nicht ausgeführt werden. Sie können das Skript mit dem folgenden Befehl manuell herunterladen und ausführen:

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 bereitgestellte CNI-Version kann jünger 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

Die Fehler hängen höchstwahrscheinlich damit zusammen, dass die AWS-IAM-Authentifizierer-Konfigurationszuordnung (aws-auth) nicht auf den Cluster angewendet wird. Die Konfigurationszuordnung stellt die system:bootstrappers- und -system:nodes Kubernetes-RBAC-Berechtigungen für Worker-Knoten zur Registrierung im Cluster bereit. Informationen zum Anwenden der Konfigurationszuordnung auf den Cluster finden Sie unter Anwendung der aws-authConfigMap auf Ihren Cluster.

Der Authentifizierer erkennt einen Role ARN (Rollen-ARN) nicht, wenn er einen anderen Pfad als / enthält, wie im folgenden Beispiel:

arn:aws:iam::111122223333:role/development/apps/prod-iam-role-NodeInstanceRole-621LVEXAMPLE

Wenn Sie in der Konfigurationszuordnung einen Role ARN (Rollen-ARN) angeben, der einen anderen Pfad als / enthält, müssen Sie den Pfad löschen. Der zuvor genannte ARN sollte wie folgt angegeben werden:

arn:aws:iam::111122223333:role/prod-iam-role-NodeInstanceRole-621LVEXAMPLE

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 Servicekonten für einen Pod oder ein DaemonSet verwenden, der bzw. das auf einem Cluster in einer AWS-Region in China bereitgestellt wird, und die Umgebungsvariable AWS_DEFAULT_REGION nicht in der Spezifikation festgelegt haben, wird für den Pod oder das DaemonSet möglicherweise die folgende Fehlermeldung angezeigt:

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

Zur Behebung des Problems müssen Sie die AWS_DEFAULT_REGION-Umgebungsvariable Ihrer Pod- oder DaemonSet-Spezifikation wie in der folgenden Beispiel-Pod-Spezifikation hinzufügen.

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"

Ablauf des Webhook-Zertifikats für die VPC-Zulassung

Wenn das Zertifikat, das zum Signieren des Webhook für die VPC-Zulassung verwendet wurde, abläuft, bleibt der Status für neue Windows-Pod-Bereitstellungen auf ContainerCreating.

Informationen zum Beheben des Problems, wenn Sie Legacy-System-Windows-Support auf Ihrer Datenebene haben, finden Sie unter Erneuerung des VPC-Zulassungs-Webhook-Zertifikats. Wenn Ihre Cluster- und Plattformversion höher ist als eine Version, die unter Windows-Supportvoraussetzungen aufgeführt ist, wird empfohlen, den Legacy-System-Windows-Support auf Ihrer Datenebene zu entfernen und für Ihre Steuerebene zu aktivieren. Sobald Sie dies getan haben, müssen Sie das Webhook-Zertifikat nicht mehr verwalten. Weitere Informationen finden Sie unter Die Windows-Unterstützung für Ihre Amazon-EKS-Cluster aktivieren.

Knotengruppen müssen mit der Kubernetes-Version übereinstimmen, bevor die Steuerebene aktualisiert wird

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 EKS-update-cluster-version-API lehnt Anfragen ab, bis Sie alle von EKS verwalteten Knoten auf die aktuelle Cluster-Version aktualisieren. EKS stellt APIs zur Verfügung, um verwaltete Knoten zu aktualisieren. Informationen zum Aktualisieren von Kubernetes-Versionen für verwaltete Knotengruppen finden Sie unter Aktualisieren einer verwalteten Knotengruppe. Um die Version eines Fargate-Knotens zu aktualisieren, löschen Sie den Pod, der durch den Knoten repräsentiert wird, und stellen Sie den Pod erneut bereit, nachdem Sie Ihre Steuerebene aktualisiert haben. Weitere Informationen finden Sie unter Aktualisieren einer Amazon-EKS-Cluster-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 Worker-Knoten-Bootstrap-Skript ü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 Stellen Sie Benutzerdaten bereit, um Argumente an die bootstrap.sh-Datei zu übergeben, die in einem für Amazon EKS optimierten Linux/Bottlerocket-AMI enthalten ist.

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

Sie sehen diese Fehler, wenn das Servicekonto-Token eines Pod auf einem Cluster der Version 1.21 oder höher abgelaufen ist.

Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters der Version 1.21 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:

• Go-Version 0.15.7 und höher

• Python-Version 12.0.0 und höher

• Java-Version 9.0.0 und höher

• JavaScript-Version 0.10.3 und höher

• Ruby master-Branch

• Haskell-Version 0.3.0.0

• C#-Version 7.0.5 und höher

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

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 eines dieser Probleme auf Ihren Cluster zutrifft, funktioniert es möglicherweise immer noch, seine Plattformversion wird einfach 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 durch den Namen Ihres Clusters.

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

Die Beispielausgabe lautet wie folgt.

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 durch den Namen Ihres Clusters.

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

Die Beispielausgabe lautet wie folgt.

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

Lösung

Bestätigen Sie, ob die Subnetz-IDs in Ihrem Konto vorhanden sind.

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"

Die Beispielausgabe lautet wie folgt.

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

Wenn die in der Ausgabe zurückgegebenen Subnetz-IDs nicht mit den Subnetz-IDs übereinstimmen, die bei der Erstellung des Clusters angegeben wurden, müssen Sie möglicherweise einen neuen Cluster erstellen, wenn Sie möchten, dass Amazon EKS den Cluster aktualisiert. 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 existiert. 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. Sie können keine neuen Subnetze erstellen, die Ihr Cluster nach der Cluster-Erstellung verwenden kann.

Wenn Sie ein Kubernetes-Versionsupdate für Ihren Cluster initiieren, kann das Update 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 deren IDs mit dem folgenden Befehl anzeigen. Ersetzen Sie my-cluster durch den Namen Ihres Clusters.

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

Die Beispielausgabe lautet wie folgt.

[
    "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"

Die Beispielausgabe lautet wie folgt.

[
"sg-EXAMPLE2"
]

Wenn die in der Ausgabe zurückgegebenen Sicherheitsgruppen-IDs nicht mit den Sicherheitsgruppen-IDs übereinstimmen, die bei der Erstellung des Clusters angegeben wurden, müssen Sie einen neuen Cluster erstellen, wenn Sie möchten, dass Amazon EKS den Cluster aktualisiert. Amazon EKS aktualisiert einen Cluster nicht, wenn die bei der Clustererstellung angegebenen Sicherheitsgruppen-IDs nicht existieren. Sie können nach der Clustererstellung keine anderen Sicherheitsgruppen angeben.

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

Andere Gründe, warum Amazon EKS die Plattformversion Ihres Clusters nicht aktualisiert

• Sie haben nicht mindestens sechs verfügbare IP-Adressen (wir empfehlen jedoch 16) in jedem der Subnetze, die Sie bei der Erstellung Ihres Clusters angegeben haben. Wenn Sie nicht über genügend verfügbare IP-Adressen im Subnetz verfügen, müssen Sie entweder IP-Adressen im Subnetz freigeben oder Sie müssen einen neuen Cluster erstellen, der Subnetze mit ausreichend verfügbaren IP-Adressen verwendet.

• Sie haben die Verschlüsselung von Secrets aktiviert, als Sie Ihren Cluster erstellt haben, und der von Ihnen angegebene AWS KMS-Schlüssel wurde gelöscht. Wenn Sie möchten, dass Amazon EKS den Cluster aktualisiert, müssen Sie einen neuen Cluster erstellen