Problembehandlung bei lokalen Clustern für Amazon EKS auf AWS Outposts - Amazon EKS

Helfen Sie mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle 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.

Problembehandlung bei lokalen Clustern für Amazon EKS auf AWS Outposts

In diesem Thema werden einige häufige Fehler behandelt, die bei der Verwendung lokaler Cluster auftreten können, und wie Sie diese beheben können. Lokale Cluster ähneln Amazon-EKS-Clustern in der Cloud, es gibt jedoch einige Unterschiede in der Art und Weise, wie sie von Amazon EKS verwaltet werden.

Lokale Cluster werden über die Amazon-EKS-API erstellt, aber asynchron ausgeführt. Dies bedeutet, dass Anforderungen an die Amazon-EKS-API für lokale Cluster sofort zurückgegeben werden. Diese Anforderungen können jedoch erfolgreich sein, aufgrund von Eingabevalidierungsfehlern schnell scheitern oder fehlschlagen und beschreibende Validierungsfehler aufweisen. Dieses Verhalten entspricht dem der Kubernetes-API.

Lokale Cluster wechseln nicht in einen FAILED-Status. Amazon EKS versucht, den Cluster-Status kontinuierlich mit dem vom Benutzer angeforderten gewünschten Status abzugleichen. Infolgedessen kann ein lokaler Cluster für längere Zeit im CREATING-Status verbleiben, bis das zugrunde liegende Problem behoben ist.

Probleme mit lokalen Clustern können mit dem describe-cluster Amazon EKS AWS CLI-Befehl erkannt werden. Probleme mit lokalen Clustern werden durch das cluster.health-Feld der Antwort des describe-cluster-Befehls angezeigt. Die in diesem Feld enthaltene Meldung enthält einen Fehlercode, eine beschreibende Meldung und zugehörige Ressourcen-IDs. Diese Informationen sind nur über die Amazon-EKS-API und AWS CLI verfügbar. Ersetzen Sie im folgenden Beispiel my-cluster durch den Namen Ihres lokalen Clusters.

aws eks describe-cluster --name my-cluster --query 'cluster.health'

Eine Beispielausgabe sieht wie folgt aus.

{
    "issues": [
        {
            "code": "ConfigurationConflict",
            "message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.",
            "resourceIds": [
                "my-cluster-arn"
            ]
        }
    ]
}

Wenn das Problem nicht behoben werden kann, müssen Sie möglicherweise den lokalen Cluster löschen und einen neuen erstellen. Versuchen Sie beispielsweise, einen Cluster mit einem Instance-Typ bereitzustellen, der auf Ihrem Outpost nicht verfügbar ist. Die folgende Tabelle enthält allgemeine Fehler im Zusammenhang mit der Integrität.

Fehlerszenario Code Fehlermeldung ResourceIds

Die bereitgestellten Subnetze konnten nicht gefunden werden.

ResourceNotFound

The subnet ID subnet-id does not exist

 Alle bereitgestellten Subnetz-IDs

Bereitgestellte Subnetze gehören nicht zur selben VPC.

ConfigurationConflict

Subnets specified must belong to the same VPC

 Alle bereitgestellten Subnetz-IDs

Einige bereitgestellte Subnetze gehören nicht zum angegebenen Outpost.

ConfigurationConflict

Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn

 Problematische Subnetz-ID

Einige bereitgestellte Subnetze gehören zu keinem Outpost.

ConfigurationConflict

Subnet subnet-id is not part of any Outpost

 Problematische Subnetz-ID

Einige bereitgestellte Subnetze verfügen nicht über genügend freie Adressen, um elastische Netzwerkschnittstellen für Instances der Steuerebene zu erstellen.

ResourceLimitExceeded

The specified subnet does not have enough free addresses to satisfy the request.

 Problematische Subnetz-ID

Der angegebene Instance-Typ der Steuerebene wird von Ihrem Outpost nicht unterstützt.

ConfigurationConflict

The instance type type is not supported in Outpost outpost-arn

 Cluster-ARN
Sie haben eine Amazon-EC2-Instance auf der Steuerebene beendet oder run-instance war erfolgreich, aber der beobachtete Status ändert sich zu Terminated. Dies kann für einen bestimmten Zeitraum passieren, nachdem Ihr Outpost die Verbindung wieder hergestellt hat und interne Fehler von Amazon EBS dazu führen, dass ein interner Amazon-EC2-Workflow fehlschlägt.

