Amazon EKS-Fehlersuche - Amazon EKS

Amazon EKS-Fehlersuche

In diesem Kapitel werden einige häufige Fehler bei der Verwendung von Amazon EKS sowie deren Lösung behandelt.

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.

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

Es gibt zwei häufige Gründe, aus denen Arbeitsknoten 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 Arbeitsknoten. Stellen Sie sicher, dass der ARN der IAM-Rolle des Arbeitsknotens (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 Worker-Knotens stimmt nicht genau mit dem Namen des Clusters überein, den Sie mit Ihren Worker-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 Worker-Knotens und dieser kann nicht mit dem Cluster verknüpft werden.

  • Der Arbeitsknoten ist nicht als Eigentum des Clusters gekennzeichnet. Auf Ihre Arbeitsknoten muss das folgende Tag angewendet werden, wobei <cluster-name> durch den Namen des Clusters ersetzt wird.

    Schlüssel Value

    kubernetes.io/cluster/<cluster-name>

    owned

  • Die Arbeitsknoten (Worker-Knoten) können möglicherweise nicht über eine öffentliche IP-Adresse auf den Cluster zugreifen. Stellen Sie sicher, dass Arbeitsknoten, die in öffentlichen Subnetzen bereitgestellt werden, eine öffentliche IP-Adresse zugewiesen wird. Ist dies nicht der Fall, können Sie einem Arbeitsknoten eine Elastic IP-Adresse nach dem Start zuordnen. Weitere Informationen 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 Region, für die Sie die Worker-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 Workerknoten hat keinen privaten DNS-Eintrag, was dazu führt,kubelet-Protokoll, das einnode "" not found-Fehler erstellt. Stellen Sie sicher, dass die VPC, auf der der Workerknoten erstellt wird, Werte fürdomain-nameunddomain-name-serversalsOptionsin einemDHCP options setaus. Die Standard-Werte sind domain-name:<region>.compute.internal und domain-name-servers:AmazonProvidedDNS. Weitere Informationen finden Sie unter DHCP-Optionsgruppen im Amazon VPC Benutzerhandbuch.

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-Benutzer- oder Rollen-Anmeldeinformationen sind keinem Kubernetes 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"

Der Grund dafür könnte sein, dass der Cluster mit AWS-Anmeldeinformationen (von einem IAM-Benutzer oder einer Rolle) erstellt wurde und dass kubectl andere Anmeldeinformationen verwendet.

Wenn ein Amazon EKS-Cluster erstellt wird, wird die IAM-Entität (Benutzer oder Rolle), die den Cluster erstellt, zur Kubernetes-RBAC-Autorisierungstabelle als Administrator (mit system:masters-Berechtigungen) hinzugefügt. Anfänglich kann nur dieser IAM-Benutzer Aufrufe an den Kubernetes-API-Server mit kubectl tätigen. Weitere Informationen finden Sie unter Verwalten von Benutzern oder IAM-Rollen für Ihren Cluster. Wenn Sie die Konsole verwenden, um den Cluster zu erstellen, müssen Sie sicherstellen, dass sich die gleichen IAM-Anmeldeinformationen in den AWS-SDK-Anmeldeinformationen befinden, wenn Sie kubectl-Befehle auf Ihrem Cluster ausführen.

Wenn Sie die AWS CLI installieren und konfigurieren, können Sie die IAM-Anmeldeinformationen für Ihren Benutzer konfigurieren. Weitere Informationen 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 Sie ein kubeconfig für Amazon EKS.

aws eks update-kubeconfig \ --region <region-code> \ --name <cluster_name> \ --role-arn arn:aws:iam::<aws_account_id>:role/<role_name>

Um einen IAM-Benutzer einem Kubernetes RBAC-Benutzer zuzuordnen, lesen Sie Verwalten von Benutzern oder IAM-Rollen für Ihren Cluster.

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

Fehler bei verwalteten Knotengruppen

Wenn die Fehlermeldung „Instances konnten dem Kubernetes-Cluster nicht beitreten“ 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.

Wenn bei Ihrer verwaltete Knotengruppe ein Integritätsproblem auftritt, gibt Amazon EKS eine Fehlermeldung zurück, die Ihnen bei der Diagnose des Problems hilft. Die folgenden Fehlermeldungen und die zugehörigen Beschreibungen werden unten dargestellt.

  • AccessDeniedAmazon EKS oder ein oder mehrere Ihrer verwalteten Knoten kann nicht mit Ihrem Kubernetes-Cluster-API-Server authentifizieren oder autorisieren. Informationen zur Behebung häufiger Ursachen für diesen Fehler finden Sie unter FixingAccessDenied-Fehler für verwaltete Knotengruppen.

  • AmiidNotFoundDie -AAMI -ID, die Ihrer Launch-Vorlage 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 -Gruppe mit den gleichen Einstellungen zur Wiederherstellung erstellen.

  • ClusterUnreachable: Amazon EKS oder ein oder mehrere Ihrer verwalteten Knoten kann nicht mit Ihrem 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 -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 Ihrer Auto Scaling-Gruppe, Instances zu starten, treten Fehler auf.

  • NodeCreationFailure:Ihre gestarteten Instances können sich nicht bei Ihrem Amazon EKS-Cluster registrieren. Häufige Ursachen für diesen Fehler sind unzureichende Arbeitsknoten-IAM-Rollenberechtigungen oder fehlender ausgehender Internetzugriff für die Knoten. Für ein ordnungsgemäßes Funktionieren müssen Ihre Worker-Knoten über eine öffentliche IP-Adresse auf das Internet zugreifen können. Weitere Informationen finden Sie unter VPC-IP-Adressierung. Ihre Arbeitsknoten müssen auch über Ports mit offenem Zugang zum Internet verfügen. Weitere Informationen finden Sie unter Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

  • InstanceLimitExceeded: Ihr AWS-Konto kann keine weiteren Instances des angegebenen Instance-Typs starten. Möglicherweise können Sie eine Erhöhung der Amazon EC2-Instance-Limit 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.

Die häufigste Ursache fürAccessDeniedFehler beim Ausführen von Vorgängen auf verwalteten Knotengruppen fehlt dieeks:node-manager ClusterRoleoderClusterRoleBindingaus. 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.

DieClusterRoleIm Laufe der Zeit ändern kann, 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

DieClusterRoleBindingIm Laufe der Zeit ändern kann, 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 vorhanden ist.

kubectl describe clusterrole eks:node-manager

Wenn vorhanden, vergleichen Sie die Ausgabe mit dem vorherigenClusterRole--Beispiel.

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

kubectl describe clusterrolebinding eks:node-manager

Wenn vorhanden, vergleichen Sie die Ausgabe mit dem vorherigenClusterRoleBinding--Beispiel.

Wenn Sie einen fehlenden oder defektenClusterRoleoderClusterRoleBindingals Ursache einesAcessDeniedFehler beim Anfordern verwalteter Knotengruppenoperationen, können Sie sie wiederherstellen. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen eks-node-manager-role.yaml auf Ihrem Computer.

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.

CNI-Protokollerfassungstool

Das Amazon VPC CNI-Plugin für Kubernetes verfügt über ein eigenes Fehlerbehebungsskript, das auf Knoten unter/opt/cni/bin/aws-cni-support.shaus. Sie können das Skript verwenden, um Diagnoseprotokolle für Supportfälle und allgemeine Fehlerbehebung zu sammeln.

Mit dem folgenden Befehl können Sie das Skript auf dem Worker-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 unter gespeichert.

/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 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 nicht auf die Worker-Knoten angewendet wird. Die Konfigurationszuordnung stellt die system:bootstrappers- und system:nodes-Kubernetes RBAC-Berechtigungen für Worker-Knoten zur Registrierung im Cluster bereit. Weitere Informationen finden Sie unter So ermöglichen Sie Worker-Knoten den Beitritt zu Ihrem Cluster auf der Registerkarte Self-managed nodes (Selbstverwaltete Knoten) von Starten selbstverwalteter Amazon Linux-Knoten. Stellen Sie sicher, dass Sie den Role ARN (Rollen-ARN) der Instance-Rolle in der Konfigurationszuordnung und nicht den Instance Profile ARN (ARN des Instance-Profils)angeben.

Der Authentifizierer erkennt einen Role ARN (Rollen-ARN) nicht, wenn er einen anderen Pfad als / enthält, vgl. das folgende 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 obige ARN würde wie folgt angegeben:

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

TLS-Handshake-Zeitüberschreitung

Wenn ein Worker-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 Worker-Knoten den öffentlichen Endpunkt erreichen kann.

InvalidClientTokenId

Wenn Sie IAM-Rollen für Servicekonten für einen Pod oder einen DaemonSet verwenden und die AWS_DEFAULT_REGION-Umgebungsvariable nicht in der Spezifikation festgelegt haben, erhält der Pod oder der DaemonSet möglicherweise die folgende Fehlermeldung:

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 VPC Zulassungswebhook-Zertifikats

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 beiContainerCreatingaus. Wenn dies angezeigt wird, zeigen Sie Informationen über den Pod in diesem Zustand mit dem folgenden Befehl an.

kubectl describe pod my-pod -n my-namespace

Sie sehen das folgende Ereignis in der zurückgegebenen Ausgabe.

Warning FailedCreatePodSandBox 39s kubelet

Überprüfen Sie das Ablaufdatum Ihres Zertifikats mit dem folgenden Befehl.

kubectl get secret \ -n kube-system \ vpc-admission-webhook-certs -o json | \ jq -r '.data."cert.pem"' | \ base64 --decode | \ openssl x509 \ -noout \ -enddate | \ cut -d= -f2

Ausgabe

May 27 14:23:00 2021 GMT

Wenn Ihr Zertifikat abgelaufen ist, müssen Sie es erneuern. Weitere Informationen finden Sie unter Erneuerung des VPC-Zulassungs-Webhook-Zertifikats. Nachdem Sie das neue Zertifikat bereitgestellt haben, müssen Sie jeden Pod erneut bereitstellen, der mit einemContainerCreatingStatus.