Helfen Sie mit, diese Seite zu verbessern
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Möchten Sie zu diesem Benutzerhandbuch beitragen? Wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet. Ihre Beiträge werden dazu beitragen, dass unser Benutzerhandbuch für alle besser wird.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Probleme mit Amazon EKS-Clustern und -Knoten beheben
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, Probleme mit dem Amazon EKS Connector beheben 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
Unzureichende Kapazität
Wenn Sie beim Versuch, einen Amazon EKS-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, 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 ein Cluster nicht befinden kann. Vergleichen Sie die Availability Zones, in denen sich Ihre Subnetze befinden, mit der Liste der Availability Zones in den Subnetzanforderungen 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:
-
Wenn es sich bei den Knoten um verwaltete Knoten handelt, fügt Amazon EKS Einträge zu
aws-auth
ConfigMap
hinzu, wenn Sie die Knotengruppe erstellen. Wenn der Eintrag entfernt oder geändert wurde, müssen Sie ihn erneut hinzufügen. Weitere Informationen erhalten Sie durch Eingabe voneksctl create iamidentitymapping --help
im Terminal. Sie können Ihre aktuellenaws-auth
ConfigMap
Einträge anzeigen, indem Siemy-cluster
den folgenden Befehl durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:.eksctl get iamidentitymapping --cluster
Der ARN der Rolle, die Sie angeben, darf keinen anderen Pfad als enthaltenmy-cluster
/
. Wenn der Name Ihrer Rolle beispielsweise lautetdevelopment/apps/my-role
, müssen Sie ihnmy-role
bei der Angabe des ARN für die Rolle in ändern. Achten Sie darauf, den ARN der IAM-Rolle des Knotens (nicht den ARN des Instances-Profils) anzugeben.Wenn die Knoten selbst verwaltet werden und Sie keine Zugriffseinträge für den ARN der IAM-Rolle des Knotens erstellt haben, führen Sie dieselben Befehle aus, die für verwaltete Knoten aufgeführt sind. Wenn Sie einen Zugriffseintrag für den ARN für die IAM-Rolle Ihres Knotens erstellt haben, ist er im Zugriffseintrag möglicherweise nicht richtig konfiguriert. Achten Sie darauf, dass in Ihrem
aws-auth
ConfigMap
-Eintrag oder Zugriffseintrag der ARN der IAM-Rolle des Knotens (nicht der ARN des Instances-Profils) als Haupt-ARN angegeben ist. Weitere Informationen zu Zugriffseinträgen finden Sie unter Gewährung IAM Benutzerzugriff auf Kubernetes mit EKS-Zugangseinträgen. -
Die AWS CloudFormation Vorlage ClusterNamein Ihrem Knoten entspricht nicht genau dem Namen des Clusters, dem Ihre Knoten beitreten sollen. Die Übergabe eines falschen Werts an dieses Feld führt zu einer falschen Konfiguration der
/var/lib/kubelet/kubeconfig
Knotendatei, und die Knoten werden dem Cluster nicht beitreten. -
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. Wenn nicht, können Sie einem Knoten nach dem Start eine Elastic IP-Adresse 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 Public IPv4 Addressing-Attributs 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 AWS STS-Endpunkt für die AWS Region, in der Sie die Knoten bereitstellen, ist für Ihr Konto nicht aktiviert. Informationen zur Aktivierung der Region finden Sie unter AWS STS in einer AWS Region aktivieren und deaktivieren.
-
Der Knoten hat keinen privaten DNS-Eintrag, was dazu führt, dass das
kubelet
Protokoll einennode "" not found
Fehler enthält. Stellen Sie sicher, dass für die VPC, in der der Knoten erstellt wird, Werte fürdomain-name
unddomain-name-servers
alsOptions
in einemDHCP options set
festgelegt sind. Die Standard-Werte sinddomain-name:<region>.compute.internal
unddomain-name-servers:AmazonProvidedDNS
. Weitere Informationen finden Sie unter DHCP-Optionssätze im Amazon-VPC-Benutzerhandbuch. -
Wenn die Knoten in der verwalteten Knotengruppe innerhalb von 15 Minuten keine Verbindung zum Cluster herstellen, wird ein Systemfehler von NodeCreationFailure "" ausgegeben und der Konsolenstatus wird auf gesetzt
Create failed
. Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Windows AMIs bei denen die Startzeiten langsam sind, kann dieses Problem mithilfe von Fast Launch behoben werden.
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, haben Sie Amazon EKS nicht richtig kubectl
konfiguriert oder die Anmeldeinformationen für den IAM-Principal (Rolle oder Benutzer), den Sie verwenden, sind nicht zugeordnet Kubernetes Benutzername, der über ausreichende Berechtigungen verfügt für Kubernetes Objekte auf Ihrem Amazon EKS-Cluster.
-
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"
Das kann auf eine der folgenden Ursachen zurückzuführen sein:
-
Der Cluster wurde mit Anmeldeinformationen für einen bestimmten IAM-Prinzipal erstellt und
kubectl
ist für die Verwendung von Anmeldeinformationen für einen anderen IAM-Prinzipal konfiguriert. Aktualisieren Sie in diesem Fall die Dateikube config
mit den Anmeldeinformationen, mit denen der Cluster erstellt wurde, um das Problem zu beheben. Weitere Informationen finden Sie unter Verbinden kubectl zu einem EKS-Cluster durch Erstellen eines kubeconfig file. -
Wenn Ihr Cluster die minimalen Plattformanforderungen im Abschnitt Voraussetzungen von Gewähren Sie IAM-Benutzern Zugriff auf Kubernetes mit EKS-Zugriffseinträgen gewährt, erfüllt, ist kein Zugriffseintrag mit Ihrem IAM-Prinzipal vorhanden. Wenn er existiert, verfügt er nicht über die erforderlichen Kubernetes Für sie wurden Gruppennamen definiert oder ihr wurde nicht die richtige Zugriffsrichtlinie zugewiesen. Weitere Informationen finden Sie unter Gewährung IAM Benutzerzugriff auf Kubernetes mit EKS-Zugangseinträgen.
-
Wenn Ihr Cluster die minimalen Plattformanforderungen unter Gewähren Sie IAM-Benutzern Zugriff auf Kubernetes mit EKS-Zugriffseinträgen gewährt, nicht erfüllt, ist kein Eintrag mit Ihrem IAM-Prinzipal in der vorhanden.
aws-auth
ConfigMap
Wenn er existiert, ist er nicht zugeordnet Kubernetes Gruppennamen, die an a gebunden sind KubernetesRole
oderClusterRole
mit den erforderlichen Berechtigungen. Weitere Informationen zur Kubernetes Objekte für die rollenbasierte Autorisierung (RBAC) finden Sie unter Verwendender RBAC-Autorisierung im Kubernetes -Dokumentation. Sie können Ihre aktuellen aws-auth
ConfigMap
Einträge anzeigen, indem Sie den folgenden Befehl durch den Namen Ihres Clusters ersetzenmy-cluster
und dann den geänderten Befehl ausführen:.eksctl get iamidentitymapping --cluster
Wenn ein Eintrag für mit dem ARN Ihres IAM-Prinzipals nicht in der enthalten istmy-cluster
ConfigMap
, geben Sie ihneksctl create iamidentitymapping --help
in Ihr Terminal ein, um zu erfahren, wie Sie einen erstellen.
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
die Verwendung einer IAM-Rolle konfigurieren, wenn Sie für den Zugriff von einer IAM-Rolle ausgehen 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-Aufrufen an Amazon EKS. Weitere Informationen finden Sie unter Was sind „Hostname stimmt nicht überein“ -Fehler
getsockopt: no route to host
Docker läuft im 172.17.0.0/16
CIDR-Bereich in Amazon EKS-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 erhalten, stellen Sie sicher AWS Management Console, 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 Steuern Sie den Netzwerkzugriff auf den Cluster-API-Serverendpunkt.
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 Gesundheitschecks erkennen keine Softwareprobleme, da sie auf EC2 Amazon-Gesundheitschecks basieren. Die Fehlercodes sind in der folgenden Liste beschrieben.
- AccessDenied
-
Amazon EKS oder einer oder mehrere Ihrer verwalteten Knoten können sich nicht authentifizieren oder autorisieren mit Ihrem Kubernetes Cluster-API-Server. Weitere Informationen zum Beheben einer häufigen Ursache finden Sie unter Behebung einer häufigen Ursache für AccessDenied-Fehler bei verwalteten Knotengruppen. Privat Windows AMIs kann diesen Fehlercode auch zusammen mit der
Not authorized for images
Fehlermeldung verursachen. Weitere Informationen finden Sie unter Not authorized for images. - AmiIdNotFound
-
Wir konnten die mit Ihrer Startvorlage verknüpfte AMI-ID nicht finden. Stellen Sie sicher, dass das AMI vorhanden ist und für Ihr Konto freigegeben ist.
- AutoScalingGroupNotFound
-
Wir konnten die Auto Scaling Scaling-Gruppe, die der verwalteten Knotengruppe zugeordnet ist, nicht finden. Möglicherweise können Sie eine Auto-Scaling-Gruppe mit den gleichen Einstellungen zur Wiederherstellung erstellen.
- ClusterUnreachable
-
Amazon EKS oder einer oder mehrere Ihrer verwalteten Knoten können nicht mit Ihrem Kubernetes Cluster-API-Server. Dies kann passieren, wenn Netzwerkunterbrechungen auftreten oder wenn API-Server eine Zeitüberschreitung für die Verarbeitung von Anforderungen vornehmen.
- Ec2 SecurityGroupNotFound
-
Wir konnten die Cluster-Sicherheitsgruppe für den Cluster nicht finden. Sie müssen Ihren Cluster neu erstellen.
- Ec2 SecurityGroupDeletionFailure
-
Die RAS-Sicherheitsgruppe für Ihre verwaltete Knotengruppe konnte nicht gelöscht werden. Entfernen Sie alle Abhängigkeiten aus der Sicherheitsgruppe.
- Ec2 LaunchTemplateNotFound
-
Wir konnten die EC2 Amazon-Startvorlage für Ihre verwaltete Knotengruppe nicht finden. Sie müssen Ihre Knotengruppe neu erstellen, um sie wiederherzustellen.
- Ec2 LaunchTemplateVersionMismatch
-
Die Version der EC2 Amazon-Startvorlage für Ihre verwaltete Knotengruppe stimmt nicht mit der Version überein, die Amazon EKS erstellt hat. Möglicherweise können Sie zu der Version zurückkehren, die Amazon EKS für die Wiederherstellung erstellt hat.
- IamInstanceProfileNotFound
-
Wir konnten das IAM-Instance-Profil für Ihre verwaltete Knotengruppe nicht finden. Möglicherweise können Sie erneut ein Instance-Profil mit den gleichen Einstellungen zur Wiederherstellung erstellen.
- IamNodeRoleNotFound
-
Wir konnten die IAM-Rolle für Ihre verwaltete Knotengruppe nicht finden. 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 erhalten Sie unter Subnetz-Anforderungen und -Überlegungen und Amazon EKS-Sicherheitsgruppenanforderungen für Cluster anzeigen.
-
Ihre Knoten und VPC müssen die Anforderungen unter Bereitstellen von privaten Clustern mit eingeschränktem Internetzugang erfüllen.
-
- InstanceLimitExceeded
-
Ihr AWS Konto kann keine weiteren Instances des angegebenen Instanztyps starten. Möglicherweise können Sie eine Erhöhung des EC2 Amazon-Instance-Limits für die Wiederherstellung beantragen.
- InsufficientFreeAddresses
-
In einem oder mehreren der Subnetze, die Ihrer verwalteten Knotengruppe zugeordnet sind, sind nicht genügend IP-Adressen für neue Knoten verfügbar.
- InternalFailure
-
Diese Fehler werden normalerweise durch ein serverseitiges Amazon-EKS-Problem verursacht.
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 bei der Anforderung verwalteter Knotengruppenoperationen ein fehlendes ClusterRole
oder ClusterRoleBinding
defektes Objekt oder die Ursache für einen AcessDenied
Fehler festgestellt haben, können Sie es 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 eine Not authorized for images
Fehlermeldung ist die Verwendung eines privaten Amazon EKS Windows AMI wird gestartet 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 verwendet Windows AMI, erwägen Sie, Ihre Windows-verwaltete Knotengruppe zu aktualisieren. 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 EC2 Amazon-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. wenn dem Knoten nicht genügend Ressourcen für CPU, Arbeitsspeicher oder verfügbaren Festplattenspeicher zur Verfügung stehen.
Für Amazon EKS optimiert Windows AMIs, es gibt keine Reservierung für Rechenressourcen, 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 und/oder system-reserved angeben-KubeletExtraArgs
Befehlszeilenparameter im Bootstrap-Skript. Weitere Informationen finden Sie unter Reservieren von Rechenressourcen für System-Daemons
CNI-Protokollerfassungstool
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
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
Dieses Problem kann folgende Ursachen haben:
-
Sie haben entweder kein in
aws-auth
ConfigMap
Ihrem Cluster oder es enthält keine Einträge für die IAM-Rolle, mit der Sie Ihre Knoten konfiguriert haben.Um das Problem zu beheben, sehen Sie sich die vorhandenen Einträge in Ihrem an, indem Sie den folgenden Befehl
ConfigMap
durch den Namen Ihres Clusters ersetzenmy-cluster
und dann den geänderten Befehl ausführen:eksctl get iamidentitymapping --cluster
. Wenn Sie im Zusammenhang mit dem Befehl eine Fehlermeldung erhalten, liegt das möglicherweise daran, dass Ihr Cluster keine hatmy-cluster
aws-auth
ConfigMap
. Der folgende Befehl fügtConfigMap
einen Eintrag hinzu. Wenn der nichtConfigMap
existiert, wird er vom Befehl ebenfalls erstellt.111122223333
Ersetzen Sie es durch die AWS Konto-ID für die IAM-Rolle undmyAmazonEKSNodeRole
durch den Namen der Rolle Ihres Knotens.eksctl create iamidentitymapping --cluster my-cluster \ --arn arn:aws: iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \ --username system:node:{{EC2PrivateDNSName}}
Der ARN der Rolle, die Sie angeben, darf keinen anderen Pfad als enthalten
/
. Wenn der Name Ihrer Rolle beispielsweise lautetdevelopment/apps/my-role
, müssen Sie ihnmy-role
bei der Angabe des ARN der Rolle in ändern. Achten Sie darauf, den ARN der IAM-Rolle des Knotens (nicht den ARN des Instances-Profils) anzugeben. -
Ihre selbstverwalteten Knoten befinden sich in einem Cluster mit einer Plattformversion in der Mindestversion, die in den Voraussetzungen im Thema Gewähren Sie IAM-Benutzern Zugriff auf Kubernetes mit EKS-Zugriff gewähren aufgeführt ist, aber im Abschnitt
aws-auth
ConfigMap
(siehe vorheriges Element) ist kein Eintrag für die IAM-Rolle des Knotens aufgeführt, oder es ist kein Zugriffseintrag für die Rolle vorhanden. Um das Problem zu beheben, zeigen Sie Ihre vorhandenen Zugriffseinträgemy-cluster
an, indem Sie den folgenden Befehl durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:aws eks list-access-entries --cluster-name
. Der folgende Befehl fügt einen Zugriffseintrag für die IAM-Rolle des Knotens hinzu.my-cluster
111122223333
Ersetzen Sie ihn durch die AWS Konto-ID für die IAM-Rolle undmyAmazonEKSNodeRole
durch den Namen der Rolle Ihres Knotens. Wenn Sie einen Windows-Knoten haben, ersetzen Sie ihnEC2_LINUX
durchEC2_Windows
. Achten Sie darauf, den ARN der IAM-Rolle des Knotens (nicht den ARN des Instances-Profils) anzugeben.aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/myAmazonEKSNodeRole --type EC2_LINUX
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 ein verwenden Pod or DaemonSet auf einem Cluster in einer AWS Region China bereitgestellt und die AWS_DEFAULT_REGION
Umgebungsvariable nicht in der Spezifikation festgelegt wurde, Pod or DaemonSet kann den folgenden Fehler erhalten:
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 or 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. 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 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 EC2 Amazon-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--apiserver-endpoint
, dass die --dns-cluster-ip
Argumente--b64-cluster-ca
, und an das Bootstrap-Skript des Knotens übergeben werden. Wenn Sie diese Argumente einbeziehen, muss das Bootstrap-Skript keinen describeCluster
Aufruf tätigen, wodurch verhindert wird, dass die Steuerungsebene überlastet wird. Weitere Informationen finden Sie unter Geben Sie Benutzerdaten an, um Argumente an die bootstrap.sh Datei zu übergeben, die in einer für Amazon EKS optimierten Datei enthalten ist Linux/Bottlerocket AMI.
HTTP 401, unautorisierte Fehlerantwort auf Kubernetes API-Serveranfragen
Sie sehen diese Fehler, wenn Pod’s Das Dienstkonto-Token ist auf einem Cluster abgelaufen.
Ihre Amazon EKS-Cluster Kubernetes Der API-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 Der API-Server kann Ihre Anfrage nicht aufgrund eines ungültigen Tokens ablehnen. Die von Ihrem Workload verwendete Kubernetes-Client-SDK-Version
-
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 und später
0.10.3
-
Ruby
master
-Branch -
Haskell-Version
0.3.0.0
-
C# Version
7.0.5
und später
Sie können alle vorhandenen identifizieren Pods in Ihrem Cluster, 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 eines dieser Probleme auf Ihren Cluster zutrifft, funktioniert er möglicherweise immer noch, seine Plattformversion wird nur 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 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 ü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 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.
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 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 bei der Erstellung 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 initiieren Kubernetes Versionsupdate für Ihren Cluster, das Update kann aus demselben Grund fehlschlagen.
-
Sie verfügen nicht über mindestens sechs (obwohl wir 16 empfehlen) verfügbare IP-Adressen 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 die vom Cluster verwendeten Subnetze so ändern, dass Subnetze mit ausreichend verfügbaren IP-Adressen verwendet werden.
-
Sie haben die Verschlüsselung von Geheimnissen 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
FAQs Cluster-Integritäts- und Fehlercodes mit Lösungspfaden
Amazon EKS erkennt Probleme mit Ihren EKS-Clustern und der Cluster-Infrastruktur und speichert sie in der Cluster-Integrität. 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 Amazon EKS, um Sicherheitsupdates auf einem heruntergestuften Cluster aufgrund von Problemen mit der erforderlichen Infrastruktur oder Clusterkonfiguration zu installieren. 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.
Sie können über die Amazon EKS-Konsole auf die Integrität Ihres Clusters zugreifen. Suchen Sie hierzu auf der Registerkarte Übersicht der Detailseite des Amazon EKS-Clusters nach dem Abschnitt Integritätsprobleme. Diese Daten sind auch verfügbar, wenn die DescribeCluster
Aktion in der EKS-API aufgerufen wird, beispielsweise von der AWS Befehlszeilenschnittstelle aus.
- Warum sollte ich diese Funktion verwenden?
-
Sie erhalten einen besseren Einblick in den Zustand Ihres Amazon EKS-Clusters und können Probleme schnell diagnostizieren und beheben, ohne Zeit mit dem Debuggen oder dem Öffnen von AWS Supportanfragen verbringen zu müssen. Beispiel: Sie haben versehentlich ein Subnetz für den Amazon EKS-Cluster gelöscht, Amazon EKS kann keine kontoübergreifenden Netzwerkschnittstellen erstellen und Kubernetes AWS CLI-Befehle wie
kubectl
exec oderkubectl
logs. Bei diesen tritt folgender Fehler auf:Error from server: error dialing backend: remote error: tls: internal error.
Nun wird ein Amazon EKS-Integritätsproblem mit folgendem Hinweis angezeigt:subnet-da60e280 was deleted: could not create network interface
. - In welcher Beziehung steht diese Funktion zu anderen AWS Diensten oder funktioniert mit ihnen?
-
IAM-Rollen und Amazon VPC-Subnetze sind zwei Beispiele für erforderliche Infrastrukturkomponenten, für die die Cluster-Integritätsfunktion Probleme erkennt. Diese Funktion gibt detaillierte Informationen zurück, wenn diese Ressourcen nicht ordnungsgemäß konfiguriert sind.
- Fallen für einen Cluster mit Gesundheitsproblemen Gebühren an?
-
Ja. Jeder Amazon EKS-Cluster wird zu den Amazon EKS-Standardpreisen abgerechnet. Die Funktion Cluster-Integrität steht ohne Aufpreis zur Verfügung.
- Funktioniert diese Funktion mit Amazon EKS-Clustern auf AWS Outposts?
-
Ja, Clusterprobleme wurden für EKS-Cluster in der AWS Cloud erkannt, einschließlich erweiterter Cluster auf AWS Outposts und lokaler Cluster auf AWS Outposts. Der Clusterstatus erkennt keine Probleme mit Amazon EKS Anywhere oder Amazon EKS Distro (EKS-D).
- Kann ich benachrichtigt werden, wenn neue Probleme erkannt werden?
-
Ja. AWS sendet eine E-Mail und eine Benachrichtigung über das Personal Health Dashboard, wenn neue Probleme mit dem Clusterstatus erkannt werden.
- Erhalte ich von der Konsole Warnungen vor Gesundheitsproblemen?
-
Ja. Cluster mit Problemen verfügen über ein Banner im oberen Bereich der Konsole.
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.
Code | Fehlermeldung | ResourceIds | Cluster wiederherstellbar? |
---|---|---|---|
SUBNET_NOT_FOUND |
Wir konnten ein oder mehrere Subnetze nicht finden, die derzeit mit Ihrem Cluster verknüpft sind. Rufen Sie Amazon EKS an update-cluster-config API zur Aktualisierung von Subnetzen. |
Subnetz-IDs |
Ja |
SECURITY_GROUP_NOT_FOUND |
Wir konnten keine oder mehrere Sicherheitsgruppen finden, die derzeit mit Ihrem Cluster verknüpft sind. Rufen Sie die Amazon update-cluster-config EKS-API auf, um Sicherheitsgruppen zu aktualisieren |
Sicherheitsgruppen-IDs |
Ja |
IP_NOT_AVAILABLE |
One or more of the subnets associated with your cluster does not have enough available IP addresses for Amazon EKS to perform cluster management operations. Geben Sie Adressen in den Subnetzen frei oder ordnen Sie Ihrem Cluster mithilfe der Amazon update-cluster-config EKS-API verschiedene Subnetze zu. |
Subnetz-IDs |
Ja |
VPC_NOT_FOUND |
Wir konnten die mit Ihrem Cluster verknüpfte VPC nicht finden. You must delete and recreate your cluster. |
VPC-ID |
Nein |
ASSUME_ROLE_ACCESS_DENIED |
Ihr Cluster verwendet Amazon EKS nicht service-linked-role. Wir konnten die Ihrem Cluster zugeordnete Rolle nicht übernehmen, um die erforderlichen Amazon EKS-Verwaltungsvorgänge durchzuführen. Check the role exists and has the required trust policy. |
Die IAM-Rolle des Clusters |
Ja |
PERMISSION_ACCESS_DENIED |
Ihr Cluster verwendet Amazon EKS nicht service-linked-role. The role associated with your cluster does not grant sufficient permissions for Amazon EKS to perform required management operations. Check the policies attached to the cluster role and if any separate deny policies are applied. |
Die IAM-Rolle des Clusters |
Ja |
ASSUME_ROLE_ACCESS_DENIED_USING_SLR |
Wir konnten nicht von der Amazon EKS-Clusterverwaltung ausgehen service-linked-role. Check the role exists and has the required trust policy. |
Das Amazon EKS service-linked-role |
Ja |
PERMISSION_ACCESS_DENIED_USING_SLR |
Die Amazon EKS-Clusterverwaltung gewährt Amazon EKS service-linked-role nicht genügend Berechtigungen, um die erforderlichen Verwaltungsvorgänge durchzuführen. Check the policies attached to the cluster role and if any separate deny policies are applied. |
Das Amazon EKS service-linked-role |
Ja |
OPT_IN_REQUIRED |
Ihr Konto hat kein EC2 Amazon-Serviceabonnement. Update your account subscriptions in your account settings page. |
N/A |
Ja |
STS_REGIONAL_ENDPOINT_DISABLED |
Das Tool STS Der regionale Endpunkt ist deaktiviert. Enable the endpoint for Amazon EKS to perform required cluster management operations. |
N/A |
Ja |
KMS_KEY_DISABLED |
Der Ihrem Cluster zugeordnete AWS KMS-Schlüssel ist deaktiviert. Re-enable the key to recover your cluster. |
Das Tool KMS Key Arn |
Ja |
KMS_KEY_NOT_FOUND |
Wir konnten den mit Ihrem Cluster verknüpften AWS KMS-Schlüssel nicht finden. You must delete and recreate the cluster. |
Das Tool KMS Key ARN |
Nein |
KMS_GRANT_REVOKED |
Zuschüsse für den mit Ihrem Cluster verknüpften AWS KMS-Schlüssel wurden widerrufen. You must delete and recreate the cluster. |
Das Tool KMS Key Arn |
Nein |