InternalFailure

EC2 instance state "Terminated" is unexpected

 Cluster-ARN

Sie verfügen über unzureichende Kapazität auf Ihrem Outpost. Dies kann auch bei der Erstellung eines Clusters passieren, wenn ein Outpost vom AWS-Region getrennt wird.

ResourceLimitExceeded

There is not enough capacity on the Outpost to launch or start the instance.

 Cluster-ARN
Ihr Konto hat das Kontingent Ihrer Sicherheitsgruppe überschritten.

ResourceLimitExceeded

 Von Amazon-EC2-API zurückgegebene Fehlermeldung Ziel-VPC-ID
Ihr Konto hat Ihr Kontingent für die elastische Netzwerkschnittstelle überschritten.

ResourceLimitExceeded

 Von Amazon-EC2-API zurückgegebene Fehlermeldung Ziel-Subnetz-ID

Instances der Steuerebene konnten nicht über AWS Systems Manager erreicht werden. Informationen zur Lösung finden Sie unter Instances der Steuerebene sind nicht über AWS Systems Manager erreichbar.

ClusterUnreachable

Amazon-EKS-Steuerebene-Instances sind nicht über SSM erreichbar. Bitte überprüfen Sie Ihre SSM- und Netzwerkkonfiguration und lesen Sie die Dokumentation zur Fehlerbehebung bei EKS on Outposts.

 Amazon-EC2-Instance-IDs
Beim Abrufen von Details für eine verwaltete Sicherheitsgruppe oder eine elastische Netzwerkschnittstelle ist ein Fehler aufgetreten.

Basierend auf dem Amazon-EC2-Client-Fehlercode.

 Von Amazon-EC2-API zurückgegebene Fehlermeldung Alle verwalteten Sicherheitsgruppen-IDs
Beim Autorisieren oder Widerrufen von Eingangsregeln für Sicherheitsgruppen ist ein Fehler aufgetreten. Dies gilt sowohl für die Sicherheitsgruppen des Clusters als auch der Steuerebene. Basierend auf dem Amazon-EC2-Client-Fehlercode. Von Amazon-EC2-API zurückgegebene Fehlermeldung Problematische Sicherheitsgruppen-ID
Beim Löschen einer elastischen Netzwerkschnittstelle für eine Instance der Steuerebene ist ein Fehler aufgetreten. Basierend auf dem Amazon-EC2-Client-Fehlercode. Von Amazon-EC2-API zurückgegebene Fehlermeldung Problematische ID der Elastic-Network-Schnittstelle

In der folgenden Tabelle sind Fehler von anderen AWS-Services aufgeführt, die im Integritätsfeld der describe-cluster-Antwort angezeigt werden.

Amazon-EC2-Fehlercode Code für Cluster-Integritätsprobleme Beschreibung

AuthFailure

AccessDenied

 Dieser Fehler kann aus einer Vielzahl von Gründen auftreten. Der häufigste Grund ist, dass Sie versehentlich ein Tag entfernt haben, das der Service verwendet, um die Richtlinie für die mit dem Service verknüpfte Rolle von der Steuerebene herabzustufen. Wenn dies auftritt, kann Amazon EKS diese AWS-Ressourcen nicht mehr verwalten und überwachen.

UnauthorizedOperation

AccessDenied

 Dieser Fehler kann aus einer Vielzahl von Gründen auftreten. Der häufigste Grund ist, dass Sie versehentlich ein Tag entfernt haben, das der Service verwendet, um die Richtlinie für die mit dem Service verknüpfte Rolle von der Steuerebene herabzustufen. Wenn dies auftritt, kann Amazon EKS diese AWS-Ressourcen nicht mehr verwalten und überwachen.

InvalidSubnetID.NotFound

ResourceNotFound

Dieser Fehler tritt auf, wenn die Subnetz-ID für die Eingangsregeln einer Sicherheitsgruppe nicht gefunden werden kann.

InvalidPermission.NotFound

ResourceNotFound

 Dieser Fehler tritt auf, wenn die Berechtigungen für die Eingangsregeln einer Sicherheitsgruppe nicht korrekt sind.

InvalidGroup.NotFound

ResourceNotFound

 Dieser Fehler tritt auf, wenn die Gruppe der Eingangsregeln einer Sicherheitsgruppe nicht gefunden werden kann.

