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.
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 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 beim Versuch, einen Amazon-EKS-Cluster zu erstellen, der folgende Fehler auftritt, verfügt eine der angegebenen Availability Zones nicht über ausreichende Kapazität, um einen Cluster zu unterstützen.
Cannot create cluster 'example-cluster' because region-1d, the targeted
Availability Zone, does not currently have sufficient capacity to support the cluster. Retry
and choose from these Availability Zones: region-1a, region-1b, region-1c
Versuchen Sie erneut, den Cluster mit Subnetzen in Ihrer Cluster-VPC zu erstellen, die in den Availability Zones gehostet werden, die diesen Fehler verursacht haben.
Es gibt Availability Zones, in denen sich kein Cluster befinden darf. Vergleichen Sie die Availability Zones, in denen sich Ihre Subnetze befinden, mit der Liste der Availability Zones unter Subnetz-Anforderungen und -Überlegungen.
Knoten können nicht mit dem Cluster verknüpft werden
Es gibt zwei häufige Gründe, aus denen Knoten nicht mit dem Cluster verknüpft werden können:
-
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 Sie im folgenden Befehlmy-cluster
durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:eksctl get iamidentitymapping --cluster
. Der ARN der von Ihnen angegebenen Rolle darf als Pfad nurmy-cluster
/
enthalten. Wenn der Name Ihrer Rolle also beispielsweisedevelopment/apps/my-role
lautet, müssen Sie ihn bei Angabe des ARN für die Rolle inmy-role
ändern. Achten Sie darauf, den ARN der IAM-Rolle des Knotens (nicht den ARN des Instances-Profils) anzugeben.Wenn es sich um selbstverwaltete Knoten handelt und Sie keine Zugriffseinträge für den ARN der IAM-Rolle des Knotens erstellt haben, führen Sie die gleichen 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 Zulassen des Zugriffs auf Kubernetes-Objekte in Ihrem Amazon EKS-Cluster durch IAM-Rollen oder -Benutzer. -
Die ClusterName in Ihrer AWS CloudFormation Knotenvorlage stimmt nicht genau mit dem Namen des Clusters überein, dem Ihre Knoten beitreten sollen. 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
durch den Namen des Clusters ersetzt wird.my-cluster
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 AWS STS Endpunkt für die AWS-Region , auf 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 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 das Zustandsproblem „NodeCreationFailure“ ausgegeben und der Konsolenstatus wird auf gesetzt
Create failed
. Bei Windows AMIs mit langsamen Startzeiten kann dieses Problem mit dem Schnellstart 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 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 kubectl
nicht korrekt für Amazon EKS konfiguriert oder die Anmeldeinformationen für den von Ihnen verwendeten IAM-Prinzipal (Rolle oder Benutzer) sind keinem Kubernetes-Benutzernamen mit ausreichenden Berechtigungen für Kubernetes-Objekte in Ihrem Amazon EKS-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"
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 Erstellen oder Aktualisieren einer kubeconfig-Datei für einen Amazon-EKS-Cluster. -
Falls Ihr Cluster die Mindestanforderungen an die Plattform erfüllt, die unter Zulassen des Zugriffs auf Kubernetes-Objekte in Ihrem Amazon EKS-Cluster durch IAM-Rollen oder -Benutzer im Abschnitt mit den Voraussetzungen angegeben sind, ist kein Zugriffseintrag mit Ihrem IAM-Prinzipal vorhanden. Falls einer vorhanden ist, sind für ihn nicht die erforderlichen Kubernetes-Gruppennamen definiert oder ihm ist nicht die richtige Zugriffsrichtlinie zugeordnet. Weitere Informationen finden Sie unter Zulassen des Zugriffs auf Kubernetes-Objekte in Ihrem Amazon EKS-Cluster durch IAM-Rollen oder -Benutzer.
-
Falls Ihr Cluster die unter Zulassen des Zugriffs auf Kubernetes-Objekte in Ihrem Amazon EKS-Cluster durch IAM-Rollen oder -Benutzer angegebenen Mindestanforderungen an die Plattform nicht erfüllt, ist in
aws-auth
ConfigMap
kein Eintrag mit Ihrem IAM-Prinzipal vorhanden. Falls einer vorhanden ist, ist er keinen Kubernetes-Gruppennamen zugeordnet, die an ein Kubernetes-Element vom TypRole
oderClusterRole
mit den erforderlichen Berechtigungen gebunden sind. Weitere Informationen zu Kubernetes-Objekten für die rollenbasierte Autorisierung (RBAC) finden Sie in der Dokumentation zu Kubernetes unter Using RBAC Authorization. Sie können Ihre aktuellen aws-auth
ConfigMap
-Einträge anzeigen, indem Sie im folgenden Befehlmy-cluster
durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:eksctl get iamidentitymapping --cluster
. Wenn inmy-cluster
ConfigMap
kein Eintrag mit dem ARN Ihres IAM-Prinzipals enthalten ist, geben Sie in Ihrem Terminaleksctl create iamidentitymapping --help
ein, um zu erfahren, wie Sie einen solchen Eintrag erstellen.
Wenn Sie die installieren und konfigurieren AWS CLI, können Sie die von Ihnen verwendeten IAM-Anmeldeinformationen konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der AWS CLI im AWS Command Line Interface -Leitfaden. Sie können auch kubectl
für die Verwendung einer IAM-Rolle konfigurieren, wenn Sie für den Zugriff auf Kubernetes-Objekte in Ihrem Cluster eine IAM-Rolle annehmen. Weitere Informationen finden Sie unter Erstellen oder Aktualisieren einer kubeconfig-Datei für einen Amazon-EKS-Cluster.
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 von Amazon EKS. Weitere Informationen finden Sie auf der Seite mit häufig gestellten Fragen der Python Requests-Website unter What are “hostname doesn’t match” errors?
getsockopt: no route to
host
Docker wird im 172.17.0.0/16
-CIDR-Bereich in Amazon-EKS-Clustern ausgeführt. Wir empfehlen, dass die VPC-Subnetze Ihres Clusters diesen Bereich nicht überschneiden. Andernfalls erhalten Sie den folgenden Fehler:
Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host
Instances failed to join the Kubernetes
cluster
Wenn Sie die Fehlermeldung Instances failed to join the Kubernetes cluster
in der erhalten AWS Management Console, 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 mindestens einer 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
-
Mindestens eines der Subnetze, die Ihrer verwalteten Knotengruppe zugeordnet sind, verfügt 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ü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 AWS macht AMIs, die älter als 4 Monate sind, privat, wodurch sie nicht mehr zugänglich sind. Wenn Ihre verwaltete Knotengruppe ein privates Windows AMI verwendet, sollten Sie erwägen, Ihre Windows verwaltete Knotengruppe zu aktualisieren. Obwohl wir nicht garantieren können, dass wir Zugriff auf AMIs gewähren können, die privat gemacht wurden, können Sie den Zugriff beantragen, indem Sie ein Ticket beim - AWS Support einreichen. Weitere Informationen finden Sie unter Patches, Sicherheitsupdates und AMI-IDs im Amazon-EC2-Benutzerhandbuch für Windows-Instances.
Knoten befindet sich im -NotReady
Zustand
Wenn Ihr Knoten in den NotReady
Status wechselt, deutet dies wahrscheinlich darauf hin, dass der Knoten fehlerhaft ist und nicht in der Lage ist, neue zu planenPods. Dies kann aus verschiedenen Gründen auftreten, z. B. weil dem Knoten genügend Ressourcen für CPU, Arbeitsspeicher oder verfügbaren Speicherplatz fehlen.
Für Amazon-EKS-optimierte Windows AMIs gibt es keine Reservierung für Rechenressourcen, die standardmäßig in der
Konfiguration angegeben sind. Um Ressourcenprobleme zu vermeiden, können Sie Rechenressourcen für Systemprozesse reservieren, indem Sie die kubelet
mit Konfigurationswerten für kubelet
kube-reserved
system-reserved
-KubeletExtraArgs
Befehlszeilenparameter im Bootstrap-Skript. Weitere Informationen finden Sie unter Reservieren von Datenverarbeitungsressourcen für System-Daemons
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
Dieses Problem kann folgende Ursachen haben:
-
Für Ihren Cluster ist keine
aws-auth
ConfigMap
vorhanden oder sie enthält keine Einträge für die IAM-Rolle, mit der Sie Ihre Knoten konfiguriert haben.Dieser
ConfigMap
-Eintrag ist erforderlich, wenn Ihre Knoten eines der folgenden Kriterien erfüllen:-
Verwaltete Knoten in einem Cluster mit einer beliebigen Kubernetes- oder Plattformversion.
-
Selbstverwaltete Knoten in einem Cluster, der älter ist als eine der Plattformversionen, die im Abschnitt „Voraussetzungen“ des Themas Zulassen des Zugriffs auf Kubernetes-Objekte in Ihrem Amazon EKS-Cluster durch IAM-Rollen oder -Benutzer aufgeführt sind.
Sehen Sie sich zur Behebung des Problems die vorhandenen Einträge in
ConfigMap
an, indem Siemy-cluster
im folgenden Befehl durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:eksctl get iamidentitymapping --cluster
. Sollten Sie im Zusammenhang mit dem Befehl eine Fehlermeldung erhalten, verfügt Ihr Cluster möglicherweise nicht über einemy-cluster
aws-auth
ConfigMap
. Der folgende Befehl fügtConfigMap
einen Eintrag hinzu. IstConfigMap
nicht vorhanden, wird sie durch den Befehl erstellt. Ersetzen Sie111122223333
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 von Ihnen angegebenen Rolle darf als Pfad nur
/
enthalten. Wenn der Name Ihrer Rolle also beispielsweisedevelopment/apps/my-role
lautet, müssen Sie ihn beim Angeben des ARN der Rolle inmy-role
ä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, die die Mindestversionsanforderung erfüllt, die unter „Voraussetzungen“ des Themas Zulassen des Zugriffs auf Kubernetes-Objekte in Ihrem Amazon EKS-Cluster durch IAM-Rollen oder -Benutzer angegeben ist. Aber
aws-auth
ConfigMap
enthält keinen Eintrag für die IAM-Rolle des Knotens (siehe vorheriger Punkt) oder es ist kein Zugriffseintrag für die Rolle vorhanden. Sehen Sie sich zur Behebung des Problems Ihre vorhandenen Zugriffseinträge an, indem Siemy-cluster
im 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. Ersetzen Siemy-cluster
111122223333
durch die AWS-Konto ID für die IAM-Rolle undmyAmazonEKSNodeRole
durch den Namen der Rolle Ihres Knotens. Ersetzen Sie im Falle eines Windows-KnotensEC2_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
--typeEC2_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 Servicekonten für ein oder verwenden AWS-Region, das auf einem Cluster in einem China Pod DaemonSet
bereitgestellt wird, und die AWS_DEFAULT_REGION
Umgebungsvariable in der Spezifikation nicht festgelegt haben, wird das Pod oder 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 der Kubernetes-Version entsprechen, bevor ein Upgrade der Steuerebene durchgeführt wird
Bevor Sie für eine Steuerebene ein Upgrade auf eine neue Kubernetes-Version durchführen, muss die Nebenversion der verwalteten Knoten und der Fargate-Knoten in Ihrem Cluster der aktuellen Version Ihrer Steuerebene entsprechen. 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 stellt APIs zum Upgraden verwalteter Knoten bereit. Informationen zum Upgraden der Kubernetes-Version einer verwalteten Knotengruppe finden Sie unter Aktualisieren einer verwalteten Knotengruppe. Löschen Sie zum Upgraden der Version eines Fargate-Knotens den pod, der durch den Knoten dargestellt wird, und stellen Sie den pod erneut bereit, nachdem Sie das Upgrade für Ihre Steuerebene durchgeführt haben. Weitere Informationen finden Sie unter 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 Bootstrap-Skript des Knotens übergeben werden. Wenn Sie diese Argumente einschließen, muss das Bootstrap-Skript keinen describeCluster
-Aufruf ausführen, wodurch verhindert wird, dass die Steuerebene überlastet wird. Weitere Informationen finden Sie unter 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 Pods auf einem Cluster abgelaufen ist.
Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters lehnt Anfragen mit Tokens ab, die älter als 90 Tage sind. In früheren Kubernetes-Versionen hatten Token kein Ablaufdatum. Clients, die diese Tokens verwenden, müssen die Tokens nun innerhalb einer Stunde aktualisieren. Um zu verhindern, dass der Kubernetes-API-Server Ihre Anfrage aufgrund eines ungültigen Tokens ablehnt, muss die von Ihrem Workload verwendete Kubernetes-Client-SDK-Version
Go-Version
0.15.7
und höherPython-Version
12.0.0
und höherJava-Version
9.0.0
und höherJavaScript -Version
0.10.3
und höherRuby
master
-BranchHaskell-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 Ihr Cluster von einem dieser Probleme betroffen ist, funktioniert er möglicherweise immer noch, aber seine Plattformversion wird nicht von Amazon EKS aktualisiert.
Problem
Die Cluster-IAM-Rolle wurde gelöscht – Diese Rolle wurde beim Erstellen des Clusters angegeben. Sie können mit dem folgenden Befehl überprüfen, welche Rolle angegeben wurde. Ersetzen Sie my-cluster
durch den 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
durch den 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 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"
Eine Beispielausgabe sieht wie folgt aus.
[ "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 die vom Cluster verwendeten Subnetze ändern, 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.
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
Eine Beispielausgabe sieht wie folgt aus.
[
"sg-EXAMPLE1
"
]
Wenn []
zurückgegeben wird, wurden beim Erstellen des Clusters keine Sicherheitsgruppen angegeben und eine fehlende Sicherheitsgruppe ist nicht das Problem. Wenn Sicherheitsgruppen zurückgegeben werden, vergewissern Sie sich, dass die Sicherheitsgruppen in Ihrem Konto vorhanden sind.
Lösung
Bestätigen Sie, ob diese Sicherheitsgruppen in Ihrem Konto vorhanden sind.
vpc_id=$(aws eks describe-cluster --name
my-cluster
--query cluster.resourcesVpcConfig.vpcId --output text) aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"
Eine Beispielausgabe sieht wie folgt aus.
[
"sg-EXAMPLE2
"
]
Wenn die in der Ausgabe zurückgegebenen Sicherheitsgruppen-IDs nicht mit den Sicherheitsgruppen-IDs übereinstimmen, die bei der Erstellung des Clusters angegeben wurden, müssen Sie die vom Cluster verwendeten Sicherheitsgruppen ändern, 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.
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 die vom Cluster verwendeten Subnetze ändern, um Subnetze mit genügend verfügbaren IP-Adressen zu verwenden.
-
Sie haben die Secrets-Verschlüsselung 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
Häufig FAQs und Fehlercodes zum Cluster-Zustand mit Auflö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 sind up-to-date. Darüber hinaus kann es aufgrund von Problemen mit der erforderlichen Infrastruktur- oder Clusterkonfiguration sein, dass Sie kein Upgrade auf neuere Versionen von Kubernetes durchführen können oder dass Amazon EKS keine Sicherheitsupdates auf einem beeinträchtigten Cluster installieren kann. Es kann drei Stunden dauern, bis Amazon EKS Probleme erkennt oder feststellt, dass ein Problem behoben wurde.
Amazon EKS und die Benutzer sind gemeinsam für die Integrität eines Amazon EKS-Clusters verantwortlich. Sie selbst sind für die erforderliche Infrastruktur von IAM-Rollen und Amazon VPC-Subnetzen sowie für andere notwendige Infrastrukturkomponenten verantwortlich, die im Voraus bereitgestellt werden müssen. Amazon EKS erkennt Änderungen an der Konfiguration dieser Infrastruktur und des Clusters.
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 Sie die Aktion DescribeCluster
der EKS-API aufrufen (beispielsweise innerhalb der AWS Command Line Interface).
- Warum sollte ich diese Funktion verwenden?
-
Sie erhalten einen besseren Überblick über den Zustand Ihres Amazon-EKS-Clusters, diagnostizieren und beheben Probleme schnell, ohne Zeit für das Debuggen oder Öffnen von AWS Support-Fällen aufwenden zu müssen. Beispiel: Sie haben versehentlich ein Subnetz für den Amazon-EKS-Cluster gelöscht, Amazon EKS kann keine kontoübergreifenden Netzwerkschnittstellen und Kubernetes AWS CLI Befehle wie
kubectl
exec oderkubectl
logs erstellen. 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
. - Wie ist diese Funktion mit anderen - AWS Services verknüpft oder funktioniert sie?
-
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 Cluster mit Integritätsproblemen 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.
- Kann diese Funktion mit Amazon EKS-Clustern in AWS Outposts verwendet werden?
-
Ja, Clusterprobleme werden für EKS-Cluster in der AWS Cloud erkannt, einschließlich erweiterter Cluster in AWS Outposts und lokaler Cluster in AWS Outposts. Die Cluster-Integritätsfunktion erkennt keine Probleme mit Amazon EKS Anywhere oder Amazon EKS Distro (EKS-D).
- Kann ich benachrichtigt werden, wenn neue Probleme erkannt werden?
-
Nein. Sie müssen die Amazon EKS-Konsole überprüfen oder die EKS-API
DescribeCluster
aufrufen. - Werden in der Konsole Warnungen im Zusammenhang mit Integritätsproblemen ausgegeben?
-
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 Health- ClusterIssueObjekts ist resourceIds, dessen Rückgabe vom Problemtyp abhängt.
Code | Fehlermeldung | ResourceIds | Cluster wiederherstellbar? |
---|---|---|---|
SUBNET_NOT_FOUND |
We couldn't find one or more subnets currently associated with your cluster. Call Amazon EKS update-cluster-config API to update subnets. |
Subnetz-IDs | Ja |
SECURITY_GROUP_NOT_FOUND | We couldn't find one or more security groups currently associated with your cluster. Rufen Sie die Amazon-EKS update-cluster-config -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 dem/den Subnetz(en) frei oder ordnen Sie Ihrem Cluster mithilfe der Amazon-EKS update-cluster-config-API verschiedene Subnetze zu. | Subnetz-IDs | Ja |
VPC_NOT_FOUND | We couldn't find the VPC associated with your cluster. You must delete and recreate your cluster. | VPC-ID | Nein |
ASSUME_ROLE_ACCESS_DENIED | Ihr Cluster verwendet nicht Amazon EKS service-linked-role. We couldn't assume the role associated with your cluster to perform required Amazon EKS management operations. Check the role exists and has the required trust policy. | Die IAM-Rolle des Clusters | Ja |
PERMISSION_ACCESS_DENIED |
Ihr Cluster verwendet nicht Amazon EKS 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 die Amazon-EKS-Clusterverwaltung nicht übernehmen service-linked-role. Check the role exists and has the required trust policy. | Amazon EKS service-linked-role | Ja |
PERMISSION_ACCESS_DENIED_USING_SLR |
Die Amazon-EKS-Clusterverwaltung gewährt Amazon EKS service-linked-role keine ausreichenden Berechtigungen, um die erforderlichen Verwaltungsvorgänge auszuführen. Check the policies attached to the cluster role and if any separate deny policies are applied. |
Amazon EKS service-linked-role |
Ja |
OPT_IN_REQUIRED |
Your account doesn't have an Amazon EC2 service subscription. Update your account subscriptions in your account settings page. |
N/A | Ja |
STS_REGIONAL_ENDPOINT_DISABLED |
The STS regional endpoint is disabled. Enable the endpoint for Amazon EKS to perform required cluster management operations. |
N/A | Ja |
KMS_KEY_DISABLED |
Der Schlüssel, der Ihrem Cluster AWS KMS zugeordnet ist, ist deaktiviert. Re-enable the key to recover your cluster. |
Die KMS Key Arn |
Ja |
KMS_KEY_NOT_FOUND |
Der Schlüssel, der Ihrem Cluster AWS KMS zugeordnet ist, konnte nicht gefunden werden. You must delete and recreate the cluster. |
Die KMS Key ARN |
Nein |
KMS_GRANT_REVOKED |
Erteilungen für den AWS KMS Schlüssel, der Ihrem Cluster zugeordnet ist, werden widerrufen. You must delete and recreate the cluster. |
Die KMS Key Arn |
Nein |