**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 auf**, 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.
# Bereitstellung von Amazon EKS On-Premises mit AWS Outposts
Sie können Amazon EKS verwenden, um On-Premises-Kubernetes-Anwendungen in AWS Outposts auszuführen. Sie können Amazon EKS auf Outposts folgendermaßen bereitstellen:
+ **Erweiterte Cluster** – Führen Sie die Kubernetes-Steuerebene in einer AWS-Region und Knoten in Ihrem Outpost aus.
+ **Lokale Cluster** – Führen Sie die Kubernetes-Steuerebene und Knoten in Ihrem Outpost aus.
Für beide Bereitstellungsoptionen wird die Kubernetes-Steuerebene vollständig von AWS verwaltet. Sie können dieselben Amazon-EKS-APIs, -Tools und -Konsolen verwenden, die Sie in der Cloud zum Erstellen und Ausführen von Amazon EKS auf Outposts verwenden.
Das folgende Diagramm zeigt diese Optionen für die Bereitstellung.
![\[Outpost-Bereitstellungsoptionen\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/outposts-deployment-options.png)
## Wann die einzelnen Bereitstellungsoptionen verwendet werden sollten
Sowohl lokale als auch erweiterte Cluster sind allgemeine Bereitstellungsoptionen und können für eine Reihe von Anwendungen verwendet werden.
Mit lokalen Clustern können Sie den gesamten Amazon-EKS-Cluster lokal auf Outposts ausführen. Mit dieser Option können Sie das Risiko von Ausfallzeiten bei Anwendungen verringern, die durch vorübergehende Netzwerkunterbrechungen in der Cloud entstehen können. Diese Netzwerkunterbrechungen können durch Glasfaserausfälle oder Wetterereignisse verursacht werden. Da der gesamte Amazon-EKS-Cluster lokal auf Outposts ausgeführt wird, bleiben Anwendungen verfügbar. Sie können Cluster-Vorgänge während Netzwerkunterbrechungen mit der Cloud durchführen. Weitere Informationen finden Sie unter [Vorbereitung lokaler Amazon-EKS-Cluster in AWS Outposts für Netzwerkunterbrechungen](eks-outposts-network-disconnects.md). Wenn Sie Bedenken hinsichtlich der Qualität der Netzwerkverbindung zwischen Ihren Outposts und dem übergeordneten AWS-Region haben und eine hohe Verfügbarkeit durch Netzwerkunterbrechungen benötigen, verwenden Sie die Bereitstellungsoption des lokalen Clusters.
Mit erweiterten Clustern können Sie Kapazität in Ihrem Outpost sparen, da die Kubernetes-Steuerebene im übergeordneten AWS-Region ausgeführt wird. Diese Option ist geeignet, wenn Sie in eine zuverlässige, redundante Netzwerkverbindung von Ihrem Outpost zum AWS-Region investieren können. Die Qualität der Netzwerkverbindung ist für diese Option entscheidend. Die Art und Weise, wie Kubernetes Netzwerkunterbrechungen zwischen der -Steuerebene und den Knoten handhabt, kann zu Ausfallzeiten der Anwendung führen. Weitere Informationen zum Verhalten von Kubernetes finden Sie unter [Planung, Vorkaufsrecht und Bereinigung](https://kubernetes.io/docs/concepts/scheduling-eviction/) in der Kubernetes-Dokumentation.
## Vergleich der Optionen für die Bereitstellung
Die folgende Tabelle vergleicht die Unterschiede zwischen den beiden Optionen.
| Funktion | Erweiterter Cluster | Lokaler Cluster |
| --- | --- | --- |
| Ort der Kubernetes-Steuerebene | AWS-Region | Outpost |
| Konto der Kubernetes-Steuerebene | AWS-Konto | Ihr Konto |
| Regionale Verfügbarkeit | siehe [Service-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) | USA Ost (Ohio), USA Ost (Nord-Virginia),USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Seoul), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Kanada (Zentral), Europa (Frankfurt), Europa (Irland), Europa (London), Naher Osten (Bahrain), Naher Osten (Bahrain) und Südamerika (São Paulo) |
| Kubernetes-Nebenversionen | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. |
| Plattformversionen | Siehe [EKS-Plattformversionen](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) | Siehe [Erfahren Sie mehr über die Plattformversionen von Kubernetes und Amazon EKS für Outposts AWS](eks-outposts-platform-versions.md) |
| Outpost-Formfaktoren | Outpost-Racks | Outpost-Racks |
| Benutzeroberflächen | AWS-Managementkonsole, AWS-CLI, Amazon-EKS-API, `eksctl`, AWS CloudFormation und Terraform | AWS-Managementkonsole, AWS-CLI, Amazon-EKS-API, `eksctl`, AWS CloudFormation und Terraform |
| Verwaltete Richtlinien | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) und [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) und [AWS verwaltete Richtlinie: Amazon EKSLocal OutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) |
| Cluster-VPC und Subnetze | Siehe [Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze](network-reqs.md) | Siehe [Erstellung einer VPC und von Subnetzen für Amazon-EKS-Cluster in AWS Outposts](eks-outposts-vpc-subnet-requirements.md) |
| Cluster-Endpunktzugriff | Öffentlich oder privat oder beides | Nur privat |
| Kubernetes-API-Server-Authentifizierung | AWS Identity and Access Management (IAM) und OIDC | IAM und `x.509`-Zertifikate |
| Knotentypen | Nur selbstverwaltet | Nur selbstverwaltet |
| Knoten-Berechnungstypen | Amazon EC2 On-Demand | Amazon EC2 On-Demand |
| Knoten-Speichertypen | Amazon EBS `gp2` und lokale NVMe-SSD | Amazon EBS `gp2` und lokale NVMe-SSD |
| Amazon EKS-optimierte AMIs | Amazon Linux, Windows und Bottlerocket | Nur Amazon Linux |
| IP-Versionen | Nur `IPv4` | Nur `IPv4` |
| Add-Ons | Amazon-EKS-Add-Ons oder selbstverwaltete Add-Ons | Nur Selbstverwaltete Add-Ons |
| Standard-Container-Netzwerkschnittstelle | Amazon-VPC-CNI-Plug-In für Kubernetes | Amazon-VPC-CNI-Plug-In für Kubernetes |
| Kubernetes-Steuerebene-Protokolle | Amazon CloudWatch Logs | Amazon CloudWatch Logs |
| Load Balancing | Verwenden Sie den [AWS Load Balancer Controller](aws-load-balancer-controller.md) nur zum Bereitstellen von Application Load Balancern (keine Network Load Balancer) | Verwenden Sie den [AWS Load Balancer Controller](aws-load-balancer-controller.md) nur zum Bereitstellen von Application Load Balancern (keine Network Load Balancer) |
| Secrets-Umschlagverschlüsselung | Siehe [Verschlüsselung von Kubernetes-Geheimnissen mit KMS in vorhandenen Clustern](enable-kms.md) | Nicht unterstützt |
| IAM-Rollen für Servicekonten | Siehe [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) | Nicht unterstützt |
| Fehlersuche | Siehe [Beheben von Problemen mit Amazon-EKS-Clustern und -Knoten](troubleshooting.md) | Siehe [Fehlerbehebung bei lokalen Amazon EKS-Clustern auf AWS Outposts](eks-outposts-troubleshooting.md) |
**Topics**
# Erstellung lokaler Amazon-EKS-Cluster in AWS Outposts für hohe Verfügbarkeit
Sie können lokale Cluster verwenden, um Ihren gesamten Amazon-EKS-Cluster lokal in AWS Outposts auszuführen. Auf diese Weise wird das Risiko von Anwendungsausfällen, die sich aus vorübergehenden Unterbrechungen der Netzwerkverbindung zur Cloud ergeben können, minimiert. Diese Verbindungsunterbrechungen können durch Glasfaserunterbrechungen oder Wetterereignisse verursacht werden. Weil das gesamte Kubernetes-Cluster lokal in Outposts ausgeführt wird, bleiben Anwendungen verfügbar. Sie können Cluster-Vorgänge während Netzwerkunterbrechungen mit der Cloud durchführen. Weitere Informationen finden Sie unter [Vorbereitung lokaler Amazon-EKS-Cluster in AWS Outposts für Netzwerkunterbrechungen](eks-outposts-network-disconnects.md). Das folgende Diagramm zeigt eine lokale Cluster-Bereitstellung.
![\[Lokaler Outpost-Cluster\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/outposts-local-cluster.png)
Lokale Cluster sind allgemein für die Verwendung mit Outpost-Racks verfügbar.
## Unterstützte AWS-Regionen
Sie können lokale Cluster in den folgenden AWS-Regionen erstellen: USA Ost (Ohio), USA Ost (Nord-Virginia),USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Seoul), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Kanada (Zentral), Europa (Frankfurt), Europa (Irland), Europa (London), Naher Osten (Bahrain), Naher Osten (Bahrain) und Südamerika (São Paulo). Weitere Informationen zu unterstützten Funktionen finden Sie unter [Vergleich der Optionen für die Bereitstellung](eks-outposts.md#outposts-overview-comparing-deployment-options).
**Topics**
# Stellen Sie einen Amazon EKS-Cluster auf AWS Outposts bereit
Dieses Thema bietet einen Überblick darüber, was beim Ausführen eines lokalen Clusters auf einem Outpost zu beachten ist. Das Thema enthält auch Anweisungen zum Bereitstellen eines lokalen Clusters auf einem Outpost.
**Wichtig**
Diese Überlegungen werden in der zugehörigen Amazon-EKS-Dokumentation nicht wiederholt. Wenn andere Themen der Amazon-EKS-Dokumentation mit den hier aufgeführten Überlegungen in Konflikt stehen, befolgen Sie die Überlegungen hier.
Diese Überlegungen sind freibleibend und können sich häufig ändern. Wir empfehlen Ihnen daher, dieses Thema regelmäßig zu überprüfen.
Viele der Überlegungen unterscheiden sich von den Überlegungen zur Erstellung eines Clusters in der AWS Cloud.
+ Lokale Cluster unterstützen nur Outpost-Racks. Ein einzelner lokaler Cluster kann über mehrere physische Outpost-Racks laufen, die aus einem einzigen logischen Outpost bestehen. Ein einzelner lokaler Cluster kann nicht über mehrere logische Outposts hinweg ausgeführt werden. Jeder logische Outpost hat einen einzigen Outpost-ARN.
+ Lokale Cluster führen und verwalten die Kubernetes-Steuerebenen in Ihrem Konto in dem Outpost. Sie können keine Workloads auf den Instances der Kubernete-Steuerebene ausführen oder die Komponenten der Kubernetes -Steuerebene ändern. Diese Knoten werden vom Amazon-EKS-Service verwaltet. Änderungen an derKubernetes-Steuerebene bleiben nicht durch automatische Amazon-EKS-Verwaltungsaktionen, wie etwa Patching, erhalten.
+ Lokale Cluster unterstützen selbstverwaltete Add-Ons und selbstverwaltete Amazon-Linux-Knotengruppen. Das [Amazon-VPC-CNI-Plugin für Kubernetes](managing-vpc-cni.md), [kube-proxy](managing-kube-proxy.md) und [CoreDNS](managing-coredns.md)-Add-Ons wird automatisch auf lokalen Clustern installiert.
+ Lokale Cluster erfordern die Verwendung von Amazon EBS auf Outposts. In Ihrem Outpost muss Amazon EBS für die Aufbewahrung der Kubernetes-Steuerebene verfügbar sein. Outposts unterstützen nur Amazon EBS `gp2`-Volumes.
+ Amazon-EBS-gestützte Kubernetes `PersistentVolumes` werden mit dem Amazon-EBS-CSI-Treiber unterstützt.
+ Die Instances der Steuerebene lokaler Cluster werden in einer [gestapelten hochverfügbaren Topologie](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/) eingerichtet. Zwei der drei Steuerebenen-Instances müssen jederzeit funktionsfähig sein, um das Quorum aufrechtzuerhalten. Wenn das Quorum verloren geht, wenden Sie sich an den AWS Support, da einige serviceseitige Aktionen erforderlich sind, um die neuen verwalteten Instanzen zu aktivieren.
**Voraussetzungen**
+ Vertrautheit mit den [Outposts-Bereitstellungsoptionen](eks-outposts.md#outposts-overview-comparing-deployment-options), [Auswahl von Instance-Typen und Platzierungsgruppen für Amazon EKS-Cluster auf AWS Outposts auf der Grundlage von Kapazitätsüberlegungen sowie [VPC-Anforderungen](eks-outposts-vpc-subnet-requirements.md) und Überlegungen](eks-outposts-capacity-considerations.md).
+ Ein vorhandener Outpost. Weitere Informationen finden Sie unter [Was sind AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Computer oder AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Ein IAM-Prinzipal (Benutzer oder Rolle) mit Berechtigungen zum Erstellen (`create`) und Beschreiben (`describe`) eines Amazon-EKS-Clusters. Weitere Informationen erhalten Sie unter [Kubernetes-Cluster auf einem Outpost erstellen](security-iam-id-based-policy-examples.md#policy-create-local-cluster) und [Auflisten oder Beschreiben aller Cluster](security-iam-id-based-policy-examples.md#policy-example2).
Wenn ein lokaler Amazon-EKS-Cluster erstellt wird, wird der [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der den Cluster erstellt, dauerhaft hinzugefügt. Der Prinzipal wird ausdrücklich als Administrator in die Kubernetes-RBAC-Autorisierungstabelle aufgenommen. Diese Entität hat `system:masters`-Berechtigungen. Die Identität dieser Entität ist in Ihrer Cluster-Konfiguration nicht sichtbar. Daher ist es wichtig, die Entität zu notieren, die den Cluster erstellt hat, und sicherzustellen, dass Sie diese keinesfalls löschen. Anfänglich kann nur der Prinzipal, der den Server erstellt hat, Aufrufe an den Kubernetes-API-Server mit `kubectl` tätigen. Wenn Sie die Konsole zum Erstellen des Clusters verwenden, stellen Sie sicher, dass sich dieselben IAM-Anmeldeinformationen in der AWS SDK-Anmeldeinformationskette befinden, wenn Sie `kubectl` Befehle auf Ihrem Cluster ausführen. Nachdem Ihr Cluster erstellt wurde, können Sie anderen IAM-Prinzipalen Zugriff auf Ihren Cluster gewähren.
## Einen lokalen Amazon-EKS-Cluster erstellen
Sie können einen lokalen Cluster mit den folgenden Tools erstellen, die auf dieser Seite beschrieben werden:
+ [`eksctl`](#eksctl_create_cluster_outpost)
+ [AWS-Managementkonsole](#console_create_cluster_outpost)
Sie können auch die [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), die [Amazon EKS-API](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), die [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html)oder [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) verwenden [AWS SDKs](https://aws.amazon.com/developer/tools/), um Cluster auf Outposts zu erstellen.
### `eksctl`
**So erstellen Sie einen Cluster mit `eksctl` **
1. Installieren Sie Version `0.215.0` oder höher des `eksctl` Befehlszeilentools auf Ihrem Gerät oder. AWS CloudShell Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie die folgenden Werte und führen Sie dann den geänderten Befehl aus, um die `outpost-control-plane.yaml`-Datei zu erstellen:
+ *region-code*Ersetzen Sie es durch die [unterstützte AWS Region](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions), in der Sie Ihren Cluster erstellen möchten.
+ Ersetzen Sie *my-cluster* durch Ihren Cluster-Namen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein.
+ Ersetzen Sie *vpc-ExampleID1* und *subnet-ExampleID1* durch die IDs Ihrer vorhandenen VPC und Ihres Subnetzes. Die VPC und das Subnetz müssen die Anforderungen unter [Erstellen einer VPC und Subnetze für Amazon EKS-Cluster](eks-outposts-vpc-subnet-requirements.md) auf Outposts erfüllen. AWS
+ Ersetzen Sie es durch die *uniqueid* ID Ihres Outposts.
+ Ersetzen Sie *m5.large* durch einen Instance-Typ, der auf Ihrem Outpost verfügbar ist. Bevor Sie einen Instance-Typ auswählen, lesen Sie [Wählen Sie Instance-Typen und Platzierungsgruppen für Amazon-EKS-Cluster in AWS Outposts basierend auf Kapazitätsüberlegungen aus.](eks-outposts-capacity-considerations.md). Drei Steuerebenen-Instances werden bereitgestellt. Sie können diese Nummer nicht ändern.
```
cat >outpost-control-plane.yaml <
**Um Ihren Cluster mit dem zu erstellen AWS-Managementkonsole **
1. Sie benötigen eine vorhandene VPC und ein Subnetz, die den Anforderungen von Amazon EKS entsprechen. Weitere Informationen finden Sie unter [Erstellung einer VPC und von Subnetzen für Amazon-EKS-Cluster in AWS Outposts](eks-outposts-vpc-subnet-requirements.md).
1. Wenn Sie bereits eine lokale Cluster-IAM-Rolle haben oder Ihren Cluster mit `eksctl` erstellen, können Sie diesen Schritt überspringen. Standardmäßig erstellt `eksctl` eine Rolle für Sie.
1. Führen Sie den folgenden Befehl aus, um eine JSON-Datei für eine IAM-Vertrauensrichtlinie zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie die Amazon-EKS-Cluster-IAM-Rolle. Um eine IAM-Rolle zu erstellen, muss dem [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der die Rolle erstellt, die folgende `iam:CreateRole`-Aktion (Berechtigung) zugewiesen werden.
```
aws iam create-role --role-name myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json"
```
1. Hängen Sie die von Amazon EKS verwaltete Richtlinie mit dem Namen [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) an die Rolle an. Um eine IAM-Richtlinie an einen [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) anzuhängen, muss der Prinzipal, der die Richtlinie anhängt, eine der folgenden IAM-Aktionen (Berechtigungen) zugewiesen werden: `iam:AttachUserPolicy` oder `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole
```
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Vergewissern Sie sich, dass Sie oben auf dem Konsolenbildschirm eine [unterstützte AWS Region](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) ausgewählt haben.
1. Wählen Sie **Cluster hinzufügen** und dann **Erstellen** aus.
1. Füllen Sie auf der Seite **Configure cluster** (Cluster konfigurieren) die folgenden Felder aus oder wählen Sie sie aus:
+ **Standort der Kubernetes-Steuerebene** — Wählen Sie AWS Outposts.
+ **Outpost-ID** – Wählen Sie die ID des Outposts, auf dem Sie Ihre Steuerebene erstellen möchten.
+ **Instance Type** (Instance-Typ) – Wählen Sie einen Instance-Typ aus. Es werden nur die in Ihrem Outpost verfügbaren Instance-Typen angezeigt. In der Dropdown-Liste beschreibt jeder Instance-Typ, für wie viele Knoten der Instance-Typ empfohlen wird. Bevor Sie einen Instance-Typ auswählen, lesen Sie [Wählen Sie Instance-Typen und Platzierungsgruppen für Amazon-EKS-Cluster in AWS Outposts basierend auf Kapazitätsüberlegungen aus.](eks-outposts-capacity-considerations.md). Alle Replikate werden mit demselben Instance-Typ bereitgestellt. Sie können den Instance-Typ nicht mehr ändern, nachdem der Cluster erstellt wurde. Drei Steuerebenen-Instances werden bereitgestellt. Sie können diese Nummer nicht ändern.
+ **Name** – Ein Name für Ihren Cluster. Es muss in Ihrem Konto einzigartig sein. AWS Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein.
+ **Kubernetes-Version** – Wählen Sie die Kubernetes-Version aus, die Sie für Ihren Cluster verwenden möchten. Wir empfehlen, die frühere Version auszuwählen, es sei denn, Sie müssen eine ältere Version verwenden.
+ **Cluster-Servicerolle** — Wählen Sie die Amazon EKS-Cluster-IAM-Rolle aus, die Sie in einem vorherigen Schritt erstellt haben, damit die Kubernetes-Steuerebene Ressourcen verwalten kann. AWS
+ **Kubernetes-Cluster-Administratorzugriff**: Wenn der IAM-Prinzipal (Rolle oder Benutzer), der den Cluster erstellt, Administratorzugriff auf die Kubernetes-Objekte im Cluster haben soll, übernehmen Sie die Standardeinstellung (zulassen). Amazon EKS erstellt einen Zugriffseintrag für den IAM-Prinzipal und erteilt Cluster-Administratorberechtigungen für den Zugriffseintrag. Weitere Informationen zu Zugriffseinträgen finden Sie unter [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md).
Wenn nicht der Prinzipal, der den Cluster erstellt, sondern ein anderer IAM-Prinzipal Administratorzugriff auf Kubernetes-Cluster-Objekte haben soll, wählen Sie die Verweigerungsoption aus. Nach der Cluster-Erstellung kann jeder IAM-Prinzipal, der über IAM-Berechtigungen zum Erstellen von Zugriffseinträgen verfügt, Zugriffseinträge für beliebige IAM-Prinzipale hinzufügen, die Zugriff auf Kubernetes-Cluster-Objekte benötigen. Weitere Informationen zu den erforderlichen IAM-Berechtigungen finden Sie in der Service-Authorization-Referenz unter [Von Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions). Wenn Sie die Verweigerungsoption auswählen und keine Zugriffseinträge erstellen, können keine IAM-Prinzipale auf die Kubernetes-Objekte im Cluster zugreifen.
+ **Tags** – (Optional) Fügen Sie Ihrem Cluster beliebige Tags hinzu. Weitere Informationen finden Sie unter [Organisation von Amazon-EKS-Ressourcen mit Tags](eks-using-tags.md). Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Specify networking** (Netzwerk angeben) die Werte für die folgenden Felder aus:
+ **VPC** – Wählen Sie eine vorhandene VPC aus. Die VPC muss über eine ausreichende Anzahl von IP-Adressen für den Cluster, alle Knoten und andere Kubernetes-Ressourcen, die Sie erstellen möchten, verfügen. Ihr VPC muss die Anforderungen in den [VPC-Anforderungen und -Überlegungen](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements) erfüllen.
+ **Subnetze** – Standardmäßig sind alle im vorherigen Feld angegebenen Subnetze in der VPC vorausgewählt. Die von Ihnen ausgewählten Subnetze müssen die in den [Subnetz-Anforderungen und -Überlegungen](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements) beschriebenen Anforderungen erfüllen.
+ **Security groups** (Sicherheitsgruppen) – (Optional) Geben Sie eine oder mehrere Sicherheitsgruppen an, die Amazon EKS den erstellten Netzwerkschnittstellen zuordnen soll. Amazon EKS erstellt automatisch eine Sicherheitsgruppe, die die Kommunikation zwischen Ihrem Cluster und Ihrer VPC ermöglicht. Amazon EKS verknüpft diese Sicherheitsgruppe und alle, die Sie wählen, mit den erstellten Netzwerkschnittstellen. Weitere Informationen zu der Cluster-Sicherheitsgruppe, die Amazon EKS erstellt, finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md). Sie können die Regeln in der von Amazon EKS erstellten Cluster-Sicherheitsgruppe ändern. Wenn Sie Ihre eigenen Sicherheitsgruppen hinzufügen möchten, können Sie die ausgewählten nach der Cluster-Erstellung nicht ändern. Damit On-Premises-Hosts mit dem Cluster-Endpunkt kommunizieren können, müssen Sie eingehenden Datenverkehr von der Cluster-Sicherheitsgruppe zulassen. Bei Clustern, die nicht über eine eingehende und ausgehende Internetverbindung verfügen (auch als private Cluster bezeichnet), müssen Sie eine der folgenden Maßnahmen ergreifen:
+ Fügen Sie die Sicherheitsgruppe hinzu, die mit den erforderlichen VPC-Endpunkten verbunden ist. Weitere Informationen zu den erforderlichen Endpunkten finden Sie unter [Subnetzzugriff [Verwendung von -Schnittstellen-VPC-Endpunkten](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints)](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services) auf Dienste. AWS
+ Ändern Sie die Sicherheitsgruppe, die Amazon EKS erstellt hat, um Datenverkehr von der Sicherheitsgruppe zuzulassen, die den VPC-Endpunkten zugeordnet ist. Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
1. Auf der Seite **Beobachtbarkeit konfigurieren** können Sie optional auswählen, welche **Metriken** und Optionen zur **Steuerebenen-Protokollierung** Sie aktivieren möchten. Standardmäßig sind alle Protokollierungstypen deaktiviert.
+ Weiteren Informationen zur Prometheus-Metrik-Option finden Sie unter [Schritt 1: Prometheus-Metriken aktivieren](prometheus.md#turn-on-prometheus-metrics).
+ Weitere Informationen zu den Optionen für die **Steuerebenen-Protokollierung** finden Sie unter [Protokolle der Kontrollebene an CloudWatch Logs senden](control-plane-logs.md). Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
1. Überprüfen Sie auf der Seite **Review and create** (Überprüfen und erstellen) die Informationen, die Sie auf den vorherigen Seiten eingegeben oder ausgewählt haben. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie zufrieden sind, klicken Sie auf **Erstellen**. Das Feld **Status** zeigt **CREATING** (WIRD ERSTELLT) an, während der Cluster bereitgestellt wird.
Die Clusterbereitstellung dauert mehrere Minuten.
## Anzeigen Ihres lokalen Amazon-EKS-Clusters
1. Nachdem Ihr Cluster erstellt wurde, können Sie die erstellten Instances der Amazon-EC2-Steuerebene anzeigen.
```
aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane
```
Eine Beispielausgabe sieht wie folgt aus.
```
"Name": "my-cluster-control-plane-id1"
"Name": "my-cluster-control-plane-id2"
"Name": "my-cluster-control-plane-id3"
```
Jede Instance ist mit `node-role.eks-local.amazonaws.com/control-plane` gekennzeichnet, sodass auf den Instances der Steuerebene keine Workloads geplant werden. Weitere Informationen zu Taints finden Sie unter [Taints und Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) in der Kubernetes-Dokumentation. Amazon EKS überwacht kontinuierlich den Status lokaler Cluster. Wir führen automatische Verwaltungsaktionen durch, z. B. Sicherheits-Patches und das Reparieren fehlerhafter Instances. Wenn lokale Cluster von der Cloud getrennt werden, führen wir Aktionen durch, um sicherzustellen, dass der Cluster bei der erneuten Verbindung wieder in einen fehlerfreien Zustand versetzt wird.
1. Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, können Sie diesen Schritt überspringen. `eksctl` schließt diesen Schritt für Sie ab. Aktivieren Sie `kubectl`, um mit Ihrem Cluster zu kommunizieren, indem Sie einen neuen Kontext zur Datei `kubectl` `config` hinzufügen. Anweisungen zum Erstellen und Aktualisieren der Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
Added new context arn:aws: eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Um eine Verbindung zum Kubernetes-API-Server Ihres lokalen Clusters herzustellen, müssen Sie Zugriff auf das lokale Gateway für das Subnetz haben oder eine Verbindung innerhalb der VPC herstellen. Weitere Informationen zum Verbinden eines Outpost-Racks mit Ihrem lokalen Netzwerk finden Sie unter [So funktionieren lokale Gateways für Racks](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html) im AWS Outposts-Benutzerhandbuch. Wenn Sie direktes VPC-Routing verwenden und das Outpost-Subnetz eine Route zu Ihrem lokalen Gateway hat, werden die privaten IP-Adressen der -Instances der Kubernetes-Steuerebene automatisch über Ihr lokales Netzwerk übertragen. Der Kubernetes-API-Server-Endpunkt des lokalen Clusters wird in Amazon Route 53 (Route 53) gehostet. Der API-Service-Endpunkt kann von öffentlichen DNS-Servern in die privaten IP-Adressen der Kubernetes API-Server aufgelöst werden.
Die Instances der Kubernetes-Steuerebenen lokaler Cluster sind mit statischen Elastic-Network-Schnittstellen mit festen privaten IP-Adressen konfiguriert, die sich während des Cluster-Lebenszyklus nicht ändern. Rechner, die mit dem Kubernetes-API-Server interagieren, verfügen möglicherweise nicht über eine Verbindung zu Route 53, wenn die Netzwerkverbindung unterbrochen ist. In diesem Fall empfehlen wir, `/etc/hosts` mit den statischen privaten IP-Adressen für den weiteren Betrieb zu konfigurieren. Wir empfehlen außerdem, lokale DNS-Server einzurichten und diese mit Ihrem Outpost zu verbinden. Weitere Informationen finden Sie in der [AWS -Outposts-Dokumentation](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns). Führen Sie den folgenden Befehl aus, um zu bestätigen, dass die Kommunikation mit Ihrem Cluster hergestellt wurde.
```
kubectl get svc
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
1. (Optional) Testen Sie die Authentifizierung für Ihren lokalen Cluster, wenn dieser nicht mit der Cloud verbunden ist. AWS Detaillierte Anweisungen finden Sie unter [Vorbereitung lokaler Amazon-EKS-Cluster in AWS Outposts für Netzwerkunterbrechungen](eks-outposts-network-disconnects.md).
### Interne Ressourcen
Amazon EKS erstellt die folgenden Ressourcen in Ihrem Cluster. Die Ressourcen sind für den internen Gebrauch von Amazon EKS bestimmt. Damit Ihr Cluster ordnungsgemäß funktioniert, sollten Sie diese Ressourcen nicht bearbeiten oder ändern.
+ Die folgenden [Spiegel-Pods](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod):
+ `aws-iam-authenticator-node-hostname `
+ `eks-certificates-controller-node-hostname `
+ `etcd-node-hostname `
+ `kube-apiserver-node-hostname `
+ `kube-controller-manager-node-hostname `
+ `kube-scheduler-node-hostname `
+ Die folgenden selbstverwalteten Add-Ons:
+ `kube-system/coredns`
+ `kube-system/` `kube-proxy` (wird erst erstellt, wenn Sie Ihren ersten Knoten hinzugefügt haben)
+ `kube-system/aws-node` (wird erst erstellt, wenn Sie Ihren ersten Knoten hinzugefügt haben). Lokale Cluster verwenden das Amazon VPC-CNI-Plugin für das Kubernetes-Plugin für die Cluster-Vernetzung. Ändern Sie nicht die Konfiguration für Steuerebene-Instances (Pods mit dem Namen `aws-node-controlplane-*`). Es gibt Konfigurationsvariablen, die Sie verwenden können, um den Standardwert zu ändern, wenn das Plugin neue Netzwerkschnittstellen erstellt. Weitere Informationen finden Sie in der [Dokumentation](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) zu GitHub.
+ Die folgenden Services:
+ `default/kubernetes`
+ `kube-system/kube-dns`
+ Eine `PodSecurityPolicy` namens `eks.system`
+ Eine `ClusterRole` namens `eks:system:podsecuritypolicy`
+ Eine `ClusterRoleBinding` namens `eks:system`
+ Zusätzlich zur [Cluster-Sicherheitsgruppe](sec-group-reqs.md) erstellt Amazon EKS in Ihrem AWS Konto eine Sicherheitsgruppe mit dem Namen`eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `. Diese Sicherheitsgruppe ermöglicht den freien Datenverkehr zwischen Kubernetes-Komponenten, die in Instances der Steuerebene ausgeführt werden.
Empfohlene nächste Schritte:
+ [Erteilen Sie dem IAM-Prinzipal, der den Cluster erstellt hat, die erforderlichen Berechtigungen zum Anzeigen von Kubernetes-Ressourcen in AWS-Managementkonsole](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
+ [Gewähren Sie IAM-Entitäten Zugriff auf Ihren Cluster](grant-k8s-access.md). Wenn Sie möchten, dass die Entitäten Kubernetes-Ressourcen in der Amazon-EKS-Konsole anzeigen können, gewähren Sie ihnen die [Erforderlichen Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ [Konfigurieren Sie die Protokollierung für Ihren Cluster](control-plane-logs.md)
+ Machen Sie sich mit dem vertraut, was während [Netzwerktrennungen](eks-outposts-network-disconnects.md) passiert.
+ [Fügen Sie Knoten zu Ihrem Cluster hinzu](eks-outposts-self-managed-nodes.md)
+ Erwägen Sie, einen Backup-Plan für Ihr `etcd` zu erstellen. Amazon EKS unterstützt keine automatisierte Sicherung und Wiederherstellung von `etcd` für lokale Cluster. Weitere Informationen finden Sie unter [Sicherung eines etcd-Clusters](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) in der Kubernetes-Dokumentation. Die beiden Hauptoptionen sind die Verwendung von `etcdctl` zur Automatisierung der Erstellung von Snapshots oder die Verwendung der Amazon-EBS-Speicher-Volume-Sicherung.
# Erfahren Sie mehr über die Plattformversionen von Kubernetes und Amazon EKS für Outposts AWS
Lokale Clusterplattformversionen stellen die Funktionen des Amazon EKS-Clusters auf AWS Outposts dar. Die Versionen umfassen die Komponenten, die in der Kubernetes-Steuerebene ausgeführt werden, wobei die Kubernetes-API-Server-Flags aktiviert sind. Sie enthalten auch die aktuelle Kubernetes-Patch-Version. Jede Kubernetes-Minor-Version hat eine oder mehrere zugehörige -Plattformversionen. Die Plattformversionen für verschiedene Kubernetes-Nebenversionen sind unabhängig. Die Plattformversionen für lokale Cluster und Amazon-EKS-Cluster in der Cloud sind unabhängig.
Wenn eine neue Kubernetes-Nebenversion für lokale Cluster verfügbar ist, z. B. `1.31`, beginnt die anfängliche Plattformversion für diese Kubernetes-Nebenversion bei `eks-local-outposts.1`. Allerdings veröffentlicht Amazon EKS regelmäßig neue Plattformversionen, um neue Einstellungen für die Kubernetes-Steuerebene und Sicherheitsfixes bereitzustellen.
Wenn neue lokale Cluster-Plattformversionen für eine Minor-Version verfügbar werden:
+ Die Versionsnummer der -Plattform wird erhöht (`eks-local-outposts.n+1`).
+ Amazon EKS aktualisiert automatisch alle vorhandenen lokalen Cluster auf die neueste Plattformversion für ihre entsprechende Kubernetes-Nebenversion. Automatische Aktualisierungen bestehender Plattformversionen werden schrittweise durchgeführt. Der Einführungsprozess umfasst den schrittweisen Austausch der verwalteten Kubernetes-Steuerebenen-Instances, die auf dem Outpost ausgeführt werden, bis alle 3 Instances durch neue ersetzt sind.
+ Der Austauschprozess der Kubernetes-Steuerebenen-Instance wird gestoppt, wenn die Gefahr einer Service-Unterbrechung besteht. Amazon EKS versucht nur dann, eine Instance zu ersetzen, wenn die beiden anderen Kubernetes-Steuerebenen-Instances fehlerfrei sind und alle Bereitschaftsbedingungen als Cluster-Knoten erfüllen.
+ Die Einführung einer neuen Plattformversion dauert in der Regel weniger als 30 Minuten. Wenn ein Cluster über einen längeren Zeitraum im `UPDATING` Status verbleibt, wenden Sie sich an den Support [Fehlerbehebung bei lokalen Amazon EKS-Clustern auf AWS Outposts](eks-outposts-troubleshooting.md) und wenden Sie sich an den AWS Support. Beenden Sie Kubernetes-Steuerungsinstanzen niemals manuell, es sei denn, Sie werden vom Support dazu aufgefordert. AWS
+ Amazon EKS veröffentlicht möglicherweise ein neues Knoten-AMI mit einer entsprechenden Patch-Version. Alle Patch-Versionen sind zwischen der Kubernetes-Steuerebene und dem Knoten AMIs für eine einzelne Kubernetes-Nebenversion kompatibel.
Neue Plattformversionen führen keine kritischen Änderungen ein. Sie führen nicht zu Service-Unterbrechungen.
Lokale Cluster werden immer mit der neuesten verfügbaren Plattformversion (`eks-local-outposts.n`) für die angegebene Kubernetes-Version erstellt.
Die aktuellen und kürzlichen -Plattformversionen sind in den folgenden Tabellen beschrieben.
Um Benachrichtigungen über alle Änderungen an den Quelldateien dieser spezifischen Dokumentationsseite zu erhalten, können Sie die folgende URL mit einem RSS-Reader abonnieren:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom
```
## Kubernetes-Version `1.31`
Die folgenden Zugangs-Controller sind für alle `1.31`-Plattformversionen aktiviert: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` und `ValidatingAdmissionWebhook`.
| Kubernetes-Version | Amazon-EKS-Plattformversion | Versionshinweise | Datum der Veröffentlichung |
| --- | --- | --- | --- |
| `1.31.14` | `eks-local-outposts.8` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.31.14` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.8` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.4`. Bottlerocket-Version aktualisiert auf `v1.52.0`. | 23. Dezember 2025 |
| `1.31.12` | `eks-local-outposts.5` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.31.10` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.4` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.2`. Bottlerocket-Version aktualisiert auf `v1.47.0`. | 3. Oktober 2025 |
| `1.31.9` | `eks-local-outposts.4` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.31.9` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.2` Das Amazon VPC CNI-Plugin für Kubernetes wurde auf die `v1.20.0` Bottlerocket-Version aktualisiert auf. `v1.43.0` | 9. August 2025 |
| `1.31.7` | `eks-local-outposts.3` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.31.9` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.1` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.19.5`. Bottlerocket-Version aktualisiert auf `v1.40.0`. | 19. Juni 2025 |
| `1.31.6` | `eks-local-outposts.2` | Neue Plattformversion mit Sicherheitsfixes und -verbesserungen. Bottlerocket-Version aktualisiert auf `v1.36.0`. | 24. April 2025 |
| `1.31.6` | `eks-local-outposts.1` | Erste Veröffentlichung von Kubernetes-Version `v1.31` für lokale Amazon-EKS-Cluster in Outposts. | 9. April 2025 |
## Kubernetes-Version `1.30`
Die folgenden Zugangs-Controller sind für alle `1.30`-Plattformversionen aktiviert: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` und `ValidatingAdmissionWebhook`.
| Kubernetes-Version | Amazon-EKS-Plattformversion | Versionshinweise | Datum der Veröffentlichung |
| --- | --- | --- | --- |
| `1.30.14` | `eks-local-outposts.10` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. AWS IAM Authenticator wurde aktualisiert auf. `v0.7.8` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.4`. Bottlerocket-Version aktualisiert auf `v1.52.0`. | 23. Dezember 2025 |
| `1.30.14` | `eks-local-outposts.7` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.30.14` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.4` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.2`. Bottlerocket-Version aktualisiert auf `v1.47.0`. | 3. Oktober 2025 |
| `1.30.13` | `eks-local-outposts.6` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.30.13` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.2` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.0`. Bottlerocket-Version aktualisiert auf `v1.43.0`. | 09. August 2025 |
| `1.30.11` | `eks-local-outposts.5` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.30.11` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.1` Das Amazon VPC CNI-Plugin für Kubernetes wurde auf die `v1.19.5` Bottlerocket-Version aktualisiert auf. `v1.40.0` | 19. Juni 2025 |
| `1.30.10` | `eks-local-outposts.4` | Neue Plattformversion mit Sicherheitsfixes und -verbesserungen. Bottlerocket-Version aktualisiert auf `v1.36.0`. | 24. April 2025 |
| `1.30.10` | `eks-local-outposts.3` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.30.10` AWS IAM Authenticator wurde aktualisiert auf. `v0.6.29` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.19.2`. CoreDNS wurde aktualisiert auf. `v1.11.4` AWS Cloud Controller Manager wurde aktualisiert auf. `v1.30.8` Bottlerocket-Version aktualisiert auf `v1.34.0`. | 27. März 2025 |
| `1.30.7` | `eks-local-outposts.2` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.30.7` AWS IAM Authenticator wurde aktualisiert auf. `v0.6.28` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.19.0`. Die Bottlerocket-Version wurde aktualisiert auf. `v1.29.0` | 10. Januar 2025 |
| `1.30.5` | `eks-local-outposts.1` | Erste Veröffentlichung von Kubernetes-Version `v1.30` für lokale Amazon-EKS-Cluster in Outposts. | 13. November 2024 |
## Kubernetes-Version `1.29`
Die folgenden Zugangs-Controller sind für alle `1.29`-Plattformversionen aktiviert: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` und `ValidatingAdmissionWebhook`.
| Kubernetes-Version | Amazon-EKS-Plattformversion | Versionshinweise | Datum der Veröffentlichung |
| --- | --- | --- | --- |
| `1.29.15` | `eks-local-outposts.13` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. AWS IAM Authenticator wurde aktualisiert auf. `v0.7.8` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.4`. Bottlerocket-Version aktualisiert auf `v1.52.0`. | 23. Dezember 2025 |
| `v1.29.15` | `eks-local-outposts.10` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. AWS IAM Authenticator wurde aktualisiert auf. `v0.7.4` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.2`. Bottlerocket-Version aktualisiert auf `v1.47.0`. | 3. Oktober 2025 |
| `v1.29.15` | `eks-local-outposts.9` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. AWS IAM Authenticator wurde aktualisiert auf. `v0.7.2` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.20.0`. Bottlerocket-Version aktualisiert auf `v1.43.0`. | 9. August 2025 |
| `v1.29.15` | `eks-local-outposts.8` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.29.15` AWS IAM Authenticator wurde aktualisiert auf. `v0.7.1` Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.19.5`. Bottlerocket-Version aktualisiert auf `v1.40.0`. | 19. Juni 2025 |
| `v1.29.14` | `eks-local-outposts.7` | Neue Plattformversion mit Sicherheitsfixes und -verbesserungen. Bottlerocket-Version aktualisiert auf `v1.36.0`. | 24. März 2025 |
| `v1.29.14` | `eks-local-outposts.6` | Neue Plattformversion mit Sicherheitskorrekturen und -verbesserungen. kube-proxy auf `v1.29.14` aktualisiert. Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.19.2`. CoreDNS wurde aktualisiert auf. `v1.11.4` AWS Cloud Controller Manager wurde aktualisiert auf. `v1.29.8` Bottlerocket-Version aktualisiert auf `v1.34.0`. | 27. März 2025 |
| `v1.29.11` | `eks-local-outposts.5` | Neue Plattformversion mit Sicherheitskorrekturen und -verbesserungen. kube-proxy auf `v1.29.11` aktualisiert. Amazon-VPC-CNI-Plugin für Kubernetes aktualisiert zu `v1.19.0`. Das CoreDNS-Image wurde aktualisiert auf. `v1.11.3` Die Bottlerocket-Version wurde aktualisiert auf. `v1.29.0` | 10. Januar 2025 |
| `1.29.9` | `eks-local-outposts.4` | Neue Plattformversion mit Sicherheitskorrekturen und Verbesserungen. Kube-Proxy wurde aktualisiert auf. `v1.29.9` AWS IAM Authenticator wurde aktualisiert auf. `v0.6.26` Die Bottlerocket-Version wurde aktualisiert auf. `v1.26.0` | 8. November 2024 |
| `1.29.6` | `eks-local-outposts.3` | Neue Plattformversion mit Sicherheitsfixes und -verbesserungen. Die Bottlerocket-Version wurde aktualisiert auf. `v1.22.0` | 22. Oktober 2024 |
| `1.29.6` | `eks-local-outposts.2` | Neue Plattformversion mit Sicherheitsfixes und -verbesserungen. Die Bottlerocket-Version wurde aktualisiert auf. `v1.21.0` | 27. August 2024 |
| `1.29.6` | `eks-local-outposts.1` | Erste Veröffentlichung von Kubernetes-Version `v1.29` für lokale Amazon-EKS-Cluster in Outposts. | 20. August 2024 |
# Erstellung einer VPC und von Subnetzen für Amazon-EKS-Cluster in AWS Outposts
Wenn Sie einen lokalen Cluster erstellen, geben Sie eine VPC und mindestens ein privates Subnetz an, das auf Outposts ausgeführt wird. Dieses Thema bietet einen Überblick über die VPC- und Subnetzanforderungen und -überlegungen für Ihren lokalen Cluster.
## VPC-Anforderungen und -Überlegungen
Wenn Sie einen lokalen Cluster erstellen, muss die von Ihnen angegebene VPC die folgenden Anforderungen und Überlegungen erfüllen:
+ Stellen Sie sicher, dass die VPC über ausreichend IP-Adressen für den lokalen Cluster, alle Knoten und andere Kubernetes-Ressourcen verfügt, die Sie erstellen möchten. Wenn die VPC, die Sie verwenden möchten, nicht über genügend IP-Adressen verfügt, erhöhen Sie die Anzahl der verfügbaren IP-Adressen. Das ist möglich, indem Sie [zusätzliche CIDR-Blöcke (Classless Inter-Domain Routing) mit Ihrer VPC verbinden](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr). Sie können entweder vor oder nach der Erstellung Ihres Clusters private (RFC 1918) und öffentliche (nicht RFC 1918) CIDR-Blöcke mit Ihrer VPC verbinden. Es kann bis zu 5 Stunden dauern, bis ein CIDR-Block, den Sie einem VPC zugeordnet haben, von einem Cluster erkannt wird.
+ Der VPC dürfen keine IP-Präfixe oder IPv6-CIDR-Blöcke zugewiesen werden. Aufgrund dieser Einschränkungen sind die Informationen, die unter [Weitere IP-Adressen mit Präfixen und [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md) für Amazon-EKS-Knoten zuweisen](cni-increase-ip-addresses.md) behandelt werden, für Ihre VPC nicht anwendbar.
+ Die VPC verfügt über einen DNS-Hostnamen und die DNS-Auflösung ist aktiviert. Ohne diese Funktionen kann der lokale Cluster nicht erstellt werden, und Sie müssen die Funktionen aktivieren und Ihren Cluster neu erstellen. Weitere Informationen finden Sie unter [DNS-Attribute für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) im Amazon-VPC-Benutzerhandbuch.
+ Um über Ihr lokales Netzwerk auf Ihren lokalen Cluster zuzugreifen, muss die VPC mit der lokalen Gateway-Routing-Tabelle Ihres Outpost verknüpft sein. Weitere Informationen finden Sie unter [VPC-Zuordnungen](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations) im AWS-Outposts-Benutzerhandbuch.
## Subnetz-Anforderungen und -Überlegungen
Geben Sie beim Erstellen des Clusters mindestens ein privates Subnetz an. Wenn Sie mehr als ein Subnetz angeben, werden die Kubernetes-Steuerebene-Instances gleichmäßig über die Subnetze hinweg verteilt. Wenn mehr als ein Subnetz angegeben wird, müssen die Subnetze auf demselben Outpost vorhanden sein. Darüber hinaus müssen die Subnetze auch über die richtigen Routen und Sicherheitsgruppen-Berechtigungen verfügen, um miteinander kommunizieren zu können. Wenn Sie einen lokalen Cluster erstellen, müssen die von Ihnen angegebenen Subnetze die folgenden Anforderungen erfüllen:
+ Die Subnetze befinden sich alle auf demselben logischen Outpost.
+ Die Subnetze verfügen zusammen über mindestens drei verfügbare IP-Adressen für die Kubernetes-Instances der Steuerebene. Wenn drei Subnetze angegeben werden, muss jedes Subnetz über mindestens eine verfügbare IP-Adresse verfügen. Wenn zwei Subnetze angegeben werden, muss jedes Subnetz über mindestens zwei verfügbare IP-Adressen verfügen. Wenn ein Subnetz angegeben wird, muss das Subnetz über mindestens drei verfügbare IP-Adressen verfügen.
+ Die Subnetze verfügen über eine Weiterleitung zum [lokalen Gateway](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) des Outpost-Racks, um über Ihr lokales Netzwerk auf den Kubernetes-API-Server zugreifen zu können. Wenn Subnetze über keine Weiterleitung zum lokalen Gateway des Outpost-Racks verfügen, müssen Sie von innerhalb der VPC mit Ihrem Kubernetes-API-Server kommunizieren.
+ Die Subnetze müssen eine IP-Adressen-basierte Benennung aufweisen. Die [ressourcenbasierte Benennung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn) von Amazon EC2 wird nicht durch Amazon EKS unterstützt.
## Subnetz-Zugang zu AWS-Services
Die privaten Subnetze des lokalen Clusters in Outposts müssen mit regionalen AWS-Services kommunizieren können. Dazu können Sie ein [NAT-Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) für den ausgehenden Internetzugang verwenden oder, wenn Sie den gesamten Datenverkehr innerhalb Ihrer VPC privat halten möchten, [Schnittstellen-VPC-Endpunkte](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) verwenden.
### Verwenden eines NAT-Gateways
Die privaten Subnetze des lokalen Clusters in Outposts müssen über eine zugeordnete Routing-Tabelle mit einer Weiterleitung zu einem NAT-Gateway verfügen, das sich in einem öffentlichen Subnetz in der übergeordneten Availability Zone des Outposts befindet. Das öffentliche Subnetz muss über eine Route zu einem [Internet-Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) verfügen. Das NAT-Gateway ermöglicht einen ausgehenden Zugriff auf das Internet und verhindert unerwünschte eingehende Verbindungen aus dem Internet zu Instances im Outpost.
### Verwendung von -Schnittstellen-VPC-Endpunkten
Wenn die privaten Subnetze des lokalen Clusters in Outposts keine ausgehende Internetverbindung haben oder wenn Sie den gesamten Datenverkehr innerhalb Ihrer VPC privat halten möchten, müssen Sie die folgenden Schnittstellen-VPC-Endpunkte und den [Gateway-Endpunkt](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) in einem regionalen Subnetz erstellen, bevor Sie Ihren Cluster erstellen.
| Endpunkt | Endpunkttyp |
| --- | --- |
| `com.amazonaws.region-code.ssm` | Schnittstelle |
| `com.amazonaws.region-code.ssmmessages` | Schnittstelle |
| `com.amazonaws.region-code.ec2messages` | Schnittstelle |
| `com.amazonaws.region-code.ec2` | Schnittstelle |
| `com.amazonaws.region-code.secretsmanager` | Schnittstelle |
| `com.amazonaws.region-code.logs` | Schnittstelle |
| `com.amazonaws.region-code.sts` | Schnittstelle |
| `com.amazonaws.region-code.ecr.api` | Schnittstelle |
| `com.amazonaws.region-code.ecr.dkr` | Schnittstelle |
| `com.amazonaws.region-code.s3` | Gateway |
Die Endpunkte müssen die folgenden Anforderungen erfüllen:
+ Sie müssen in einem privaten Subnetz erstellt werden, das sich in der übergeordneten Availability Zone Ihres Outposts befindet.
+ Private DNS-Namen müssen aktiviert sein.
+ Sie müssen über eine angefügte Sicherheitsgruppe verfügen, die eingehenden HTTPS-Datenverkehr aus dem CIDR-Bereich des privaten Outpost-Subnetzes zulässt.
Für die Erstellung von Endpunkten fallen Gebühren an. Weitere Informationen erhalten Sie unter [AWS PrivateLink-Preise](https://aws.amazon.com/privatelink/pricing/). Wenn Ihre Pods Zugriff auf andere AWS-Services benötigen, müssen Sie zusätzliche Endpunkte erstellen. Eine umfassende Liste der Endpunkte finden Sie unter [AWS-Services, die in AWS PrivateLink integriert sind](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html).
## Erstellen einer VPC
Sie können eine VPC erstellen, welche die oben genannten Anforderungen erfüllt, indem Sie eine der folgenden AWS-CloudFormation-Vorlagen verwenden:
+ ** [Vorlage 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml) ** – Diese Vorlage erstellt eine VPC mit einem privaten Subnetz in dem Outpost und einem öffentlichen Subnetz in der AWS-Region. Das private Subnetz verfügt über eine Weiterleitung zum Internet über ein NAT-Gateway, das sich im öffentlichen Subnetz in der AWS-Region befindet. Diese Vorlage kann verwendet werden, um einen lokalen Cluster in einem Subnetz mit ausgehendem Internetzugriff zu erstellen.
+ **[Vorlage 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)** – Diese Vorlage erstellt eine VPC mit einem privaten Subnetz in dem Outpost und der Mindestanzahl von VPC-Endpunkten, die erforderlich sind, um einen lokalen Cluster in einem Subnetz zu erstellen, das über keinen eingehenden oder ausgehenden Internetzugriff verfügt (auch als privates Subnetz bezeichnet).
# Vorbereitung lokaler Amazon-EKS-Cluster in AWS Outposts für Netzwerkunterbrechungen
Wenn Ihr lokales Netzwerk die Verbindung zur AWS Cloud verloren hat, können Sie Ihren lokalen Amazon-EKS-Cluster weiterhin in einem Outpost verwenden. In diesem Thema wird beschrieben, wie Sie Ihren lokalen Cluster auf Netzwerkunterbrechungen vorbereiten können, und verwandte Überlegungen.
+ Lokale Cluster gewährleisten Stabilität und einen unterbrechungsfreien Betrieb bei vorübergehenden, ungeplanten Netzwerkausfällen. AWS Outposts bleibt ein vollständig verbundenes Angebot, das als Erweiterung der AWS Cloud in Ihrem Rechenzentrum fungiert. Im Falle einer Netzwerkunterbrechung zwischen Ihrem Outpost und der AWS Cloud empfehlen wir, die Verbindung wiederherzustellen. Eine Anleitung dazu finden Sie in der [Checkliste zur Fehlerbehebung im AWS-Rack-Netzwerk](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) im * AWS-Outposts-Benutzerhandbuch*. Weitere Informationen zum Beheben von Problemen mit lokalen Clustern finden Sie unter [Fehlerbehebung bei lokalen Amazon EKS-Clustern auf AWS Outposts](eks-outposts-troubleshooting.md).
+ Outposts geben eine `ConnectedStatus`-Metrik aus, mit der Sie den Konnektivitätsstatus Ihres Outposts überwachen können. Weitere Informationen finden Sie unter [Outposts-Metriken](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) im * AWS-Benutzerhandbuch*.
+ Lokale Cluster verwenden IAM als standardmäßigen Authentifizierungsmechanismus mit dem [AWS Authenticator Identity and Access Management für Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator). IAM ist während Netzwerkunterbrechungen nicht verfügbar. Daher unterstützen lokale Cluster einen alternativen Authentifizierungsmechanismus mithilfe von `x.509`-Zertifikaten, die Sie verwenden können, um eine Verbindung zu Ihrem Cluster herzustellen, wenn die Netzwerkverbindung unterbrochen ist. Informationen zum Abrufen und Verwenden eines `x.509`-Zertifikats für Ihren Cluster finden Sie unter [Authentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung](#outposts-network-disconnects-authentication).
+ Wenn Sie bei Netzwerkunterbrechungen nicht auf Route 53 zugreifen können, sollten Sie lokale DNS-Server in Ihrer On-Premises-Umgebung verwenden. Die Kubernetes-Instances der Steuerebene verwenden statische IP-Adressen. Sie können die Hosts, die Sie für die Verbindung mit Ihrem Cluster verwenden, mit dem Hostnamen und den IP-Adressen des Endpunkts als Alternative zur Verwendung lokaler DNS-Server konfigurieren. Weitere Informationen finden Sie unter [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) im * AWS-Outposts-Benutzerhandbuch*.
+ Wenn Sie bei Netzwerkunterbrechungen mit einem Anstieg des Anwendungsdatenverkehrs rechnen, können Sie in Ihrem Cluster bei Verbindung mit der Cloud freie Rechenkapazität bereitstellen. Amazon-EC2-Instances sind im Preis von AWS Outposts enthalten. Der Betrieb von Ersatz-Instances hat also keinen Einfluss auf Ihre AWS-Nutzungskosten.
+ Während Netzwerkunterbrechungen, die das Erstellen, Aktualisieren und Skalieren von Workloads ermöglichen, müssen die Container-Images Ihrer Anwendung über das lokale Netzwerk zugänglich sein und Ihr Cluster muss über genügend Kapazität verfügen. Lokale Cluster hosten keine Container-Registry für Sie. Wenn die Pods zuvor auf diesen Knoten ausgeführt wurden, werden Container-Images auf den Knoten zwischengespeichert. Wenn Sie die Container-Images Ihrer Anwendung in der Regel aus Amazon ECR in der Cloud beziehen, sollten Sie erwägen, einen lokalen Cache oder eine lokale Registry auszuführen. Ein lokaler Cache oder eine lokale Registry ist hilfreich, wenn Sie während einer Netzwerkunterbrechung Workload-Ressourcen erstellen, aktualisieren und skalieren müssen.
+ Lokale Cluster verwenden Amazon EBS als Standardspeicherklasse für persistente Volumes und den Amazon-EBS-CSI-Treiber, um den Lebenszyklus persistenter Amazon-EBS-Volumes zu verwalten. Während Netzwerkunterbrechungen können Pods, die von Amazon EBS gesichert werden, nicht erstellt, aktualisiert oder skaliert werden. Dies liegt daran, dass diese Vorgänge Aufrufe an die Amazon-EBS-API in der Cloud erfordern. Wenn Sie statusbehaftete Workloads auf lokalen Clustern bereitstellen und während Netzwerktrennungen Vorgänge zum Erstellen, Aktualisieren oder Skalieren benötigen, sollten Sie die Verwendung eines alternativen Speichermechanismus in Betracht ziehen.
+ Amazon-EBS-Snapshots können nicht erstellt oder gelöscht werden, wenn AWS Outposts kein Zugriff auf die relevanten AWS-APIs in der Region (z. B. die APIs für Amazon EBS oder Amazon S3) möglich ist.
+ Bei der Integration von ALB (Ingress) mit AWS Certificate Manager (ACM) werden Zertifikate übertragen und im Speicher der ALB-Rechen-Instance von AWS Outposts gespeichert. Die aktuelle TLS-Terminierung wird im Falle einer Trennung von der AWS-Region weiter betrieben. Mutationsvorgänge in diesem Kontext schlagen fehl (z. B. neue Eingangsdefinitionen, neue API-Vorgänge für ACM-basierte Zertifikate, ALB-Rechenskalierung oder Zertifikatsrotation). Weitere Informationen finden Sie unter [Problembehandlung bei der Erneuerung verwalteter Zertifikate](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) im * Benutzerhandbuch zum AWS-Zertifikatsmanager*.
+ Die Protokolle der Amazon-EKS-Steuerebene werden während Netzwerkunterbrechungen lokal auf Kubernetes-Instances der Steuerebene zwischengespeichert. Nach der erneuten Verbindung werden die Protokolle an CloudWatch Logs in der übergeordneten AWS-Region gesendet. Sie können [Prometheus](https://prometheus.io/)-, [Grafana](https://grafana.com/)- oder Amazon-EKS-Partnerlösungen verwenden, um den Cluster lokal mithilfe des Metrik-Endpunkts des Kubernetes-API-Servers oder mithilfe von Fluent Bit für Protokolle zu überwachen.
+ Wenn Sie AWS Load Balancer Controller in Outposts für den Anwendungsdatenverkehr verwenden, erhalten vorhandene Pods, denen das AWS Load Balancer Controller vorangestellt ist, während der Netzwerkunterbrechung weiterhin Datenverkehr. Neue Pods, die bei Netzwerkunterbrechungen erstellt wurden, empfangen keinen Datenverkehr, bis der Outpost wieder mit der AWS Cloud verbunden ist. Erwägen Sie, die Replikatanzahl für Ihre Anwendungen festzulegen, während Sie mit der AWS Cloud verbunden sind, um Ihre Skalierungsanforderungen während Netzwerktrennungen zu erfüllen.
+ Das Amazon-VPC-CNI-Plugin für Kubernetes ist standardmäßig auf den [sekundären IP-Modus](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview) eingestellt. Es ist mit `WARM_ENI_TARGET` = `1` konfiguriert, wodurch das Plugin „eine vollständige elastische Netzwerkschnittstelle“ mit verfügbaren IP-Adressen bereithalten kann. Erwägen Sie, `WARM_ENI_TARGET`-, `WARM_IP_TARGET`- und `MINIMUM_IP_TARGET`-Werte entsprechend Ihren Skalierungsanforderungen während eines getrennten Zustands zu ändern. Weitere Informationen finden Sie in der Datei [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) für das Plugin auf GitHub. Eine Liste der maximalen Anzahl von Pods, die von jedem Instance-Typ unterstützt werden, finden Sie in der Datei [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) auf GitHub.
## Authentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung
AWS Identity and Access Management (IAM) ist bei Netzwerkunterbrechungen nicht verfügbar. Sie können sich nicht bei Ihrem lokalen Cluster mit IAM-Anmeldeinformationen authentifizieren, während keine Verbindung besteht. Sie können jedoch über Ihr lokales Netzwerk mithilfe von `x509`-Zertifikaten eine Verbindung zu Ihrem Cluster herstellen, wenn die Verbindung getrennt ist. Sie müssen ein Client `X509`-Zertifikat herunterladen und speichern, das Sie während der Verbindungstrennung verwenden können. In diesem Thema erfahren Sie, wie Sie das Zertifikat erstellen und verwenden, um sich bei Ihrem Cluster zu authentifizieren, wenn dieser sich in einem nicht verbundenen Status befindet.
1. Erstellen einer Zertifikatssignierungsanforderung
1. Generieren einer Zertifikatssignierungsanforderung.
```
openssl req -new -newkey rsa:4096 -nodes -days 365 \
-keyout admin.key -out admin.csr -subj "/CN=admin"
```
1. Erstellen Sie eine Anfrage zur Zertifikatssignierung in Kubernetes.
```
BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: admin-csr
spec:
signerName: kubernetes.io/kube-apiserver-client
request: ${BASE64_CSR}
usages:
- client auth
EOF
```
1. Erstellen einer Zertifikatssignierungsanforderung mit `kubectl`.
```
kubectl create -f admin-csr.yaml
```
1. Überprüfen Sie den Status der Zertifikatssignierungsanforderung.
```
kubectl get csr admin-csr
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Pending
```
Kubernetes hat die Anfrage zur Zertifikatsignierung erstellt.
1. Genehmigen Sie die Zertifikatssignieranforderung.
```
kubectl certificate approve admin-csr
```
1. Überprüfen Sie erneut den Status der Anfrage zum Signieren des Zertifikats auf Genehmigung.
```
kubectl get csr admin-csr
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Approved
```
1. Rufen Sie das Zertifikat ab und überprüfen Sie es.
1. Rufen Sie das Zertifikat ab.
```
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
```
1. Überprüfen Sie das Zertifikat.
```
cat admin.crt
```
1. Erstellen Sie eine Cluster-Rollenbindung für einen `admin`-Benutzer.
```
kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
--user=admin --group=system:masters
```
1. Generieren Sie eine kubeconfig mit Benutzerbereich für einen getrennten Status.
Sie können eine `kubeconfig`-Datei mit den heruntergeladenen `admin`-Zertifikaten generieren. Ersetzen Sie *my-cluster* und *apiserver-endpoint* in den folgenden Befehlen.
```
aws eks describe-cluster --name my-cluster \
--query "cluster.certificateAuthority" \
--output text | base64 --decode > ca.crt
```
```
kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
--certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
--client-certificate=admin.crt --client-key=admin.key --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
--cluster my-cluster --user admin
```
```
kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
```
1. Ziegen Sie Ihre `kubeconfig`-Datei an.
```
kubectl get nodes --kubeconfig admin.kubeconfig
```
1. Wenn Sie bereits über Services in Produktion auf Ihrem Outpost verfügen, überspringen Sie diesen Schritt. Wenn Amazon EKS der einzige Service ist, der in Ihrem Outpost ausgeführt wird, und der Outpost sich nicht in der Produktion befindet, können Sie eine Netzwerkunterbrechung simulieren. Bevor Sie mit Ihrem lokalen Cluster in Produktion gehen, simulieren Sie einen Verbindungsabbruch, um sicherzustellen, dass Sie auf Ihren Cluster zugreifen können, wenn er sich in einem getrennten Status befindet.
1. Wenden Sie Firewall-Regeln auf die Netzwerkgeräte an, die Ihren Outpost mit der AWS-Region verbinden. Dadurch wird der Service-Link des Outposts getrennt. Sie können keine neuen Instances erstellen. Aktuell ausgeführte Instances verlieren die Konnektivität zur AWS-Region und zum Internet.
1. Sie können die Verbindung zu Ihrem lokalen Cluster testen, während die Verbindung getrennt ist, indem Sie das `x509`-Zertifikat verwenden. Stellen Sie sicher, dass Sie Ihr `kubeconfig` in das `admin.kubeconfig` ändern, das Sie in einem vorherigen Schritt erstellt haben. Ersetzen Sie *my-cluster* durch den Namen Ihres lokalen Clusters.
```
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
```
Wenn Sie Probleme mit Ihren lokalen Clustern feststellen, während diese sich im getrennten Status befinden, empfehlen wir Ihnen, ein Support-Ticket zu erstellen.
# Wählen Sie Instance-Typen und Platzierungsgruppen für Amazon-EKS-Cluster in AWS Outposts basierend auf Kapazitätsüberlegungen aus.
Dieses Thema enthält Anleitungen zur Auswahl des Instance-Typs der Kubernetes-Steuerebene und (optional) zur Verwendung von Platzierungsgruppen, um Hochverfügbarkeitsanforderungen für Ihren lokalen Amazon-EKS-Cluster in einem Outpost zu erfüllen.
Bevor Sie einen Instance-Typ (z. B. `m5`, `c5`, oder `r5`) auswählen, den Sie für die Kubernetes-Steuerebene Ihres lokalen Clusters in Outposts verwenden möchten, überprüfen Sie die Instance-Typen, die in Ihrer Outpost-Konfiguration verfügbar sind. Nachdem Sie die verfügbaren Instance-Typen identifiziert haben, wählen Sie die Instance-Größe (z. B. `large`, `xlarge`, oder `2xlarge`) basierend auf der Anzahl der Knoten, die Ihr Workload benötigt. Die folgende Tabelle enthält Empfehlungen für die Auswahl einer Instance-Größe.
**Anmerkung**
Die Instance-Größen müssen auf Ihren Outposts eingestellt werden. Stellen Sie sicher, dass Sie über genügend Kapazität für drei Instances der auf Ihren Outposts verfügbaren Größe für die Lebensdauer Ihres lokalen Clusters verfügen. Eine Liste der verfügbaren Amazon-EC2-Instance-Typen finden Sie in den Abschnitten „Rechenleistung“ und „Speicher“ unter [AWS-Outposts-Rack-Features](https://aws.amazon.com/outposts/rack/features/).
| Anzahl der Knoten | Instance-Größe der Kubernetes-Steuerebene |
| --- | --- |
| 1–20 | `large` |
| 21–100 | `xlarge` |
| 101–250 | `2xlarge` |
| 251–500 | `4xlarge` |
Der Speicher für die Kubernetes-Steuerebene erfordert 246 GB Amazon EBS-Speicher für jeden lokalen Cluster, um die erforderlichen IOPS von `etcd` zu erfüllen. Bei der Erstellung des lokalen Clusters werden die Amazon-EBS-Volumes automatisch für Sie bereitgestellt.
## Platzierung der Steuerebene
Wenn Sie keine Platzierungsgruppe mit der `OutpostConfig.ControlPlanePlacement.GroupName`-Eigenschaft angeben, erhalten die für Ihre Kubernetes-Steuerebene bereitgestellten Amazon-EC2-Instances keine spezifische Durchsetzung der Hardware-Platzierung über die zugrunde liegende Kapazität, die in Ihrem Outpost verfügbar ist.
Sie können Platzierungsgruppen verwenden, um die Hochverfügbarkeitsanforderungen für Ihren lokalen Amazon EKS-Cluster auf einem Outpost zu erfüllen. Indem Sie bei der Cluster-Erstellung eine Platzierungsgruppe angeben, beeinflussen Sie die Platzierung der Instances der Kubernetes-Steuerebene. Die Instances sind auf unabhängige zugrundeliegende Hardware (Racks oder Hosts) verteilt, wodurch die Auswirkungen korrelierter Instances bei Hardwareausfällen minimiert werden.
Die Art der Verteilung, die Sie konfigurieren können, hängt von der Anzahl der Outpost-Racks in Ihrer Bereitstellung ab.
+ **Bereitstellungen mit einem oder zwei physischen Racks in einem einzelnen logischen Outpost** – Sie müssen über mindestens drei Hosts verfügen, die mit dem Instance-Typ konfiguriert sind, den Sie für Ihre Instances der Kubernetes-Steuerebene auswählen. Eine *Spread*-Placement-Gruppe, die eine Verteilung auf *Host-Ebene* verwendet, stellt sicher, dass alle Instances der Kubernetes-Steuerebene auf verschiedenen Hosts innerhalb der zugrunde liegenden Racks ausgeführt werden, die in Ihrer Outpost-Bereitstellung verfügbar sind.
+ **Bereitstellungen mit drei oder mehr physischen Racks in einem einzigen logischen Outpost** – Sie müssen mindestens drei Hosts mit dem Instance-Typ konfiguriert haben, den Sie für Ihre Instances der Kubernetes-Steuerebene auswählen. Eine *Spread*-Placement-Gruppe, die eine *Verteilung auf Rack-Ebene* verwendet, stellt sicher, dass alle Instances der Kubernetes-Steuerebene auf unterschiedlichen Racks in Ihrer Outpost-Bereitstellung ausgeführt werden. Sie können alternativ die *auf Host-Ebene verteilte* Platzierungsgruppe verwenden, wie in der vorherigen Option beschrieben.
Sie sind für die Erstellung der gewünschten Platzierungsgruppe verantwortlich. Sie geben die Platzierungsgruppe an, wenn Sie die `CreateCluster`-API aufrufen. Weitere Informationen zu Platzierungsgruppen und deren Erstellung finden Sie unter [Platzierungsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) im Amazon-EC2-Benutzerhandbuch.
+ Wenn eine Platzierungsgruppe angegeben wird, muss verfügbare Slot-Kapazität auf Ihrem Outpost vorhanden sein, um erfolgreich einen lokalen Amazon-EKS-Cluster zu erstellen. Die Kapazität variiert je nachdem, ob Sie den Host- oder Rack-Spread-Typ verwenden. Wenn nicht genügend Kapazität vorhanden ist, verbleibt der Cluster im `Creating`-Zustand. Sie können das `Insufficient Capacity Error` auf dem Zustandsfeld der [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)-API-Reaktion überprüfen. Sie müssen Kapazität freigeben, damit der Erstellungsprozess fortgesetzt werden kann.
+ Während der Plattform- und Versionsaktualisierungen des Amazon-EKS-Clusters werden die Instances der Kubernetes-Steuerebene aus Ihrem Cluster durch neue Instances ersetzt, die eine fortlaufende Aktualisierungsstrategie verwenden. Während dieses Ersetzungsprozesses wird jede Instance der Steuerebene beendet, wodurch ihr jeweiliger Slot freigegeben wird. Eine neue aktualisierte Instance wird an ihrer Stelle bereitgestellt. Die aktualisierte Instance wird möglicherweise in den freigegebenen Slot platziert. Wenn der Slot von einer anderen unabhängigen Instance verbraucht wird und keine Kapazität mehr vorhanden ist, die die erforderliche verteilte Topologieanforderung erfüllt, verbleibt der Cluster im `Updating`-Zustand. Sie können das entsprechende `Insufficient Capacity Error` im Zustandsfeld der [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)-API-Reaktion anzeigen. Sie müssen Kapazitäten freigeben, damit der Aktualisierungsprozess fortschreiten und vorherige Hochverfügbarkeitsniveaus wiederherstellen kann.
+ Sie können in jeder Region maximal 500 Platzierungsgruppen pro Konto in jeder AWS-Region erstellen. Weitere Informationen finden Sie unter [Allgemeine Regeln und Einschränkungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general) im Amazon-EC2-Benutzerhandbuch.
# Fehlerbehebung 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-Steuerebeneninstanz, die auf Outpost läuft, es sei denn, Sie werden ausdrücklich vom Support dazu aufgefordert. AWS Das Beenden dieser Instances stellt ein Risiko für die Verfügbarkeit des lokalen Cluster-Services dar, einschließlich des Verlusts des lokalen Clusters, falls mehrere Instances gleichzeitig beendet werden. Instanzen der lokalen `Kubernetes` EKS-Cluster-Steuerebene werden durch das Tag auf der Instanzkonsole identifiziert. `eks-local:controlplane-name` EC2
## 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
Probleme mit lokalen Clustern können mit dem Amazon [AWS EKS-CLI-Befehl describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) erkannt werden. Probleme mit lokalen Clustern werden durch das `cluster.health`-Feld der Antwort des `describe-cluster`-Befehls angezeigt. Die in diesem Feld enthaltene Nachricht enthält einen Fehlercode, eine beschreibende Meldung und eine zugehörige Ressource. IDs Diese Informationen sind nur über die Amazon EKS-API und AWS CLI verfügbar. Im folgenden Beispiel ersetzen Sie es *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` | Das gesamte bereitgestellte Subnetz IDs |
| Bereitgestellte Subnetze gehören nicht zur selben VPC. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | Alles bereitgestellte 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 EC2 Amazon-Instance auf Kontrollebene beendet oder `run-instance` waren erfolgreich, aber der beobachtete Status hat sich geändert`Terminated`. Dies kann für einen bestimmten Zeitraum passieren, nachdem Ihr Outpost wieder eine Verbindung hergestellt hat und interne Amazon EBS-Fehler dazu führen, dass ein EC2 interner Amazon-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 und ein Outpost von der Region getrennt wird. AWS | `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 der Amazon EC2 API zurückgegebene Fehlermeldung | Ziel-VPC-ID |
| Ihr Konto hat Ihr Kontingent für die elastische Netzwerkschnittstelle überschritten. | `ResourceLimitExceeded` | Von der Amazon EC2 API zurückgegebene Fehlermeldung | Ziel-Subnetz-ID |
| Instanzen der Kontrollebene waren über AWS Systems Manager nicht erreichbar. Informationen zur Lösung finden Sie unter [Instanzen der Kontrollebene sind über AWS Systems Manager nicht erreichbar](#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. | EC2 Amazon-Instanz IDs |
| Beim Abrufen von Details für eine verwaltete Sicherheitsgruppe oder eine elastische Netzwerkschnittstelle ist ein Fehler aufgetreten. | Basiert auf dem EC2 Amazon-Client-Fehlercode. | Von der 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. | Basiert auf dem EC2 Amazon-Client-Fehlercode. | Von der 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. | Basiert auf dem EC2 Amazon-Client-Fehlercode. | Von der 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 „Integrität“ der `describe-cluster` Antwort aufgeführt sind.
| EC2 Amazon-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 beobachtet, wenn eine EC2 Amazon-Instance in einem neuen Konto erstellt wird. 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 im 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, ob der Cluster-Rolle, die Sie verwenden, die von [Amazon EKSLocal OutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) verwaltete Richtlinie zugeordnet ist. Alle anderen API-Aufrufe erfordern dieselben Berechtigungen wie Amazon-EKS-Cluster in der Cloud.
## Cluster bleibt im `CREATING`-Zustand hängen
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 von der AWS Region aus, in der sich Systems Manager befindet, keine Verbindung zur Kontrollebeneninstanz 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.
+ 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 Richtlinie für benutzerverwaltete Schlüssel der Clusterrolle die erforderlichen Berechtigungen 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: Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) aus der Rolle entfernt EKSLocal OutpostClusterPolicy 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.
**VPC- und Subnetz-DNS-Konfiguration ist falsch konfiguriert oder fehlt**
Lesen [Sie den Artikel VPC und Subnetze für Amazon EKS-Cluster auf AWS Outposts erstellen](eks-outposts-vpc-subnet-requirements.md).
## Cluster bleibt im `UPDATING`-Zustand hängen
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 Outposts AWS](eks-outposts-platform-versions.md).
Während einer automatischen Einführung der Plattformversion ändert sich der Cluster-Status zu `UPDATING`. Der Aktualisierungsprozess besteht aus dem Austausch aller Kubernetes- Steuerebenen-Instances durch neue Instances, welche die neuesten Sicherheits-Patches und Fehlerkorrekturen 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. Daher wird der Aktualisierungsvorgang angehalten, um den lokalen Cluster-Service vor Unterbrechungen zu schützen.
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 AWS Support dazu aufgefordert werden. Dies ist besonders wichtig für lokale Cluster, die in einem bestimmten `UPDATING`-Status hängen geblieben sind, da eine hohe Wahrscheinlichkeit besteht, dass ein anderer Steuerebenen-Knoten nicht vollständig fehlerfrei ist. Das Beenden der falschen Instances kann zu einer Service-Unterbrechung und dem Risiko eines Datenverlusts im lokalen Cluster führen.
Die am häufigsten auftretenden Probleme sind:
+ Eine oder mehrere Steuerebenen-Instances können keine Verbindung zum System Manager herstellen, da sich die Netzwerkkonfiguration seit der Erstellung des lokalen Clusters geändert hat. 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 Richtlinie für benutzerverwaltete Schlüssel der Clusterrolle die erforderlichen Berechtigungen 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 [Subnetz-Zugang zu AWS-Services](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: Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) nicht aus der Rolle entfernt EKSLocal OutpostClusterPolicy 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 Amazon EKS-optimiertes Amazon Linux 2 AMIs wird unterstützt (`amazon-linux-2`,`amazon-linux-2-gpu`,`amazon-linux-2-arm64`). Wenn Sie versuchen, AL2 023 Knoten mit EKS LocalClusters auf AWS Outposts zu verbinden, können die Knoten dem Cluster nicht beitreten. Weitere Informationen finden Sie unter [Amazon Linux-Knoten auf AWS Outposts erstellen](eks-outposts-self-managed-nodes.md).
+ Wenn Sie zum Erstellen Ihrer Knoten eine AWS CloudFormation Vorlage verwendet haben, stellen Sie sicher, dass sie kein nicht unterstütztes AMI verwendet.
+ Fehlt der AWS IAM-Authenticator `ConfigMap` — Falls er fehlt, müssen Sie ihn erstellen. Weitere Informationen finden Sie unter [Anwenden von `aws-auth` `ConfigMap` auf Ihren Cluster](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 , sodass bei jeder Verwendung des Stacks eine neue Sicherheitsgruppe zulässig ist.
+ 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 für Netzwerkunterbrechungen vorbereiten](eks-outposts-network-disconnects.md). Wenn Sie auf andere Probleme stoßen, wenden Sie sich an den AWS 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-Steuerungsebeneninstanzen sammeln und sie zur weiteren Untersuchung an den AWS Support senden.
## Instanzen der Kontrollebene sind über AWS Systems Manager nicht erreichbar
Wenn die Amazon EKS Control Plane 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 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](eks-outposts-vpc-subnet-requirements.md) erfüllen und dass Sie die Schritte unter [Setup Session Manager im Systems Manager Manager-Benutzerhandbuch](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) ausgeführt haben. AWS
# Amazon Linux-Knoten auf AWS Outposts erstellen
**Wichtig**
Amazon EKS Local Clusters on Outposts unterstützt nur Knoten, die aus dem folgenden Amazon EKS-optimierten Amazon Linux 2023 erstellt wurden: AMIs
Standard Amazon Linux 2023 (`amazon-linux-2023/x86_64/standard`)
Beschleunigtes Nvidia Amazon Linux 2023 (`amazon-linux-2023/x86_64/nvidia`)
Beschleunigtes Neuron Amazon Linux 2023 () `amazon-linux-2023/x86_64/neuron`
AWS Der Support für EKS AL2 — optimiert und AL2 beschleunigt — AMIs wurde mit Wirkung zum 26. November 2025 eingestellt. Sie können EKS zwar auch AL2 AMIs nach dem end-of-support (EOS-) Datum (26. November 2025) weiter verwenden, aber EKS wird nach diesem Datum keine neuen Kubernetes-Versionen oder Updates mehr veröffentlichen AL2 AMIs, einschließlich kleinerer Releases, Patches und Bugfixes. Weitere Informationen zu veralteten Versionen finden Sie [hier](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html). AL2
Dieses Thema beschreibt Hinweise zum Starten von Auto-Scaling-Gruppen von Amazon-Linux-Knoten auf einem Outpost, die mit Ihrem Amazon-EKS-Cluster registriert sind. Der Cluster kann sich in der AWS Cloud oder in einem Outpost befinden.
+ Ein vorhandener Outpost. Weitere Informationen finden Sie unter [Was sind AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ Ein vorhandener Amazon-EKS-Cluster. Informationen zur Bereitstellung eines Clusters in der AWS Cloud finden Sie unter[Amazon-EKS-Cluster erstellen](create-cluster.md). Informationen zum Bereitstellen eines Clusters in einem Outpost finden Sie unter [Erstellung lokaler Amazon-EKS-Cluster in AWS Outposts für hohe Verfügbarkeit](eks-outposts-local-cluster-overview.md).
+ Angenommen, Sie erstellen Ihre Knoten in einem Cluster in der AWS Cloud und Sie haben Subnetze in der AWS Region, in der Sie AWS Outposts, AWS Wavelength oder AWS Local Zones aktiviert haben. Diese Subnetze dürfen dann bei der Erstellung Ihres Clusters nicht angegeben worden sein. Wenn Sie Ihre Knoten in einem Cluster in einem Outpost erstellen, müssen Sie bei der Erstellung Ihres Clusters ein Outpost-Subnetz angegeben haben.
+ (Empfohlen für Cluster in der AWS Cloud) Das Amazon VPC CNI-Plug-In für Kubernetes ist mit einer eigenen IAM-Rolle konfiguriert, der die erforderliche IAM-Richtlinie zugeordnet ist. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). Lokale Cluster unterstützen keine IAM-Rollen für Service-Konten.
Sie können eine selbstverwaltete Amazon Linux-Knotengruppe mit `eksctl` oder AWS-Managementkonsole (mit einer AWS CloudFormation Vorlage) erstellen. Sie können auch Terraform verwenden.
Sie können eine selbstverwaltete Knotengruppe für einen lokalen Cluster mit den folgenden Tools erstellen, die auf dieser Seite beschrieben sind:
+ [`eksctl`](#eksctl_create_nodes_outpost)
+ [AWS-Managementkonsole](#console_create_nodes_outpost)
**Wichtig**
Die selbstverwaltete Knotengruppe umfasst EC2 Amazon-Instances in Ihrem Konto. Diese Instances werden nicht automatisch aktualisiert, wenn Sie oder Amazon EKS die Version der Steuerebene in Ihrem Namen aktualisieren. Für eine selbstverwaltete Knotengruppe gibt es in der Konsole keinen Hinweis darauf, dass sie aktualisiert werden muss. Sie können die auf einem Knoten installierte `kubelet`-Version anzeigen, indem Sie den Knoten in der Liste **Knoten** auf der Registerkarte **Übersicht** Ihres Clusters auswählen, um zu bestimmen, welche Knoten aktualisiert werden müssen. Sie müssen die Knoten manuell aktualisieren. Weitere Informationen finden Sie unter [Selbstverwaltete Knoten für Ihren Cluster aktualisieren](update-workers.md).
Die von kubelet auf Ihren selbstverwalteten Knoten verwendeten Zertifikate werden mit einer Gültigkeitsdauer von einem Jahr ausgestellt. Standardmäßig ist die Zertifikatsrotation **nicht** aktiviert (siehe: https://kubernetes). io/docs/reference/config-api/kubelet-config.v1beta1/\$1 kubelet-config-k 8 s-io-v 1beta1-KubeletConfiguration), das heißt, wenn Sie einen selbstverwalteten Knoten haben, der länger als ein Jahr läuft, kann er sich nicht mehr bei der Kubernetes-API authentifizieren.
Als bewährte Methode empfehlen wir Kunden, ihre selbstverwalteten Knotengruppen regelmäßig zu aktualisieren, um Sicherheitspatches von den neuesten für Amazon EKS optimierten AMI zu erhalten CVEs . Die Aktualisierung der AMI, die in selbstverwalteten Knotengruppen verwendet wird, löst auch die Neuerstellung von Knoten aus und stellt sicher, dass sie nicht aufgrund abgelaufener Kubelet-Zertifikate in Konflikt geraten.
Alternativ können Sie auch die Rotation von Client-Zertifikaten aktivieren (siehe: https://kubernetes). io/docs/tasks/tls/certificate-rotation/) beim Erstellen der selbstverwalteten Knotengruppen, um sicherzustellen, dass Kubelet-Zertifikate erneuert werden, wenn das aktuelle Zertifikat bald abläuft.
## `eksctl`
**Um selbstverwaltete Linux-Knoten zu starten mit `eksctl`**
1. Installieren Sie die Version `0.215.0` oder höher des auf Ihrem Gerät installierten `eksctl` Befehlszeilentools oder AWS CloudShell. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
1. Wenn sich Ihr Cluster in der AWS Cloud befindet und die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Dienstkonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). Wenn sich Ihr Cluster in Ihrem Outpost befindet, muss die Richtlinie an Ihre Knotenrolle angehängt sein.
1. Der folgende Befehl erstellt eine Knotengruppe in einem bestehenden Cluster. Der Cluster muss mit `eksctl` erstellt worden sein. Ersetzen Sie *al-nodes* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der Region und des Kontos, in dem Sie den Cluster erstellen, eindeutig sein. AWS AWS Wenn Ihr Cluster auf einem Outpost existiert, ersetzen Sie *id* mit der ID eines Outpost-Subnetzes. Wenn Ihr Cluster in der AWS Cloud vorhanden ist, *id* ersetzen Sie ihn durch die ID eines Subnetzes, das Sie bei der Erstellung Ihres Clusters nicht angegeben haben. Ersetzen Sie die verbleibenden Beispielwerte durch Ihre eigenen Werte. Die Knoten werden standardmäßig mit derselben Kubernetes-Version wie die Steuerungsebene erstellt.
Ersetzen Sie *instance-type* durch einen Instance-Typ, der auf Ihrem Outpost verfügbar ist.
*my-key*Ersetzen Sie es durch den Namen Ihres EC2 Amazon-Schlüsselpaars oder öffentlichen Schlüssels. Dieser Schlüssel wird für den SSH-Zugriff zu Ihren Knoten verwendet, nachdem diese gestartet wurden. Wenn Sie noch kein EC2 Amazon-Schlüsselpaar haben, können Sie eines in der erstellen AWS-Managementkonsole. Weitere Informationen finden Sie unter [ EC2 Amazon-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im * EC2 Amazon-Benutzerhandbuch*.
Erstellen Sie Ihre Knoten-Gruppe mit dem folgenden Befehl.
```
eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \
--nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \
--node-volume-type gp2 --subnet-ids subnet-id \
--node-ami-family AmazonLinux2023
```
Wenn Ihr Cluster in der AWS Cloud bereitgestellt ist:
+ Die von Ihnen bereitgestellte Knotengruppe kann `IPv4`-Adressen an Pods aus einem anderen CIDR-Block als dem der Instance zuweisen. Weitere Informationen finden Sie unter [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md).
+ Die von Ihnen bereitgestellte Knotengruppe benötigt keinen ausgehenden Internetzugriff. Weitere Informationen finden Sie unter [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md).
Eine vollständige Liste aller verfügbaren Optionen und Standardwerte finden Sie unter [Support für AWS Outposts](https://eksctl.io/usage/outposts/) in der `eksctl`-Dokumentation.
+ Wenn Knoten dem Cluster nicht beitreten können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) [Beheben von Problemen mit Amazon EKS-Clustern und -Knoten und](troubleshooting.md) unter [Problembehandlung [Knoten können keinem Cluster beitreten](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) bei lokalen Amazon EKS-Clustern auf AWS Outposts](eks-outposts-troubleshooting.md).
+ Eine Beispielausgabe sieht wie folgt aus. Mehrere Zeilen werden ausgegeben, während die Knoten erstellt werden. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Linux-Worker-Knoten zu testen.
## AWS-Managementkonsole
**Schritt 1: Selbstverwaltete Linux-Knoten mit AWS-Managementkonsole starten **
1. Laden Sie die neueste Version der AWS CloudFormation Vorlage herunter.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml
```
1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie **Create stack** (Stack erstellen) und dann **With new resources (standard)** (Mit neuen Ressourcen [Standard]) aus.
1. Wählen Sie für **Specify template** (Vorlage festlegen) **Upload a template file** (Vorlagendatei hochladen) aus und wählen Sie dann **Choose file** (Datei wählen). Wählen Sie die `amazon-eks-nodegroup.yaml`-Datei aus, die Sie in einem vorherigen Schritt heruntergeladen haben, und wählen Sie dann **Next** (Weiter) aus.
1. Geben Sie auf der Seite **Specify stack details** (Stack-Details angeben) die folgenden Parameter ein und klicken Sie dann auf **Next** (Weiter):
+ **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren AWS CloudFormation Stack. Sie können ihn beispielsweise *al-nodes* nennen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein.
+ **ApiServerEndpoint**: Geben Sie den Kubernetes API-Server-Endpunkt ein, der in der EKS-Konsole oder über DescribeCluster die API sichtbar ist.
+ **ClusterName**: Geben Sie den Namen Ihres Clusters ein. Wenn dieser Name nicht mit Ihrem Cluster-Namen übereinstimmt, können Ihre Knoten dem Cluster nicht beitreten.
+ **ClusterId**: Geben Sie die ID ein, die dem Cluster vom EKS-Dienst zugewiesen wurde. Sichtbar über DescribeCluster API. Wenn diese ID nicht mit Ihrer Cluster-ID übereinstimmt, können Ihre Knoten dem Cluster nicht beitreten.
+ **CertificateAuthority**: Geben Sie die Base64-kodierte Zeichenfolge der Kubernetes Certificate Authority ein. Sichtbar in der EKS-Konsole oder über die API. DescribeCluster
+ **ServiceCidr**: Geben Sie den Kubernetes Services CIDR ein. Sichtbar in der EKS-Konsole oder über die API. DescribeCluster
+ **ClusterControlPlaneSecurityGroup**: Wählen Sie den **SecurityGroups**Wert aus der AWS CloudFormation Ausgabe aus, die Sie bei der Erstellung Ihrer [VPC](creating-a-vpc.md) generiert haben.
Die folgenden Schritte zeigen einen Vorgang zum Abrufen der entsprechenden Gruppe.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters.
1. Wählen Sie die Registerkarte **Network (Network)** aus.
1. Verwenden Sie den Wert **Zusätzliche Sicherheitsgruppen** als Referenz, wenn Sie aus der **ClusterControlPlaneSecurityGroup**Dropdownliste auswählen.
+ **NodeGroupName**: Geben Sie einen Namen für Ihre Knotengruppe ein. Dieser Name kann zu einem späteren Zeitpunkt zum Identifizieren der Auto-Scaling-Knotengruppe verwendet werden, die für Ihre Knoten erstellt wurde.
+ **NodeAutoScalingGroupMinSize**: Geben Sie die Mindestanzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann.
+ **NodeAutoScalingGroupDesiredCapacity**: Geben Sie die gewünschte Anzahl von Knoten ein, auf die bei der Erstellung Ihres Stacks skaliert werden soll.
+ **NodeAutoScalingGroupMaxSize**: Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann.
+ **NodeInstanceType**: Wählen Sie einen Instance-Typ für Ihre Knoten. Wenn Ihr Cluster in der AWS Cloud läuft, finden Sie weitere Informationen unter[Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md). Wenn Ihr Cluster auf einem Outpost ausgeführt wird, können Sie nur einen Instance-Typ auswählen, der auf Ihrem Outpost verfügbar ist.
+ **NodeImageIdSSMParam**: Vorab mit dem Amazon EC2 Systems Manager Manager-Parameter eines kürzlich für Amazon EKS optimierten AMI für eine variable Kubernetes-Version gefüllt. Um eine andere Kubernetes-Nebenversion zu verwenden, die von Amazon EKS unterstützt wird, ersetzen Sie *1.XX* durch eine andere [unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). Wir empfehlen, dieselbe Kubernetes-Version wie Ihr Cluster anzugeben.
Um ein für Amazon EKS optimiertes beschleunigtes AMI zu verwenden, aktualisieren Sie den *NodeImageIdSSMParam* Wert auf den gewünschten SSM-Parameter. Erfahren Sie [hier](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html), wie Sie das EKS-AMI IDs von SSM abrufen können.
**Anmerkung**
Die Amazon EKS-Knoten AMIs basieren auf Amazon Linux. Sie können Sicherheits- oder Datenschutzereignisse für [Amazon Linux im Amazon-Linux-Sicherheitscenter](https://alas.aws.amazon.com/) verfolgen, indem Sie die Registerkarte für die gewünschte Version auswählen. Sie können auch den entsprechenden RSS-Feed abonnieren. Sicherheits- oder Datenschutzereignisse enthalten eine Übersicht über das Problem, welche Pakete betroffen sind und wie Sie Ihre Instances aktualisieren, um das Problem zu beheben.
+ **NodeImageId**: (Optional) Wenn Sie Ihr eigenes benutzerdefiniertes AMI (anstelle eines für Amazon EKS optimierten AMI) verwenden, geben Sie eine Knoten-AMI-ID für Ihre AWS Region ein. Wenn Sie hier einen Wert angeben, überschreibt dieser alle Werte im **NodeImageIdSSMParam**Feld.
+ **NodeVolumeSize**: Geben Sie eine Root-Volume-Größe für Ihre Knoten in GiB an.
+ **NodeVolumeType**: Geben Sie einen Root-Volume-Typ für Ihre Knoten an.
+ **KeyName**: Geben Sie den Namen eines Amazon EC2 SSH-Schlüsselpaars ein, mit dem Sie nach dem Start über SSH eine Verbindung zu Ihren Knoten herstellen können. Wenn Sie noch kein EC2 Amazon-Schlüsselpaar haben, können Sie eines in der erstellen AWS-Managementkonsole. Weitere Informationen finden Sie unter [ EC2 Amazon-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im * EC2 Amazon-Benutzerhandbuch*.
**Anmerkung**
Wenn Sie hier kein key pair angeben, schlägt die AWS CloudFormation Stack-Erstellung fehl.
+ **Deaktivieren IMDSv1**: Standardmäßig unterstützt jeder Knoten den Instanz-Metadatendienst Version 1 (IMDSv1) und IMDSv2. Sie können deaktivieren IMDSv1. Um zu verhindern, dass future Knoten und Pods in der Knotengruppe verwendet werden IMDSv1, setzen **Sie Disable IMDSv1** auf **true**. Weitere Informationen finden Sie unter [Konfiguration des Instance-Metadatenservice](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Weitere Informationen zum Einschränken des Zugriffs darauf auf Ihre Knoten finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ **VpcId**: Geben Sie die ID für die [VPC](creating-a-vpc.md) ein, die Sie erstellt haben. Überprüfen Sie vor der Auswahl eines VPC die [VPC-Anforderungen und -Überlegungen](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **Subnets** (Subnetze): Wenn sich Ihr Cluster auf einem Outpost befindet, wählen Sie mindestens ein privates Subnetz in Ihrer VPC. Bevor Sie Subnetze auswählen, überprüfen Sie die [Anforderungen und Überlegungen zu Subnetzen](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). Sie können sehen, welche Subnetze privat sind, indem Sie den jeweiligen Subnetzlink in der Registerkarte **Networking** (Netzwerk) Ihres Clusters öffnen.
1. Treffen Sie die gewünschte Auswahl auf der Seite **Configure stack options** (Stackoptionen konfigurieren) und wählen Sie dann **Next** (Weiter) aus.
1. Aktivieren Sie das Kontrollkästchen links neben **Ich bestätige, dass AWS CloudFormation möglicherweise IAM-Ressourcen erstellt** werden. , und wählen Sie dann **Stapel erstellen** aus.
1. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf **Outputs** (Ausgaben).
1. Notieren Sie das **NodeInstanceRole**für die Knotengruppe, die erstellt wurde. Sie benötigen diese, wenn Sie Ihre Amazon-EKS--Arbeitsknoten konfigurieren.
**Schritt 2: Knoten, die Ihrem Cluster beitreten sollen, aktivieren**
1. Überprüfen Sie, ob Sie bereits über eine `aws-auth` `ConfigMap` verfügen.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Wenn eine `aws-auth` `ConfigMap` angezeigt wird, aktualisieren Sie sie nach Bedarf.
1. Öffnen Sie `ConfigMap` zum Bearbeiten.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Fügen Sie nach Bedarf einen neuen `mapRoles`-Eintrag hinzu. Setzen Sie den `rolearn` Wert auf den **NodeInstanceRole**Wert, den Sie im vorherigen Verfahren aufgezeichnet haben.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. Speichern Sie die Datei und beenden Sie den Text-Editor.
1. Wenn die Fehlermeldung `Error from server (NotFound): configmaps "aws-auth" not found` angezeigt wird, wenden Sie die standardmäßige `ConfigMap` an.
1. Laden Sie die Konfigurationszuordnung herunter.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Stellen Sie in der `aws-auth-cm.yaml` Datei `rolearn` den **NodeInstanceRole**Wert ein, den Sie im vorherigen Verfahren aufgezeichnet haben. Hierzu können Sie einen Texteditor verwenden oder *my-node-instance-role* ersetzen und den folgenden Befehl ausführen:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. Wenden Sie die Konfiguration an. Die Ausführung dieses Befehls kann einige Minuten dauern.
```
kubectl apply -f aws-auth-cm.yaml
```
1. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten.
```
kubectl get nodes --watch
```
Geben Sie `Ctrl`\$1`C` ein, um zum Shell-Prompt zurückzukehren.
**Anmerkung**
Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung.
Wenn Knoten dem Cluster nicht beitreten können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) [Beheben von Problemen mit Amazon EKS-Clustern und -Knoten und](troubleshooting.md) unter [Problembehandlung [Knoten können keinem Cluster beitreten](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) bei lokalen Amazon EKS-Clustern auf AWS Outposts](eks-outposts-troubleshooting.md).
1. Installieren Sie den Amazon-EBS-CSI-Treiber. Weitere Informationen finden Sie unter [Installation](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) am GitHub. Stellen Sie im Abschnitt **Einrichten der Treiberberechtigung** sicher, dass Sie die Anweisungen für die Option **Verwenden des IAM-Instance-Profils** befolgen. Sie müssen die `gp2`-Speicherklasse verwenden. Die `gp3`-Speicherklasse wird nicht unterstützt.
Führen Sie die folgenden Schritte aus, um eine `gp2`-Speicherklasse auf Ihrem Cluster zu erstellen.
1. Führen Sie den folgenden Befehl aus, um die Datei `gp2-storage-class.yaml` zu erstellen.
```
cat >gp2-storage-class.yaml <