InvalidNetworkInterfaceID.NotFound

ResourceNotFound

 Dieser Fehler tritt auf, wenn die Netzwerkschnittstellen-ID für die Eingangsregeln einer Sicherheitsgruppe nicht gefunden werden kann.

InsufficientFreeAddressesInSubnet

ResourceLimitExceeded

 Dieser Fehler tritt auf, wenn das Kontingent der Subnetzressourcen überschritten wird.

InsufficientCapacityOnOutpost

ResourceLimitExceeded

 Dieser Fehler tritt auf, wenn das Kapazitätskontingent des Außenpostens überschritten wird.

NetworkInterfaceLimitExceeded

ResourceLimitExceeded

Dieser Fehler tritt auf, wenn das Kontingent der elastischen Netzwerkschnittstelle überschritten wird.

SecurityGroupLimitExceeded

ResourceLimitExceeded

 Dieser Fehler tritt auf, wenn das Kontingent der Sicherheitsgruppe überschritten wird.

VcpuLimitExceeded

ResourceLimitExceeded

 Dies wird beim Erstellen einer Amazon-EC2-Instance in einem neuen Konto beobachtet. Die Fehlermeldung könnte ähnlich wie die folgende lauten: „You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."

InvalidParameterValue

ConfigurationConflict

Amazon EC2 gibt diesen Fehlercode zurück, wenn der angegebene Instance-Typ auf dem Outpost nicht unterstützt wird.
Alle anderen Fehler

InternalFailure

 None

Lokale Cluster erfordern andere Berechtigungen und Richtlinien als Amazon-EKS-Cluster, die in der Cloud gehostet werden. Wenn ein Cluster nicht erstellt werden kann und einen InvalidPermissions Fehler erzeugt, überprüfen Sie erneut, ob der von Ihnen verwendeten Clusterrolle die von AmazonEKSLocalOutpostClusterPolicy verwaltete Richtlinie zugeordnet ist. Alle anderen API-Aufrufe erfordern dieselben Berechtigungen wie Amazon-EKS-Cluster in der Cloud.

Die Zeit, die zum Erstellen eines lokalen Clusters benötigt wird, hängt von mehreren Faktoren ab. Zu diesen Faktoren gehören Ihre Netzwerkkonfiguration, die Outpost-Konfiguration und die Konfiguration des Clusters. Im Allgemeinen wird ein lokaler Cluster erstellt und wechselt innerhalb von 15–20 Minuten in den ACTIVE-Status. Wenn ein lokaler Cluster im CREATING-Status bleibt, können Sie describe-clusteraufrufen, um Informationen über die Ursache im cluster.health-Ausgabefeld abzurufen.

Die am häufigsten auftretenden Probleme sind:

AWS Systems Manager (Systems Manager) stößt auf die folgenden Probleme:

  • Ihr Cluster kann von dem AWS-Region, in dem sich Systems Manager befindet, keine Verbindung zur Instance der Steuerebene herstellen. Sie können dies überprüfen, indem Sie aws ssm start-session --target instance-id von einem Bastion-Host in der Region aufrufen. Wenn dieser Befehl nicht funktioniert, überprüfen Sie, ob Systems Manager auf der Instance der Steuerebene ausgeführt wird. Eine andere Möglichkeit besteht darin, den Cluster zu löschen und ihn dann neu zu erstellen.

  • Instances auf der Steuerebene von Systems Manager haben möglicherweise keinen Zugriff auf das Internet. Überprüfen Sie, ob das Subnetz, das Sie beim Erstellen des Clusters angegeben haben, über ein NAT-Gateway und eine VPC mit einem Internet-Gateway verfügt. Verwenden Sie VPC Reachability Analyzer, um zu überprüfen, ob die Instance der Steuerebene das Internet-Gateway erreichen kann. Weitere Informationen finden Sie unter Erste Schritte mit VPC Reachability Analyzer.

  • Der von Ihnen angegebene Rollen-ARN enthält keine Richtlinien. Überprüfen Sie, ob das AWS verwaltete Richtlinie: AmazonEKS LocalOutpostClusterPolicy aus der Rolle entfernt wurde. Dies kann auch auftreten, wenn ein AWS CloudFormation-Stack falsch konfiguriert ist.

