**Unterstützung für die Verbesserung dieser Seite beitragen** 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. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub ** Link Diese Seite ** bearbeiten unter, der sich im rechten Bereich jeder Seite befindet. 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 Amazon EKS-Clustern 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. **Wichtig** Beenden Sie niemals eine verwaltete lokale `Kubernetes` EKS-Cluster-Steuerungsebenen-Instance, die auf Outpost ausgeführt wird, es sei denn, Sie werden ausdrücklich vom Support dazu aufgefordert. AWS Das Beenden dieser Instanzen birgt ein Risiko für die Verfügbarkeit des lokalen Clusterdienstes, einschließlich des Verlusts des lokalen Clusters, falls mehrere Instanzen gleichzeitig beendet werden. Lokale EKS-Cluster in `Kubernetes`-Steuerebenen-Instances werden auf der EC2-Instance-Konsole durch das Tag `eks-local:controlplane-name` identifiziert. ## API-Verhalten 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 ähnelt 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. ## Beschreibung des Bereichs Cluster-Integrität Lokale Cluster-Probleme können mit dem [ Amazon EKS-CLI-Befehl ](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) describe-cluster erkannt werden. AWS 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 in 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 passieren, wenn ein Cluster erstellt wird, wenn ein Außenposten von der 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 | | Instanzen der Kontrollebene waren über den AWS Systems Manager nicht erreichbar. Informationen zur Lösung finden Sie unter [Instanzen der Kontrollebene sind nicht erreichbar über AWS Systems Manager](#outposts-troubleshooting-control-plane-instances-ssm). | `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 anderer AWS Dienste aufgeführt, die im Feld „Health“ der `describe-cluster` Antwort angezeigt werden. | Amazon-EC2-Fehlercode | Code für Cluster-Integritätsprobleme | Description | | --- | --- | --- | | `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. In diesem Fall 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. In diesem Fall 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 in dem Outpost nicht unterstützt wird. | | Alle anderen Fehler | `InternalFailure` | Keine | ## Cluster können nicht erstellt oder geändert werden 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 ein `InvalidPermissions` Fehler auftritt, überprüfen Sie noch einmal, ob die von Ihnen verwendete Cluster-Rolle mit der [ AmazonEKSLocalOutpostClusterPolicy ](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) verwalteten Richtlinie verknüpft ist. Alle anderen API-Aufrufe erfordern dieselben Berechtigungen wie Amazon-EKS-Cluster in der Cloud. ## Der Cluster steckt im `Status` CREATING fest 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-cluster`aufrufen, um Informationen über die Ursache im `cluster.health`-Ausgabefeld abzurufen. Die am häufigsten auftretenden Probleme sind: + Ihr Cluster kann keine Verbindung zur Control Plane-Instance aus der AWS Region herstellen, in der sich Systems Manager befindet. 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 Problemumgehung besteht darin, den Cluster zu löschen und ihn dann neu zu erstellen. + Die Steuerebenen-Instances können aufgrund von KMS-Schlüsselberechtigungen für EBS-Volumes nicht erstellt werden. Bei benutzerverwalteten KMS-Schlüsseln für verschlüsselte EBS-Volumes werden die Steuerebenen-Instances beendet, wenn auf den Schlüssel nicht zugegriffen werden kann. Wenn die Instanzen beendet werden, wechseln Sie entweder zu einem AWS verwalteten KMS-Schlüssel oder stellen Sie sicher, dass Ihre benutzerverwaltete Schlüsselrichtlinie die erforderlichen Berechtigungen für die Clusterrolle gewährt. + 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](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html). + Der von Ihnen angegebene Rollen-ARN enthält keine Richtlinien. Prüfen Sie, ob die [AWS verwaltete Richtlinie: aus der Rolle entfernt AmazonEKSLocalOutpostClusterPolicy ](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) wurde. Dies kann auch passieren, wenn ein AWS CloudFormation Stack falsch konfiguriert ist. + 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. + Die VPC- und Subnetz-DNS-Konfiguration ist falsch konfiguriert oder fehlt. Weitere Informationen finden [ Sie unter Erstellen einer VPC und Subnetze für Amazon EKS-Cluster auf Outposts. AWS](eks-outposts-vpc-subnet-requirements.md) ## Der Cluster steckt im UPDATING-Status fest `` Amazon EKS aktualisiert automatisch alle vorhandenen lokalen Cluster auf die neuesten Plattformversionen für die entsprechende Kubernetes- Nebenversion. Weitere Informationen zu Plattformversionen finden Sie unter [Erfahren Sie mehr über die Plattformversionen von Kubernetes und Amazon EKS für AWS Outposts](eks-outposts-platform-versions.md). Während einer automatischen Einführung der Plattformversion ändert sich der Cluster-Status zu `UPDATING`. Der Aktualisierungsprozess besteht darin, alle Kubernetes-Instanzen auf Steuerungsebene durch neue Instanzen zu ersetzen, die die neuesten Sicherheitspatches und Bugfixes enthalten, die für die jeweilige Kubernetes-Nebenversion veröffentlicht wurden. Im Allgemeinen dauert ein Aktualisierungsprozess der lokalen Cluster-Plattform weniger als 30 Minuten, und der Cluster kehrt anschließend in den `ACTIVE`-Status zurück Wenn ein lokaler Cluster über einen längeren Zeitraum in diesem `UPDATING`-Status verbleibt, können Sie `describe-cluster` aufrufen, um im `cluster.health`-Ausgabefeld nach Informationen zur Ursache zu suchen. Amazon EKS stellt sicher, dass mindestens 2 von 3 Kubernetes-Steuerebenen-Instances fehlerfrei und betriebsbereit sind, um die lokale Cluster-Verfügbarkeit aufrechtzuerhalten und Service-Unterbrechungen zu vermeiden. Wenn ein lokaler Cluster im `UPDATING`-Status hängen bleibt, liegt dies normalerweise daran, dass ein Infrastruktur- oder Konfigurationsproblem vorliegt, das die Gewährleistung der Mindestverfügbarkeit von zwei Instances verhindert, falls der Prozess fortgesetzt wird. Der Aktualisierungsprozess schreitet also nicht mehr voran, um eine Unterbrechung des lokalen Clusterdienstes zu verhindern. Es ist wichtig, einen lokalen Cluster, der in einem `UPDATING`-Status hängen geblieben ist, zu überprüfen und die Ursache zu beheben. So kann der Aktualisierungsprozess abgeschlossen und der lokale Cluster mit der hohen Verfügbarkeit von drei Kubernetes-Steuerebenen-Instances zurück in `ACTIVE` wiederhergestellt werden. Beenden Sie keine verwalteten lokalen `Kubernetes` EKS-Clusterinstanzen auf Outposts, sofern Sie nicht ausdrücklich vom Support dazu aufgefordert werden. AWS Dies ist besonders wichtig für lokale Cluster, die im `UPDATING` Status feststecken, da die Wahrscheinlichkeit hoch ist, dass ein anderer Knoten auf der Steuerungsebene nicht vollständig funktionsfähig ist und das Beenden der falschen Instance zu einer Dienstunterbrechung führen kann und das Risiko eines Datenverlusts im lokalen Cluster besteht. Die am häufigsten auftretenden Probleme sind: + Eine oder mehrere Instanzen der Steuerungsebene können aufgrund einer Änderung der Netzwerkkonfiguration seit der ersten Erstellung des lokalen Clusters keine Verbindung zu Systems Manager 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. + Neue Steuerebenen-Instances können aufgrund von KMS-Schlüsselberechtigungen für EBS-Volumes nicht erstellt werden. Bei benutzerverwalteten KMS-Schlüsseln für verschlüsselte EBS-Volumes werden die Steuerebenen-Instances beendet, wenn auf den Schlüssel nicht zugegriffen werden kann. Wenn die Instanzen beendet werden, wechseln Sie entweder zu einem AWS verwalteten KMS-Schlüssel oder stellen Sie sicher, dass Ihre benutzerverwaltete Schlüsselrichtlinie die erforderlichen Berechtigungen für die Clusterrolle gewährt. + Instances auf der Steuerebene von Systems Manager haben möglicherweise den Zugriff auf das Internet verloren. Ü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](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html). Wenn Ihre privaten Netzwerke über keine ausgehende Internetverbindung verfügen, stellen Sie sicher, dass alle erforderlichen VPC-Endpunkte und Gateway-Endpunkte weiterhin im regionalen Subnetz Ihres Clusters vorhanden sind (siehe [Subnetzzugriff auf AWS service](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)). + Der von Ihnen angegebene Rollen-ARN enthält keine Richtlinien. Prüfen Sie, ob die [AWS verwaltete Richtlinie: aus der Rolle entfernt AmazonEKSLocalOutpostClusterPolicy ](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) wurde. + Bei einer der neuen Kubernetes-Steuerebenen-Instances ist möglicherweise ein unerwarteter Bootstrapping-Fehler aufgetreten. Reichen Sie ein Ticket beim [AWS Support Center](https://console.aws.amazon.com/support/home) ein, um weitere Anweisungen zur Fehlerbehebung und Protokollerfassung in diesem Ausnahmefall zu erhalten. ## Knoten können keinem Cluster beitreten + AMI-Probleme: + Sie verwenden ein inkompatibles AMI. Nur für Amazon EKS optimierte Amazon Linux 2023 AMIs werden unterstützt. Weitere Informationen finden Sie unter [ Erstellen von Amazon Linux-Knoten auf AWS Outposts](eks-outposts-self-managed-nodes.md). + Wenn Sie zum Erstellen Ihrer Knoten eine AWS CloudFormation Vorlage verwendet haben, stellen Sie sicher, dass kein AMI verwendet wurde, das nicht unterstützt wird. + Fehlender AWS IAM-Authenticator `ConfigMap` — Wenn er fehlt, müssen Sie ihn erstellen. Weitere Informationen finden Sie unter [Wenden Sie `ConfigMap aws-auth auf Ihren Cluster an`](auth-configmap.md#aws-auth-configmap). + 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 geändert AWS CloudFormation , 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. ## Sammeln von Protokollen Wenn ein Outpost von der AWS Region getrennt wird, der er zugeordnet ist, funktioniert der Kubernetes-Cluster wahrscheinlich weiterhin normal. Wenn der Cluster jedoch nicht ordnungsgemäß funktioniert, folgen Sie den Schritten zur Fehlerbehebung unter Lokale Amazon EKS-Cluster auf AWS Outposts auf Netzwerkunterbrechungen [ vorbereiten. ](eks-outposts-network-disconnects.md) Wenn Sie auf andere Probleme stoßen, wenden AWS Sie sich an den Support. AWS Der Support kann Sie beim Herunterladen und Ausführen eines Tools zur Protokollerfassung unterstützen. Auf diese Weise können Sie Protokolle von Ihren Kubernetes-Cluster-Steuerungsebenen-Instances sammeln und sie zur weiteren Untersuchung an den AWS Support senden. ## Instanzen der Kontrollebene sind nicht erreichbar über AWS Systems Manager Wenn die Amazon EKS-Control-Plane-Instances über den AWS Systems Manager (Systems Manager) nicht 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 beheben, stellen Sie sicher, dass Ihre VPC und Subnetze die Anforderungen unter [ Erstellen einer VPC und Subnetze für Amazon EKS-Cluster auf AWS Outposts erfüllen ](eks-outposts-vpc-subnet-requirements.md) und dass Sie die Schritte unter [ Einrichten des Session Managers ](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) im Systems Manager-Benutzerhandbuch abgeschlossen haben. AWS