Beim Erstellen eines Clusters werden mehrere Subnetze falsch konfiguriert und angegeben:

  • Alle bereitgestellten Subnetze müssen demselben Outpost zugeordnet sein und sich gegenseitig erreichen. Wenn beim Erstellen eines Clusters mehrere Subnetze angegeben werden, versucht Amazon EKS, die Instances der Steuerebene auf mehrere Subnetze zu verteilen.

  • Amazon-EKS-verwaltete Sicherheitsgruppen werden auf die Elastic-Network-Schnittstelle angewendet. Andere Konfigurationselemente wie NACL-Firewall-Regeln könnten jedoch mit den Regeln für die elastische Netzwerkschnittstelle in Konflikt geraten.

VPC- und Subnetz-DNS-Konfiguration ist falsch konfiguriert oder fehlt

Sehen Sie sich Amazon EKS lokale Cluster-VPC- und Subnetz-Anforderungen und -Überlegungen an.

Häufige Ursachen:

  • AMI-Probleme:

    • Sie verwenden ein nicht unterstütztes AMI. Sie müssen v20220620 oder höher für das Amazon EKS-optimierte Amazon Linux-AMIs Amazon EKS optimierte Amazon Linux verwenden.

    • Wenn Sie eine AWS CloudFormation-Vorlage zum Erstellen Ihrer Knoten verwendet haben, stellen Sie sicher, dass kein nicht unterstütztes AMI verwendet wurde.

  • AWS IAM Authenticator ConfigMap fehlt – Wenn es fehlt, müssen Sie es erstellen. Weitere Informationen finden Sie unter Anwenden von aws-authConfigMap auf Ihren Cluster.

  • Die falsche Sicherheitsgruppe wird verwendet – Stellen Sie sicher, dass Sie eks-cluster-sg-cluster-name-uniqueid für die Sicherheitsgruppe Ihrer Worker-Knoten verwenden. Die ausgewählte Sicherheitsgruppe wird durch AWS CloudFormation geändert, um bei jeder Verwendung des Stacks eine neue Sicherheitsgruppe zuzulassen.

  • Unerwartete VPC-Schritte für private Links – Falsche CA-Daten (--b64-cluster-ca) oder API-Endpunkt (--apiserver-endpoint) sind bestanden.

  • Fehlkonfigurierte Pod-Sicherheitsrichtlinie:

    • Die CoreDNS- und Amazon VPC CNI plugin for Kubernetes-Daemonsets müssen auf Knoten ausgeführt werden, damit Knoten dem Cluster beitreten und mit ihm kommunizieren können.

    • Das Amazon VPC CNI plugin for Kubernetes erfordert einige privilegierte Netzwerkfeatures, um ordnungsgemäß zu funktionieren. Sie können die privilegierten Netzwerkfeatures mit dem folgenden Befehl anzeigen: kubectl describe psp eks.privileged.

    Wir empfehlen nicht, die standardmäßige Richtlinie für die Pod-Sicherheit zu ändern. Weitere Informationen finden Sie unter Pod-Sicherheitsrichtlinie.

Wenn ein Außenposten von dem AWS-Region getrennt wird, dem er zugeordnet ist, funktioniert der Kubernetes-Cluster wahrscheinlich weiterhin normal. Wenn der Cluster jedoch nicht richtig funktioniert, befolgen Sie die Schritte zur Fehlerbehebung unter Vorbereitungen für Netzwerkunterbrechungen. Wenn Sie auf andere Probleme stoßen, wenden Sie sich an AWS Support. AWS Support kann Sie beim Herunterladen und Ausführen eines Tools zur Protokollerfassung unterstützen. Auf diese Weise können Sie Protokolle von den Steuerebenen-Instances Ihres Kubernetes-Clusters erfassen und zur weiteren Untersuchung an den AWS Support-Support senden.

Wenn die Amazon-EKS-Steuerebene-Instances nicht über AWS Systems Manager (Systems Manager) erreichbar sind, zeigt Amazon EKS den folgenden Fehler für Ihren Cluster an.

Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.

Um dieses Problem zu lösen, stellen Sie sicher, dass Ihre VPC und Subnetze die Anforderungen in Amazon EKS lokale Cluster-VPC- und Subnetz-Anforderungen und -Überlegungen erfüllen und dass Sie die Schritte in Einrichten von Session Manager im AWS Systems Manager-Benutzerhandbuch abgeschlossen haben.