**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.
# Lebenszyklus und Konfiguration des Amazon-EKS-Clusters
Dieser Abschnitt enthält detaillierte Anleitungen zum gesamten Lebenszyklus-Management von Kubernetes-Clustern und zu verschiedenen Möglichkeiten, diese zu konfigurieren. Er behandelt die Erstellung von Clustern, die Überwachung des Cluster-Zustands, die Aktualisierung von Kubernetes-Versionen und das Löschen von Clustern. Es enthält auch fortgeschrittene Themen zur Konfiguration des Endpunktzugriffs, zur enable/disable Windows-Unterstützung, zur Einrichtung privater Cluster, zur Implementierung von Autoscaling und zur Verbesserung der Ausfallsicherheit durch Zonenverschiebung für die Verkehrsumleitung in Multi-AZ-Setups.
**Topics**
+ [Einen Cluster für Amazon EKS Auto Mode erstellen](create-cluster-auto.md)
+ [Amazon-EKS-Cluster erstellen](create-cluster.md)
+ [Von Amazon EKS bereitgestellte Kontrollebene](eks-provisioned-control-plane.md)
+ [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md)
+ [Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version](update-cluster.md)
+ [Einen Cluster löschen](delete-cluster.md)
+ [Cluster-API-Server-Endpunkt](cluster-endpoint.md)
+ [Bereitstellung von Windows-Knoten in EKS-Clustern](windows-support.md)
+ [Windows-Support deaktivieren](disable-windows-support.md)
+ [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md)
+ [Skalierung von Cluster-Computing mit Karpenter und Cluster Autoscaler](autoscaling.md)
+ [Weitere Informationen zur Zonenverschiebung von Amazon Application Recovery Controller (ARC) in Amazon EKS](zone-shift.md)
+ [Aktivierung der EKS-Zonenverschiebung zur Vermeidung beeinträchtigter Availability Zones](zone-shift-enable.md)
# Einen Cluster für Amazon EKS Auto Mode erstellen
Dieses Thema enthält detaillierte Anweisungen zum Erstellen eines Clusters für Amazon EKS Auto Mode mit erweiterten Konfigurationsoptionen. Es behandelt Voraussetzungen, Netzwerkoptionen und Add-On-Konfigurationen. Der Prozess umfasst die Einrichtung von IAM-Rollen, die Konfiguration von Cluster-Einstellungen, die Festlegung von Netzwerkparametern und die Auswahl von Add-Ons. Benutzer können Cluster entweder mit der AWS-Managementkonsole oder der AWS CLI erstellen, wobei step-by-step Anleitungen für beide Methoden bereitgestellt werden.
Benutzer, die einen weniger komplexen Einrichtungsprozess wünschen, finden nachfolgend vereinfachte Schritte zur Cluster-Erstellung:
+ [Erstellung eines EKS-Auto-Mode-Clusters mit der eksctl-Befehlszeilenschnittstelle](automode-get-started-eksctl.md)
+ [Erstellen Sie einen EKS-Auto-Mode-Cluster mit der AWS CLI](automode-get-started-cli.md)
+ [Erstellung eines EKS-Auto-Mode-Clusters mit AWS-Managementkonsole](automode-get-started-console.md)
Dieser Leitfaden zur erweiterten Konfiguration richtet sich an Benutzer, die eine differenziertere Kontrolle über die Einrichtung ihres EKS-Auto-Mode-Clusters benötigen und mit den Konzepten und Anforderungen von Amazon EKS vertraut sind. Bevor Sie mit der erweiterten Konfiguration fortfahren, stellen Sie sicher, dass Sie alle Voraussetzungen erfüllt haben und die Netzwerk- und IAM-Anforderungen für EKS-Auto-Mode-Cluster gründlich verstanden haben.
EKS Auto Mode erfordert zusätzliche IAM-Berechtigungen. Weitere Informationen finden Sie unter:
+ [IAM-Rollen für Cluster in EKS Auto Mode](automode-get-started-cli.md#auto-mode-create-roles)
+ [Weitere Informationen zu Identität und Zugriff in EKS Auto Mode](auto-learn-iam.md)
**Anmerkung**
Wenn Sie einen Cluster ohne EKS Auto Mode erstellen möchten, lesen Sie [Amazon-EKS-Cluster erstellen](create-cluster.md).
Dieses Thema behandelt die erweiterte Konfiguration. Wenn Sie den EKS Auto Mode verwenden möchten, lesen Sie [Einen Cluster mit Amazon EKS Auto Mode erstellen](create-auto.md).
## Voraussetzungen
+ Eine vorhandene VPC und Subnetze, die die [Amazon-EKS-Anforderungen](network-reqs.md) erfüllen. Bevor Sie einen Cluster für den Produktionseinsatz bereitstellen, empfehlen wir, dass Sie sich ein umfassendes Verständnis der VPC- und Subnetzanforderungen aneignen. Wenn Sie keine VPC und keine Subnetze haben, können Sie diese mithilfe einer von [Amazon EKS bereitgestellten AWS CloudFormation ](creating-a-vpc.md) Vorlage erstellen.
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der 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`. 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*.
+ Ein [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) mit Berechtigungen zum Erstellen und Ändern von EKS- und IAM-Ressourcen.
## Cluster erstellen — AWS Konsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie **Cluster hinzufügen** und dann **Erstellen** aus.
1. Wählen Sie unter *Konfigurationsoptionen* die Option **Benutzerdefinierte Konfiguration** aus.
+ Dieses Thema behandelt die benutzerdefinierte Konfiguration. Informationen zur Schnellkonfiguration finden Sie unter [Erstellung eines EKS-Auto-Mode-Clusters mit AWS-Managementkonsole](automode-get-started-console.md).
1. Bestätigen Sie, dass **EKS Auto Mode verwenden** aktiviert ist.
+ Dieses Thema behandelt die Erstellung von Clustern mit EKS Auto Mode. Weitere Informationen zum Erstellen von Clustern ohne EKS Auto Mode finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md).
1. Füllen Sie auf der Seite **Configure cluster** (Cluster konfigurieren) die folgenden Felder aus:
+ **Name** – Ein Name für Ihren Cluster. Der Name darf nur alphanumerische Zeichen (Groß-/Kleinschreibung beachten), Bindestriche und Unterstriche 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.
+ **Cluster-IAM-Rolle** — Wählen Sie die Amazon EKS-Cluster-IAM-Rolle aus, die Sie erstellt haben, damit die Kubernetes-Steuerebene AWS Ressourcen in Ihrem Namen verwalten kann. Wenn Sie zuvor noch keine Cluster-IAM-Rolle für den EKS Auto Mode erstellt haben, klicken Sie auf die Schaltfläche **Empfohlene Rolle erstellen**, um die Rolle mit den erforderlichen Berechtigungen in der IAM-Konsole zu erstellen.
+ **Kubernetes-Version** – Die Kubernetes-Version, die für den Cluster verwendet wird. Wir empfehlen, die frühere Version auszuwählen, es sei denn, Sie benötigen eine ältere Version.
+ **Upgrade-Richtlinie** – Die Kubernetes-Versionsrichtlinie, die Sie für Ihren Cluster festlegen möchten. Wenn Ihr Cluster nur mit einer Standard-Supportversion ausgeführt werden soll, wählen Sie **Standard**. Wenn Ihr Cluster nach Ablauf des Standard-Supports für eine Version in den erweiterten Support wechseln soll, wählen Sie **Erweitert**. Wenn Sie eine Kubernetes-Version auswählen, für die derzeit der erweiterte Support gilt, können Sie den Standard-Support nicht als Option auswählen.
1. Geben Sie im Abschnitt **Auto Mode Compute** der Seite für die Cluster-Konfiguration die folgenden Felder ein:
+ **Knoten-Pools** – Legen Sie fest, ob Sie die integrierten Knoten-Pools verwenden möchten. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
+ **Knoten-IAM-Rolle** – Wenn Sie einen der integrierten Knoten-Pools aktivieren, müssen Sie eine Knoten-IAM-Rolle auswählen. EKS Auto Mode weist diese Rolle neuen Knoten zu. Dieser Wert kann nach der Erstellung des Clusters nicht mehr geändert werden. Falls Sie noch keine Knoten-IAM-Rolle für EKS Auto Mode erstellt haben, klicken Sie auf die Schaltfläche „Empfohlene Rolle erstellen“, um die Rolle mit den erforderlichen Berechtigungen zu erstellen. Weitere Informationen über diese Rolle finden Sie unter [Weitere Informationen zu Identität und Zugriff in EKS Auto Mode](auto-learn-iam.md).
1. Geben Sie im Abschnitt **Cluster-Zugriff** der Seite „Cluster konfigurieren“ die folgenden Felder ein:
+ **Administrator-Zugriff für Bootstrap-Cluster** – Der Cluster-Ersteller ist automatisch ein Kubernetes-Administrator. Wenn Sie dies deaktivieren möchten, wählen Sie **Cluster-Administratorzugriff verbieten** aus.
+ **Cluster-Authentifizierungsmodus** – EKS Auto Mode erfordert EKS-Zugriffseinträge, den EKS-API-Authentifizierungsmodus. **Sie können den `ConfigMap` Authentifizierungsmodus optional aktivieren, indem Sie EKS-API und auswählen. ConfigMap**
1. Geben Sie die restlichen Felder auf der Seite für die Cluster-Konfiguration ein:
+ **Secrets-Verschlüsselung** – (Optional) Aktivieren Sie die Secrets-Verschlüsselung von Kubernetes-Secrets mithilfe eines KMS-Schlüssels. Sie können diese auch aktivieren, nachdem Sie Ihren Cluster erstellt haben. Stellen Sie vor Aktivierung dieser Funktion sicher, dass Sie mit den Informationen unter [Verschlüsselung von Kubernetes-Geheimnissen mit KMS in vorhandenen Clustern](enable-kms.md) vertraut sind.
+ **ARC-Zonenverschiebung** – EKS Auto Mode unterstützt keine Arc-Zonenverschiebung.
+ **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 die [Anforderungen für Amazon EKS VPC](network-reqs.md#network-requirements-vpc) erfüllt, um Ihren Cluster zu erstellen. Bevor Sie sich für eine VPC entscheiden, empfehlen wir, sich mit allen Anforderungen und Überlegungen in [Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze](network-reqs.md) vertraut zu machen. Sie können nach der Cluster-Erstellung nicht mehr ändern, welche VPC Sie verwenden möchten. Wenn keine aufgeführt VPCs sind, müssen Sie zuerst eine erstellen. Weitere Informationen finden Sie unter [Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md).
+ **Subnetze** – Standardmäßig sind alle im vorherigen Feld angegebenen Subnetze in der VPC vorausgewählt. Sie müssen mindestens zwei auswählen.
Die von Ihnen gewählten Subnetze müssen die [Anforderungen für Amazon-EKS-Subnetze](network-reqs.md#network-requirements-subnets) erfüllen. Bevor Sie Subnetze auswählen, empfehlen wir, dass Sie sich mit allen [Anforderungen und Überlegungen für Amazon-EKS-VPCs und -Subnetze](network-reqs.md) vertraut machen.
**Security groups** (Sicherheitsgruppen) – (Optional) Geben Sie eine oder mehrere Sicherheitsgruppen an, die Amazon EKS den erstellten Netzwerkschnittstellen zuordnen soll.
Unabhängig davon, ob Sie Sicherheitsgruppen wählen oder nicht, erstellt Amazon EKS 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.
+ **Cluster-IP-Adressfamilie wählen** — Sie können entweder **IPv4**und wählen **IPv6**.
Kubernetes weist Pods und Services standardmäßig `IPv4`-Adressen zu. Bevor Sie sich entscheiden, die `IPv6`-Familie zu verwenden, stellen Sie sicher, dass Sie mit allen Überlegungen und Anforderungen in den [VPC-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-vpc), [Subnetz-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-subnets)-, [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md)- und [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md)-Themen vertraut sind. Wenn Sie die `IPv6`-Familie auswählen, können Sie keinen Adressbereich für Kubernetes festlegen, aus dem `IPv6`-Serviceadressen zugewiesen werden sollen, wie dies bei der `IPv4`-Familie möglich ist. Kubernetes weist Serviceadressen aus dem eindeutigen lokalen Adressbereich (`fc00::/7`) zu.
+ (Optional) Wählen Sie **Configure Kubernetes Service IP address range** (IP-Adressbereich des Kubernetes-Diensts konfigurieren) und geben Sie einen **`IPv4`-Bereich für den Service** an.
Durch die Angabe Ihres eigenen Bereichs können Sie Konflikte zwischen Kubernetes-Services und anderen Netzwerken vermeiden, die mit Ihrer VPC verbunden sind. Geben Sie einen Bereich in CIDR-Notation ein. Beispiel: `10.2.0.0/16`.
Der CIDR-Block muss die folgenden Anforderungen erfüllen:
+ Verwendet einen der folgenden Bereiche: `10.0.0.0/8`, `172.16.0.0/12`, oder `192.168.0.0/16`.
+ Hat eine Mindestgröße von `/24` und eine maximale Größe von `/12`.
+ Überschneidet sich nicht mit dem Bereich der VPC für Ihre Amazon-EKS-Ressourcen.
Sie können diese Option nur angeben, wenn Sie die `IPv4`-Adressfamilie verwenden, und nur bei Erstellen des Clusters. Wenn Sie dies nicht angeben, weist Kubernetes Service-IP-Adressen aus den CIDR-Blöcken `10.100.0.0/16` oder `172.20.0.0/16` zu.
+ Wählen Sie eine Option für den **Cluster-Endpunktzugriff** aus. Nachdem Ihr Cluster erstellt wurde, können Sie diese Option ändern. Bevor Sie eine nicht standardmäßige Option auswählen, sollten Sie sich mit den Optionen und deren Auswirkungen vertraut machen. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md).
Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
1. (Optional) Auf der Seite **Beobachtbarkeit konfigurieren** können Sie **Metriken** und Optionen zur **Steuerebenen-Protokollierung** aktivieren. Standardmäßig sind alle Protokollierungstypen deaktiviert.
+ Weitere 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. Wählen Sie auf der Seite **Select add-ons** (Add-Ons auswählen) die Add-Ons aus, die Sie Ihrem Cluster hinzufügen möchten. Sie können so viele **Amazon EKS-Add-Ons** und ** AWS Marketplace-Add-Ons** auswählen, wie Sie benötigen. Wenn die ** AWS Marketplace-Add-Ons**, die Sie installieren möchten, nicht aufgeführt sind, können Sie auf die Seitennummerierung klicken, um zusätzliche Seitenergebnisse anzuzeigen, oder nach verfügbaren ** AWS Marketplace-Add-Ons** suchen, indem Sie Text in das Suchfeld eingeben. Sie können auch nach **Kategorie**, **Anbieter** oder **Preismodell** filtern und dann die Add-Ons aus den Suchergebnissen auswählen. Beim Erstellen eines Clusters können Sie alle Add-Ons, die EKS Pod Identities unterstützen, wie in [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md) beschrieben, anzeigen, auswählen und installieren.
+ EKS Auto Mode automatisiert die Funktionalität bestimmter Add-Ons. Wenn Sie planen, EKS-verwaltete Knotengruppen in Ihrem EKS-Auto-Mode-Cluster bereitzustellen, wählen Sie **Zusätzliche Amazon-EKS-Add-Ons** aus und überprüfen Sie die Optionen. Möglicherweise müssen Sie Add-Ons wie CoreDNS und Kube-Proxy installieren. EKS installiert die Add-Ons in diesem Abschnitt nur in selbstverwalteten Knoten und Knotengruppen.
+ Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
1. Wählen Sie auf der Seite **Einstellungen für ausgewählte Add-ons konfigurieren** die Version aus, die Sie installieren möchten. Sie können nach der Clustererstellung jederzeit auf eine neuere Version aktualisieren.
Bei Add-Ons, die EKS Pod Identities unterstützen, können Sie die Konsole verwenden, um die Rolle automatisch zu generieren, wobei der Name, die AWS verwaltete Richtlinie und die Vertrauensrichtlinie speziell für das Add-on vorausgefüllt sind. Sie können vorhandene Rollen wiederverwenden oder neue Rollen für unterstützte Add-Ons erstellen. Schritte zur Verwendung der Konsole zum Erstellen von Rollen für Add-Ons, die EKS Pod Identities unterstützen, finden Sie unter [Add-on erstellen (Konsole)AWS](creating-an-add-on.md#create_add_on_console). Wenn ein Add-On EKS Pod Identity nicht unterstützt, wird nach der Erstellung des Clusters eine Meldung mit Anweisungen zur Verwendung des Assistenten zum Erstellen der IAM-Rollen für Servicekonten (IRSA) angezeigt.
Sie können die Konfiguration jedes Add-Ons nach der Cluster-Erstellung aktualisieren. Weitere Informationen zum Konfigurieren eines Add-Ons finden Sie unter [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.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.
**Anmerkung**
Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter [Unzureichende Kapazität](troubleshooting.md#ice).
Die Clusterbereitstellung dauert mehrere Minuten.
## Cluster erstellen — AWS CLI
Die folgenden CLI-Anweisungen behandeln die Erstellung von IAM-Ressourcen und das Erstellen des Clusters.
### Erstellung einer IAM-Rolle für einen Cluster in EKS Auto Mode
#### Schritt 1: Vertrauensrichtlinie erstellen
Erstellen Sie eine Vertrauensrichtlinie, mit welcher der Amazon-EKS-Service die Rolle übernehmen kann. Speichern Sie die Richtlinie als `trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
#### Schritt 2: Erstellen der IAM-Rolle
Verwenden Sie die Vertrauensrichtlinie, um die Cluster-IAM-Rolle zu erstellen:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
#### Schritt 3: Rollen-ARN notieren
Rufen Sie die ARN der neuen Rolle ab und speichern Sie sie für die Verwendung in den folgenden Schritten:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
#### Schritt 4: Erforderliche Richtlinien hinzufügen
Fügen Sie der Cluster-IAM-Rolle die folgenden AWS verwalteten Richtlinien hinzu, um die erforderlichen Berechtigungen zu gewähren:
**EKSClusterAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputeAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
### Erstellung einer Knoten-IAM-Rolle in EKS Auto Mode
#### Schritt 1: Vertrauensrichtlinie erstellen
Erstellen Sie eine Vertrauensrichtlinie, mit welcher der Amazon-EKS-Service die Rolle übernehmen kann. Speichern Sie die Richtlinie als `node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Schritt 2: Knoten-IAM-Rolle erstellen
Verwenden Sie die **node-trust-policyJSON-Datei** aus dem vorherigen Schritt, um zu definieren, welche Entitäten die Rolle übernehmen können. Führen Sie den folgenden Befehl aus, um die Knoten-IAM-Rolle zu erstellen:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Schritt 3: Rollen-ARN notieren
Rufen Sie nach dem Erstellen der Rolle die ARN der Knoten-IAM-Rolle ab und speichern Sie sie. Sie benötigen diese ARN in den nachfolgenden Schritten. Um die ARN abzurufen, verwenden Sie den folgenden Befehl.
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Schritt 4: Erforderliche Richtlinien hinzufügen
Fügen Sie der Node-IAM-Rolle die folgenden AWS verwalteten Richtlinien hinzu, um die erforderlichen Berechtigungen bereitzustellen:
**Amazon EKSWorker NodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**Amazon EC2 ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
### Cluster erstellen
1. Erstellen Sie den Cluster mit dem folgenden Befehl. Nehmen Sie vor der Ausführung des Befehls die folgenden Ersetzungen vor:
+ *region-code*Ersetzen Sie es durch die AWS Region, in der Sie Ihren Cluster erstellen möchten.
+ Ersetzen Sie *my-cluster* durch Ihren Cluster-Namen. Der Name darf nur alphanumerische Zeichen (Groß-/Kleinschreibung beachten), Bindestriche und Unterstriche 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.
+ Ersetzen Sie *1.30* durch eine von [Amazon EKS unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Ersetzen Sie ihn *111122223333* durch Ihre Konto-ID
+ Wenn Sie unterschiedlich benannte IAM-Rollen für die Cluster- und Node-Rollen erstellt haben, ersetzen Sie die ARNs.
+ Ersetzen Sie `subnetIds` durch Ihre eigenen Werte. Sie können auch weitere IDs hinzufügen. Sie müssen mindestens zwei Subnetze IDs angeben.
Die von Ihnen gewählten Subnetze müssen die [Anforderungen für Amazon-EKS-Subnetze](network-reqs.md#network-requirements-subnets) erfüllen. Bevor Sie Subnetze auswählen, empfehlen wir, dass Sie sich mit allen [Anforderungen und Überlegungen für Amazon-EKS-VPCs und -Subnetze](network-reqs.md) vertraut machen.
+ Wenn Sie keine Sicherheitsgruppen-ID angeben möchten, entfernen Sie `,securityGroupIds=sg-` aus dem Befehl. Wenn Sie eine oder mehrere Sicherheitsgruppen angeben möchten IDs, ersetzen Sie die Werte für `securityGroupIds` durch Ihre eigenen. Sie können auch weitere hinzufügen IDs.
Unabhängig davon, ob Sie Sicherheitsgruppen wählen oder nicht, erstellt Amazon EKS 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.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws: iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws: iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**Anmerkung**
Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter [Unzureichende Kapazität](troubleshooting.md#ice).
Im Folgenden finden Sie optionale Einstellungen, die bei Bedarf dem vorherigen Befehl hinzugefügt werden müssen. Sie können diese Optionen nur aktivieren, wenn Sie den Cluster erstellen, nicht danach.
+ Wenn Sie angeben möchten welchem `IPv4` CIDR-Block (Classless Inter-Domain Routing) Kubernetes Service-IP-Adressen zuweist, geben Sie die Option `--kubernetes-network-config serviceIpv4Cidr=` für den folgenden Befehl an.
Durch die Angabe Ihres eigenen Bereichs können Sie Konflikte zwischen Kubernetes-Services und anderen Netzwerken vermeiden, die mit Ihrer VPC verbunden sind. Geben Sie einen Bereich in CIDR-Notation ein. Beispiel: `10.2.0.0/16`.
Der CIDR-Block muss die folgenden Anforderungen erfüllen:
+ Verwendet einen der folgenden Bereiche: `10.0.0.0/8`, `172.16.0.0/12`, oder `192.168.0.0/16`.
+ Hat eine Mindestgröße von `/24` und eine maximale Größe von `/12`.
+ Überschneidet sich nicht mit dem Bereich der VPC für Ihre Amazon-EKS-Ressourcen.
Sie können diese Option nur angeben, wenn Sie die `IPv4`-Adressfamilie verwenden, und nur bei Erstellen des Clusters. Wenn Sie dies nicht angeben, weist Kubernetes Service-IP-Adressen aus den CIDR-Blöcken `10.100.0.0/16` oder `172.20.0.0/16` zu.
+ Wenn Sie einen Cluster erstellen und möchten, dass der Cluster Pods und Services `IPv6`-Adressen statt `IPv4`-Adressen zuweist, fügen Sie dem folgenden Befehl `--kubernetes-network-config ipFamily=ipv6` hinzu.
Kubernetes weist Pods und Services standardmäßig `IPv4`-Adressen zu. Bevor Sie sich entscheiden, die `IPv6`-Familie zu verwenden, stellen Sie sicher, dass Sie mit allen Überlegungen und Anforderungen in den [VPC-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-vpc), [Subnetz-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-subnets)-, [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md)- und [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md)-Themen vertraut sind. Wenn Sie die `IPv6`-Familie auswählen, können Sie keinen Adressbereich für Kubernetes festlegen, aus dem `IPv6`-Serviceadressen zugewiesen werden sollen, wie dies bei der `IPv4`-Familie möglich ist. Kubernetes weist Serviceadressen aus dem eindeutigen lokalen Adressbereich (`fc00::/7`) zu.
1. Die Bereitstellung des Clusters dauert mehrere Minuten. Sie können den Status Ihres Clusters mit dem folgenden Befehl überprüfen.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## Nächste Schritte
+ [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md)
+ [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md)
+ [Aktivieren Sie die Secrets-Verschlüsselung für Ihren Cluster](enable-kms.md).
+ [Konfigurieren Sie die Protokollierung für Ihren Cluster](control-plane-logs.md).
+ [Fügen Sie Ihrem Cluster Knoten hinzu](eks-compute.md).
# Amazon-EKS-Cluster erstellen
**Anmerkung**
Dieses Thema behandelt die Erstellung von Amazon EKS-Clustern ohne EKS Auto Mode.
Detaillierte Anweisungen zum Erstellen eines EKS-Auto-Mode-Clusters finden Sie unter [Einen Cluster für Amazon EKS Auto Mode erstellen](create-cluster-auto.md).
Informationen zum Einstieg in EKS Auto Mode finden Sie unter [Erste Schritte mit Amazon EKS – EKS Auto Mode](getting-started-automode.md).
Dieses Thema bietet einen Überblick über die verfügbaren Optionen und beschreibt, was zu beachten ist, wenn Sie einen Amazon-EKS-Cluster erstellen. Informationen zum Erstellen eines Clusters mit Ihrer On-Premises-Infrastruktur als Rechenleistung für Knoten finden Sie unter [Einen Amazon-EKS-Cluster mit Hybridknoten erstellen](hybrid-nodes-cluster-create.md). Wenn Sie zum ersten Mal einen Amazon-EKS-Cluster erstellen, empfehlen wir, entsprechend unseren Leitfäden in [Erste Schritte mit Amazon EKS](getting-started.md) vorzugehen. Diese Leitfäden helfen, einen einfachen Standard-Cluster zu erstellen, ohne auf alle verfügbaren Optionen einzugehen.
## Voraussetzungen
+ Eine vorhandene VPC und Subnetze, die die [Amazon-EKS-Anforderungen](network-reqs.md) erfüllen. Bevor Sie einen Cluster für den Produktionseinsatz bereitstellen, empfehlen wir, dass Sie sich ein umfassendes Verständnis der VPC- und Subnetzanforderungen aneignen. Wenn Sie keine VPC und keine Subnetze haben, können Sie diese mithilfe einer von [Amazon EKS bereitgestellten AWS CloudFormation ](creating-a-vpc.md) Vorlage erstellen.
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) mit Berechtigungen für das `create` und `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).
## Schritt 1: Cluster-IAM-Rolle erstellen
1. Wenn Sie bereits eine 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": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie die Amazon-EKS-Cluster-IAM-Rolle. Falls erforderlich, stellen Sie *eks-cluster-role-trust-policy.json* den Pfad auf Ihrem Computer voran, in den Sie im vorherigen Schritt die Datei geschrieben haben. Der Befehl verknüpft die im vorherigen Schritt erstellte Vertrauensrichtlinie mit der 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 `iam:CreateRole`-Aktion (Berechtigung) zugewiesen werden.
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Sie können entweder die von Amazon EKS verwaltete Richtlinie zuweisen oder Ihre eigene benutzerdefinierte Richtlinie erstellen. Informationen zu den Mindestberechtigungen, die Sie in Ihrer benutzerdefinierten Richtlinie verwenden müssen, finden Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
Fügen Sie der Rolle die von Amazon EKS verwaltete Richtlinie mit dem Namen [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) hinzu. 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/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### Serviceverknüpfte Rolle
Amazon EKS erstellt automatisch eine mit dem Service verknüpfte Rolle mit dem Namen `AWSServiceRoleForAmazonEKS`.
Diese ergänzt die Cluster-IAM-Rolle. Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Diese Rolle ermöglicht es Amazon EKS, Cluster in Ihrem Konto zu verwalten. Weitere Informationen finden Sie unter [Verwenden von Rollen für Amazon-EKS-Cluster](using-service-linked-roles-eks.md).
Die IAM-Identität, die Sie zum Erstellen des EKS-Clusters verwenden, muss über die Berechtigung zum Erstellen der serviceverknüpften Rolle verfügen. Dies beinhaltet die `iam:CreateServiceLinkedRole`-Berechtigung.
Wenn die serviceverknüpfte Rolle noch nicht vorhanden ist und Ihre aktuelle IAM-Rolle nicht über ausreichende Berechtigungen zum Erstellen verfügt, schlägt der Cluster-Erstellungsvorgang fehl.
## Schritt 2: Cluster erstellen
Sie können einen Cluster erstellen, indem Sie Folgendes verwenden:
+ [`eksctl`](#step2-eksctl)
+ [die AWS-Managementkonsole](#step2-console)
+ [die AWS CLI](#step2-cli)
### Cluster erstellen – eksctl
1. Sie benötigen eine Version `0.215.0` oder eine neuere Version des `eksctl` Befehlszeilentools, das auf Ihrem Gerät installiert ist oder AWS CloudShell. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
1. Erstellen Sie einen Amazon `IPv4` EKS-Cluster mit der Amazon EKS-Standardversion von Kubernetes in Ihrer AWS Standardregion. Nehmen Sie vor der Ausführung des Befehls die folgenden Ersetzungen vor:
1. *region-code*Ersetzen Sie es durch die AWS Region, in der Sie Ihren Cluster erstellen möchten.
1. 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.
1. Ersetzen Sie *1.35* durch eine von [Amazon EKS unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Ändern Sie die Werte für `vpc-private-subnets`, um Ihre Anforderungen zu erfüllen. Sie können auch weitere hinzufügen IDs. Sie müssen mindestens zwei Subnetze IDs angeben. Wenn Sie lieber öffentliche Subnetze angeben möchten, können Sie `--vpc-private-subnets` zu `--vpc-public-subnets` ändern. Öffentliche Subnetze verfügen über eine zugeordnete Routing-Tabelle mit einer Route zu einem Internet-Gateway, private Subnetze verfügen nicht über eine zugeordnete Routing-Tabelle. Wir empfehlen, nach Möglichkeit private Subnetze zu verwenden.
Die von Ihnen gewählten Subnetze müssen die [Anforderungen für Amazon-EKS-Subnetze](network-reqs.md#network-requirements-subnets) erfüllen. Bevor Sie Subnetze auswählen, empfehlen wir, dass Sie sich mit allen [Anforderungen und Überlegungen für Amazon-EKS-VPCs und -Subnetze](network-reqs.md) vertraut machen.
1. Führen Sie den folgenden Befehl aus:
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
Die Clusterbereitstellung dauert mehrere Minuten. Während der Cluster erstellt wird, werden mehrere Ausgabezeilen angezeigt. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. Mit [Schritt 3: kubeconfig aktualisieren](#step3) fortfahren
#### Optionale Einstellungen
Sie können die meisten Optionen, die beim Erstellen eines Clusters mit `eksctl` angegeben werden können, über den Befehl `eksctl create cluster --help` anzeigen. Verwenden Sie eine `config`-Datei, um alle verfügbaren Optionen anzuzeigen. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. Auf GitHub finden Sie [Beispiele für Config-Dateien](https://github.com/weaveworks/eksctl/tree/master/examples).
Im Folgenden finden Sie optionale Einstellungen, die bei Bedarf dem vorherigen Befehl hinzugefügt werden müssen. Sie können diese Optionen nur aktivieren, wenn Sie den Cluster erstellen, nicht danach. Wenn Sie diese Optionen angeben müssen, müssen Sie den Cluster mit einer [eksctl-Konfigurationsdatei](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) erstellen und die Einstellungen angeben, anstatt den vorherigen Befehl zu verwenden.
+ Wenn Sie eine oder mehrere Sicherheitsgruppen angeben möchten, die Amazon EKS den erstellten Netzwerkschnittstellen zuweist, geben Sie die Option [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup) an.
Unabhängig davon, ob Sie Sicherheitsgruppen wählen oder nicht, erstellt Amazon EKS 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 angeben möchten, welchem CIDR-Block (`IPv4`Classless Inter-Domain Routing) Kubernetes Dienst-IP-Adressen zuweist, geben Sie die Service-CIDR-Option an. IPv4](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR)
Durch die Angabe Ihres eigenen Bereichs können Sie Konflikte zwischen Kubernetes-Services und anderen Netzwerken vermeiden, die mit Ihrer VPC verbunden sind. Geben Sie einen Bereich in CIDR-Notation ein. Beispiel: `10.2.0.0/16`.
Der CIDR-Block muss die folgenden Anforderungen erfüllen:
+ Verwendet einen der folgenden Bereiche: `10.0.0.0/8`, `172.16.0.0/12`, oder `192.168.0.0/16`.
+ Hat eine Mindestgröße von `/24` und eine maximale Größe von `/12`.
+ Überschneidet sich nicht mit dem Bereich der VPC für Ihre Amazon-EKS-Ressourcen.
Sie können diese Option nur angeben, wenn Sie die `IPv4`-Adressfamilie verwenden, und nur bei Erstellen des Clusters. Wenn Sie dies nicht angeben, weist Kubernetes Service-IP-Adressen aus den CIDR-Blöcken `10.100.0.0/16` oder `172.20.0.0/16` zu.
+ Wenn Sie einen Cluster erstellen und möchten, dass der Cluster Pods und Services `IPv6`-Adressen statt `IPv4`-Adressen zuweist, geben Sie die Option [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily) an.
Kubernetes weist Pods und Services standardmäßig `IPv4`-Adressen zu. Bevor Sie sich entscheiden, die `IPv6`-Familie zu verwenden, stellen Sie sicher, dass Sie mit allen Überlegungen und Anforderungen in den Themen [VPC-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-vpc), [Subnetz-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-subnets), [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md), und [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md) vertraut sind. Wenn Sie die `IPv6`-Familie auswählen, können Sie keinen Adressbereich für Kubernetes festlegen, aus dem `IPv6`-Serviceadressen zugewiesen werden sollen, wie dies bei der `IPv4`-Familie möglich ist. Kubernetes weist Serviceadressen aus dem eindeutigen lokalen Adressbereich (`fc00::/7`) zu.
### Cluster erstellen — Konsole AWS
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie **Cluster hinzufügen** und dann **Erstellen** aus.
1. Wählen Sie unter **Konfigurationsoptionen** die Option **Benutzerdefinierte Konfiguration**
+ Informationen zur schnellen Erstellung eines Clusters mit EKS Auto Mode finden Sie unter [Erstellung eines EKS-Auto-Mode-Clusters mit AWS-Managementkonsole](automode-get-started-console.md).
1. Deaktivieren Sie unter **EKS Auto Mode** die Option **EKS Auto Mode verwenden**.
+ Informationen zum Erstellen eines EKS-Auto-Mode-Clusters mit benutzerdefinierter Konfiguration finden Sie unter [Einen Cluster für Amazon EKS Auto Mode erstellen](create-cluster-auto.md).
1. Füllen Sie auf der Seite **Configure cluster** (Cluster konfigurieren) die folgenden Felder aus:
+ **Name** – Ein Name für Ihren Cluster. Der Name darf nur alphanumerische Zeichen (Groß-/Kleinschreibung beachten), Bindestriche und Unterstriche 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.
+ **Cluster-IAM-Rolle** — Wählen Sie die Amazon EKS-Cluster-IAM-Rolle aus, die Sie erstellt haben, damit die Kubernetes-Steuerebene AWS Ressourcen in Ihrem Namen verwalten kann.
+ **Kubernetes-Version** – Die Kubernetes-Version, die für den Cluster verwendet wird. Wir empfehlen, die frühere Version auszuwählen, es sei denn, Sie benötigen eine ältere Version.
+ **Supporttyp** – Die Kubernetes-Versionsrichtlinie, die Sie für Ihren Cluster festlegen möchten. Wenn Ihr Cluster nur mit einer Standard-Supportversion ausgeführt werden soll, können Sie **Standard-Support** auswählen. Wenn Sie möchten, dass Ihr Cluster nach Ablauf des Standard-Supports für eine Version in den erweiterten Support übergeht, können Sie **Erweiterter Support** auswählen. Wenn Sie eine Kubernetes-Version auswählen, für die derzeit der erweiterte Support gilt, können Sie den Standard-Support nicht als Option auswählen.
+ **Secrets-Verschlüsselung** – (Optional) Aktivieren Sie die Secrets-Verschlüsselung von Kubernetes-Secrets mithilfe eines KMS-Schlüssels. Sie können diese auch aktivieren, nachdem Sie Ihren Cluster erstellt haben. Stellen Sie vor Aktivierung dieser Funktion sicher, dass Sie mit den Informationen unter [Verschlüsselung von Kubernetes-Geheimnissen mit KMS in vorhandenen Clustern](enable-kms.md) vertraut sind.
+ **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).
+ **ARC-Zonenverschiebung** – (Optional) Sie können den Route53 Application Recovery Controller einsetzen, um beeinträchtigte Availability Zones zu mindern. Weitere Informationen finden Sie unter [Weitere Informationen zur Zonenverschiebung von Amazon Application Recovery Controller (ARC) in Amazon EKS](zone-shift.md).
1. Geben Sie im Abschnitt **Cluster-Zugriff** der Seite „Cluster konfigurieren“ die folgenden Felder ein:
+ **Administrator-Zugriff für Bootstrap-Cluster** – Der Cluster-Ersteller ist automatisch ein Kubernetes-Administrator. Wenn Sie dies deaktivieren möchten, wählen Sie **Cluster-Administratorzugriff verbieten** aus.
+ **Cluster-Authentifizierungsmodus** — Legen Sie fest, wie Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes gewähren möchten. APIs Weitere Informationen finden Sie unter [Einstellen des Cluster-Authentifizierungsmodus](grant-k8s-access.md#set-cam).
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 die [Anforderungen für Amazon EKS VPC](network-reqs.md#network-requirements-vpc) erfüllt, um Ihren Cluster zu erstellen. Bevor Sie sich für eine VPC entscheiden, empfehlen wir, sich mit allen Anforderungen und Überlegungen in [Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze](network-reqs.md) vertraut zu machen. Sie können nach der Cluster-Erstellung nicht mehr ändern, welche VPC Sie verwenden möchten. Wenn keine aufgeführt VPCs sind, müssen Sie zuerst eine erstellen. Weitere Informationen finden Sie unter [Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md).
+ **Subnetze** – Standardmäßig sind alle im vorherigen Feld angegebenen Subnetze in der VPC vorausgewählt. Sie müssen mindestens zwei auswählen.
Die von Ihnen gewählten Subnetze müssen die [Anforderungen für Amazon-EKS-Subnetze](network-reqs.md#network-requirements-subnets) erfüllen. Bevor Sie Subnetze auswählen, empfehlen wir, dass Sie sich mit allen [Anforderungen und Überlegungen für Amazon-EKS-VPCs und -Subnetze](network-reqs.md) vertraut machen.
**Security groups** (Sicherheitsgruppen) – (Optional) Geben Sie eine oder mehrere Sicherheitsgruppen an, die Amazon EKS den erstellten Netzwerkschnittstellen zuordnen soll.
Unabhängig davon, ob Sie Sicherheitsgruppen wählen oder nicht, erstellt Amazon EKS 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.
+ **Cluster-IP-Adressfamilie wählen** — Sie können entweder **IPv4**und wählen **IPv6**.
Kubernetes weist Pods und Services standardmäßig `IPv4`-Adressen zu. Bevor Sie sich entscheiden, die `IPv6`-Familie zu verwenden, stellen Sie sicher, dass Sie mit allen Überlegungen und Anforderungen in den [VPC-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-vpc), [Subnetz-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-subnets)-, [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md)- und [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md)-Themen vertraut sind. Wenn Sie die `IPv6`-Familie auswählen, können Sie keinen Adressbereich für Kubernetes festlegen, aus dem `IPv6`-Serviceadressen zugewiesen werden sollen, wie dies bei der `IPv4`-Familie möglich ist. Kubernetes weist Serviceadressen aus dem eindeutigen lokalen Adressbereich (`fc00::/7`) zu.
+ (Optional) Wählen Sie **Configure Kubernetes Service IP address range** (IP-Adressbereich des Kubernetes-Diensts konfigurieren) und geben Sie einen **`IPv4`-Bereich für den Service** an.
Durch die Angabe Ihres eigenen Bereichs können Sie Konflikte zwischen Kubernetes-Services und anderen Netzwerken vermeiden, die mit Ihrer VPC verbunden sind. Geben Sie einen Bereich in CIDR-Notation ein. Beispiel: `10.2.0.0/16`.
Der CIDR-Block muss die folgenden Anforderungen erfüllen:
+ Verwendet einen der folgenden Bereiche: `10.0.0.0/8`, `172.16.0.0/12`, oder `192.168.0.0/16`.
+ Hat eine Mindestgröße von `/24` und eine maximale Größe von `/12`.
+ Überschneidet sich nicht mit dem Bereich der VPC für Ihre Amazon-EKS-Ressourcen.
Sie können diese Option nur angeben, wenn Sie die `IPv4`-Adressfamilie verwenden, und nur bei Erstellen des Clusters. Wenn Sie dies nicht angeben, weist Kubernetes Service-IP-Adressen aus den CIDR-Blöcken `10.100.0.0/16` oder `172.20.0.0/16` zu.
+ Wählen Sie eine Option für den **Cluster-Endpunktzugriff** aus. Nachdem Ihr Cluster erstellt wurde, können Sie diese Option ändern. Bevor Sie eine nicht standardmäßige Option auswählen, sollten Sie sich mit den Optionen und deren Auswirkungen vertraut machen. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md).
Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
1. (Optional) Auf der Seite **Beobachtbarkeit konfigurieren** können Sie **Metriken** und Optionen zur **Steuerebenen-Protokollierung** aktivieren. Standardmäßig sind alle Protokollierungstypen deaktiviert.
+ Weitere 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. Wählen Sie auf der Seite **Select add-ons** (Add-Ons auswählen) die Add-Ons aus, die Sie Ihrem Cluster hinzufügen möchten. Bestimmte Add-Ons sind bereits vorausgewählt. Sie können so viele **Amazon EKS-Add-Ons** und ** AWS Marketplace-Add-Ons** auswählen, wie Sie benötigen. Wenn die ** AWS Marketplace-Add-Ons**, die Sie installieren möchten, nicht aufgeführt sind, können Sie auf die Seitennummerierung klicken, um zusätzliche Seitenergebnisse anzuzeigen, oder nach verfügbaren ** AWS Marketplace-Add-Ons** suchen, indem Sie Text in das Suchfeld eingeben. Sie können auch nach **Kategorie**, **Anbieter** oder **Preismodell** filtern und dann die Add-Ons aus den Suchergebnissen auswählen. Beim Erstellen eines Clusters können Sie alle Add-Ons, die EKS Pod Identities unterstützen, wie in [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md) beschrieben, anzeigen, auswählen und installieren.
Wenn Sie mit dieser Seite fertig sind, wählen Sie **Weiter** aus.
Einige Add-Ons, wie Amazon VPC CNI, CoreDNS und kube-proxy, sind standardmäßig installiert. Wenn Sie eines der Standard-Add-Ons deaktivieren, kann dies Ihre Fähigkeit beeinträchtigen, Kubernetes-Anwendungen auszuführen.
1. Wählen Sie auf der Seite **Einstellungen für ausgewählte Add-ons konfigurieren** die Version aus, die Sie installieren möchten. Sie können nach der Clustererstellung jederzeit auf eine neuere Version aktualisieren.
Bei Add-Ons, die EKS Pod Identities unterstützen, können Sie die Konsole verwenden, um die Rolle automatisch zu generieren, wobei der Name, die AWS verwaltete Richtlinie und die Vertrauensrichtlinie speziell für das Add-on vorausgefüllt sind. Sie können vorhandene Rollen wiederverwenden oder neue Rollen für unterstützte Add-Ons erstellen. Schritte zur Verwendung der Konsole zum Erstellen von Rollen für Add-Ons, die EKS Pod Identities unterstützen, finden Sie unter [Add-on erstellen (Konsole)AWS](creating-an-add-on.md#create_add_on_console). Wenn ein Add-On EKS Pod Identity nicht unterstützt, wird nach der Erstellung des Clusters eine Meldung mit Anweisungen zur Verwendung des Assistenten zum Erstellen der IAM-Rollen für Servicekonten (IRSA) angezeigt.
Sie können die Konfiguration jedes Add-Ons nach der Cluster-Erstellung aktualisieren. Weitere Informationen zum Konfigurieren eines Add-Ons finden Sie unter [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.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.
**Anmerkung**
Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter [Unzureichende Kapazität](troubleshooting.md#ice).
Die Clusterbereitstellung dauert mehrere Minuten.
1. Mit [Schritt 3: kubeconfig aktualisieren](#step3) fortfahren
### Cluster erstellen — AWS CLI
1. Erstellen Sie den Cluster mit dem folgenden Befehl. Nehmen Sie vor der Ausführung des Befehls die folgenden Ersetzungen vor:
+ *region-code*Ersetzen Sie es durch die AWS Region, in der Sie Ihren Cluster erstellen möchten.
+ Ersetzen Sie *my-cluster* durch Ihren Cluster-Namen. Der Name darf nur alphanumerische Zeichen (Groß-/Kleinschreibung beachten), Bindestriche und Unterstriche 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.
+ Ersetzen Sie *1.35* durch eine von [Amazon EKS unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Ersetzen Sie *111122223333* durch Ihre Konto-ID und *myAmazonEKSClusterRole* durch den Namen Ihres IAM-Rollen-Clusters.
+ Ersetzen Sie `subnetIds` durch Ihre eigenen Werte. Sie können auch weitere hinzufügen IDs. Sie müssen mindestens zwei Subnetze IDs angeben.
Die von Ihnen gewählten Subnetze müssen die [Anforderungen für Amazon-EKS-Subnetze](network-reqs.md#network-requirements-subnets) erfüllen. Bevor Sie Subnetze auswählen, empfehlen wir, dass Sie sich mit allen [Anforderungen und Überlegungen für Amazon-EKS-VPCs und -Subnetze](network-reqs.md) vertraut machen.
+ Wenn Sie keine Sicherheitsgruppen-ID angeben möchten, entfernen Sie `,securityGroupIds=sg-` aus dem Befehl. Wenn Sie eine oder mehrere Sicherheitsgruppen angeben möchten IDs, ersetzen Sie die Werte für `securityGroupIds` durch Ihre eigenen. Sie können auch weitere hinzufügen IDs.
Unabhängig davon, ob Sie Sicherheitsgruppen wählen oder nicht, erstellt Amazon EKS 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.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws: iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**Anmerkung**
Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter [Unzureichende Kapazität](troubleshooting.md#ice).
Im Folgenden finden Sie optionale Einstellungen, die bei Bedarf dem vorherigen Befehl hinzugefügt werden müssen. Sie können diese Optionen nur aktivieren, wenn Sie den Cluster erstellen, nicht danach.
+ Standardmäßig installiert EKS während der Cluster-Erstellung mehrere Netzwerk-Add-Ons. Dazu gehören Amazon VPC CNI, CoreDNS und kube-proxy.
Wenn Sie die Installation dieser Standard-Netzwerk-Add-Ons deaktivieren möchten, verwenden Sie den folgenden Parameter. Dies kann als Alternative verwendet werden CNIs, z. B. für Cilium. Weitere Informationen finden Sie in der [EKS-API-Referenz](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html).
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Wenn Sie angeben möchten welchem `IPv4` CIDR-Block (Classless Inter-Domain Routing) Kubernetes Service-IP-Adressen zuweist, geben Sie die Option `--kubernetes-network-config serviceIpv4Cidr=` für den folgenden Befehl an.
Durch die Angabe Ihres eigenen Bereichs können Sie Konflikte zwischen Kubernetes-Services und anderen Netzwerken vermeiden, die mit Ihrer VPC verbunden sind. Geben Sie einen Bereich in CIDR-Notation ein. Beispiel: `10.2.0.0/16`.
Der CIDR-Block muss die folgenden Anforderungen erfüllen:
+ Verwendet einen der folgenden Bereiche: `10.0.0.0/8`, `172.16.0.0/12`, oder `192.168.0.0/16`.
+ Hat eine Mindestgröße von `/24` und eine maximale Größe von `/12`.
+ Überschneidet sich nicht mit dem Bereich der VPC für Ihre Amazon-EKS-Ressourcen.
Sie können diese Option nur angeben, wenn Sie die `IPv4`-Adressfamilie verwenden, und nur bei Erstellen des Clusters. Wenn Sie dies nicht angeben, weist Kubernetes Service-IP-Adressen aus den CIDR-Blöcken `10.100.0.0/16` oder `172.20.0.0/16` zu.
+ Wenn Sie einen Cluster erstellen und möchten, dass der Cluster Pods und Services `IPv6`-Adressen statt `IPv4`-Adressen zuweist, fügen Sie dem folgenden Befehl `--kubernetes-network-config ipFamily=ipv6` hinzu.
Kubernetes weist Pods und Services standardmäßig `IPv4`-Adressen zu. Bevor Sie sich entscheiden, die `IPv6`-Familie zu verwenden, stellen Sie sicher, dass Sie mit allen Überlegungen und Anforderungen in den [VPC-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-vpc), [Subnetz-Anforderungen und -Überlegungen](network-reqs.md#network-requirements-subnets)-, [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md)- und [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md)-Themen vertraut sind. Wenn Sie die `IPv6`-Familie auswählen, können Sie keinen Adressbereich für Kubernetes festlegen, aus dem `IPv6`-Serviceadressen zugewiesen werden sollen, wie dies bei der `IPv4`-Familie möglich ist. Kubernetes weist Serviceadressen aus dem eindeutigen lokalen Adressbereich (`fc00::/7`) zu.
1. Die Bereitstellung des Clusters dauert mehrere Minuten. Sie können den Status Ihres Clusters mit dem folgenden Befehl überprüfen.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
Fahren Sie nicht mit dem nächsten Schritt fort, bis die zurückgegebene Ausgabe `ACTIVE` ist.
1. Mit [Schritt 3: kubeconfig aktualisieren](#step3) fortfahren
## Schritt 3: kubeconfig aktualisieren
1. Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, können Sie diesen Schritt überspringen. Das liegt daran, dass `eksctl` diesen Schritt bereits für Sie durchgeführt hat. Aktivieren Sie `kubectl`, um mit Ihrem Cluster zu kommunizieren, indem Sie einen neuen Kontext zur Datei `kubectl` `config` hinzufügen. Weitere Informationen 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. Bestätigen Sie die Kommunikation mit Ihrem Cluster, indem Sie den folgenden Befehl ausführen.
```
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
```
## Schritt 4: Cluster-Einrichtung
1. (Empfohlen) Um einige Amazon EKS-Add-Ons zu verwenden oder einzelnen Kubernetes-Workloads bestimmte AWS Identity and Access Management (IAM) -Berechtigungen zuzuweisen, [erstellen Sie einen IAM OpenID Connect (OIDC](enable-iam-roles-for-service-accounts.md)) -Anbieter für Ihren Cluster. Sie müssen einen IAM-OIDC-Anbieter für Ihren Cluster nur einmal erstellen. Weitere Informationen zu Amazon EKS-Add-ons finden Sie unter [Amazon-EKS-Add-ons](eks-add-ons.md). Weitere Informationen zum Zuweisen bestimmter IAM-Berechtigungen zu Ihren Workloads finden Sie unter [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md).
1. (Empfohlen) Konfigurieren Sie Ihren Cluster für das Amazon-VPC-CNI-Plugin für das Kubernetes-Plugin, bevor Sie Amazon EC2-Knoten in Ihrem Cluster bereitstellen. Standardmäßig wurde das Plugin mit Ihrem Cluster installiert. Wenn Sie Ihrem Cluster Amazon-EC2-Knoten hinzufügen, wird das Plugin automatisch für jeden Amazon-EC2-Knoten bereitgestellt, den Sie hinzufügen. Für das Plugin müssen Sie eine der folgenden IAM-Richtlinien an eine IAM-Rolle anfügen: Wenn Ihr Cluster die `IPv4`-Familie verwendet, verwenden Sie die verwaltete IAM-Richtlinie [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html). Wenn Ihr Cluster die `IPv6`-Familie verwendet, verwenden Sie eine [von Ihnen erstellte IAM-Richtlinie](cni-iam-role.md#cni-iam-role-create-ipv6-policy).
Die IAM-Rolle, an die Sie die Richtlinie anhängen, kann die IAM-Rolle des Knotens oder eine dedizierte Rolle sein, die nur für das Plugin verwendet wird. Wir empfehlen, die Richtlinie an diese Rolle anzuhängen. Weitere Informationen zum Erstellen der Rolle finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md) oder [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md).
1. Wenn Sie Ihren Cluster mit dem bereitgestellt haben, können Sie diesen Schritt überspringen. AWS-Managementkonsole Der AWS-Managementkonsole stellt standardmäßig das Amazon VPC CNI-Plug-In für Kubernetes-, CoreDNS- und `kube-proxy` Amazon EKS-Add-Ons bereit.
Wenn Sie Ihren Cluster entweder mit der CLI `eksctl` oder mit der AWS CLI bereitstellen, werden das Amazon VPC CNI-Plug-In für Kubernetes, CoreDNS und selbstverwaltete Add-Ons bereitgestellt. `kube-proxy` Sie können das Amazon-VPC-CNI-Plugin für Kubernetes, CoreDNS und selbstverwaltete `kube-proxy`-Add-Ons, die mit Ihrem Cluster bereitgestellt werden, auf Amazon-EKS-Add-Ons migrieren. Weitere Informationen finden Sie unter [Amazon-EKS-Add-ons](eks-add-ons.md).
1. (Optional) Falls noch nicht geschehen, können Sie Prometheus-Metriken für Ihren Cluster aktivieren. Weitere Informationen finden Sie unter [Erstellen eine Scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
1. Wenn Sie beabsichtigen, Workloads auf Ihrem Cluster bereitzustellen, die Amazon-EBS-Volumes verwenden, müssen Sie vor der Bereitstellung der Workloads [Amazon EBS CSI](ebs-csi.md) auf Ihrem Cluster installieren.
## Nächste Schritte
+ Der [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der den Cluster erstellt hat, ist der einzige Prinzipal, der Zugriff auf den Cluster hat. [Gewähren Sie Berechtigungen für andere IAM-Prinzipalen](grant-k8s-access.md), damit sie auf Ihren Cluster zugreifen können.
+ Wenn der IAM-Prinzipal, der den Cluster erstellt hat, nur über die Mindest-IAM-Berechtigungen verfügt, auf die in den Voraussetzungen verwiesen wird, dann möchten Sie vielleicht weitere Amazon-EKS-Berechtigungen für diesen Prinzipal hinzufügen. Weitere Informationen über das Erteilen von Amazon-EKS-Berechtigungen für IAM-Prinzipals finden Sie unter [Identitäts- und Zugriffsverwaltung für Amazon EKS](security-iam.md).
+ Wenn Sie möchten, dass der IAM-Prinzipal, der den Cluster erstellt hat, oder andere Prinzipalen Kubernetes-Ressourcen in der Amazon-EKS-Konsole sehen können, gewähren Sie den Entitäten die [erforderlichen Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Wenn Sie möchten, dass Knoten und IAM-Prinzipalen von Ihrer VPC aus auf Ihren Cluster zugreifen können, aktivieren Sie den privaten Endpunkt für Ihren Cluster. Standardmäßig ist der öffentliche Endpunkt aktiviert. Falls gewünscht, können Sie den öffentlichen Endpunkt deaktivieren, nachdem Sie den privaten Endpunkt aktiviert haben. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md).
+ [Aktivieren Sie die Secrets-Verschlüsselung für Ihren Cluster](enable-kms.md).
+ [Konfigurieren Sie die Protokollierung für Ihren Cluster](control-plane-logs.md).
+ [Fügen Sie Ihrem Cluster Knoten hinzu](eks-compute.md).
# Von Amazon EKS bereitgestellte Kontrollebene
## -Übersicht
Amazon EKS Provisioned Control Plane ist eine Funktion, mit der Cluster-Administratoren aus einer Reihe von Skalierungsstufen auswählen und die von ihnen gewählte Stufe für eine sehr hohe, vorhersehbare Leistung von der Steuerungsebene des Clusters aus festlegen können. Auf diese Weise können Clusteradministratoren sicherstellen, dass die Kontrollebene immer mit der angegebenen Kapazität bereitgestellt wird.
Amazon EKS bietet zwei Betriebsmodi für die Steuerungsebene Ihres Clusters. Standardmäßig verwenden Amazon EKS-Cluster den **Standardmodus**, in dem die Steuerungsebene je nach Ihren Workload-Anforderungen automatisch nach oben und unten skaliert wird. Der Standardmodus weist dynamisch ausreichend Kapazität auf der Steuerungsebene zu, um Ihren Workload-Anforderungen gerecht zu werden. Dies ist die empfohlene Lösung für die meisten Anwendungsfälle. **Für spezielle Workloads, die aufgrund der Skalierung der Steuerungsebene keine Leistungsschwankungen tolerieren können, oder für solche, die eine sehr hohe Kapazität der Steuerungsebene erfordern, können Sie jedoch optional den Bereitstellungsmodus verwenden.** Im Bereitstellungsmodus können Sie die Kapazität der Steuerungsebene vorab zuweisen, sodass diese stets bereit ist, anspruchsvolle Workload-Anforderungen zu bewältigen.
**Anmerkung**
Der Bereitstellungsmodus ist neben dem standardmäßigen Standardmodus ein zusätzlicher Betriebsmodus auf der Steuerungsebene. Durch die Einführung des Bereitstellungsmodus wird das Verhalten im Standardmodus nicht geändert.
Mit EKS Provisioned Control Plane können Clusteradministratoren die gewünschte Kapazität der Steuerungsebene im Voraus bereitstellen und so eine vorhersehbare und hohe Leistung von der Steuerungsebene des Clusters aus gewährleisten, die immer verfügbar ist. EKS Provisioned Control Plane ermöglicht es Clusteradministratoren außerdem, dieselbe Kapazität der Steuerungsebene in allen Umgebungen bereitzustellen, vom Staging über die Produktion bis hin zu den Standorten für die Notfallwiederherstellung. Dies ist wichtig, um sicherzustellen, dass die Leistung der Kontrollebene in allen Umgebungen konsistent und vorhersehbar ist. Schließlich bietet Ihnen EKS Provisioned Control Plane Zugriff auf ein sehr hohes Maß an Leistung auf der Kontrollebene und ermöglicht so die Ausführung von massiv skalierbaren KI-Workloads, Hochleistungscomputing und umfangreichen Datenverarbeitungs-Workloads auf Kubernetes.
Alle vorhandenen und neuen Amazon EKS-Cluster arbeiten standardmäßig im Standardmodus. Für Cluster, die eine hohe, vorhersehbare Leistung auf der Kontrollebene erfordern, können Sie sich für die Verwendung der EKS Provisioned Control Plane-Funktion entscheiden. Ihnen wird der Stundensatz für die jeweilige Skalierungsstufe der Steuerungsebene zusätzlich zu den EKS-Stundengebühren für den standardmäßigen oder erweiterten Support in Rechnung gestellt. Weitere Informationen zur Preisgestaltung finden Sie unter [Amazon EKS-Preise](https://aws.amazon.com/eks/pricing/).
![\[Modi der Amazon EKS-Steuerebene\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/control-plane-modes.png)
## Anwendungsfälle
EKS Provisioned Control Plane wurde für spezifische Szenarien entwickelt, in denen eine hohe und vorhersehbare Leistung der Kontrollebene für Ihren Betrieb entscheidend ist. Wenn Sie diese Anwendungsfälle verstehen, können Sie feststellen, ob EKS Provisioned Control Plane die richtige Lösung für Ihre Workloads ist.
**Leistungskritische Workloads — Für Workloads**, die minimale Latenz und maximale Leistung von der Kubernetes-Steuerebene erfordern, bietet EKS Provisioned Control Plane Kapazität, die Leistungsschwankungen durch Skalierung der Kontrollebene ausschließt.
**Extrem skalierbare Workloads** — Wenn Sie hoch skalierbare Workloads wie KI-Training und Inferenz, Hochleistungscomputing oder umfangreiche Datenverarbeitung ausführen, für die eine große Anzahl von Knoten im Cluster erforderlich ist, bietet Provisioned Control Plane die erforderliche Kapazität der Steuerungsebene, um diese anspruchsvollen Workloads zu unterstützen.
**Erwartete Ereignisse mit hoher Nachfrage** — Wenn Sie aufgrund eines bevorstehenden Ereignisses wie E-Commerce-Verkäufen oder Werbeaktionen, Produkteinführungen, Weihnachtseinkäufen oder großen Sport- oder Unterhaltungsereignissen mit einem plötzlichen Anstieg der Anfragen auf Kontrollebenen rechnen, können Sie mit Provisioned Control Plane die Kapazität Ihrer Kontrollebene im Voraus skalieren. Dieser proaktive Ansatz stellt sicher, dass Ihre Steuerungsebene bereit ist, die erhöhte Last zu bewältigen, ohne auf die automatische Skalierung warten zu müssen, um auf die Nachfrage zu reagieren.
**Konsistenz der Umgebung** — Mit der bereitgestellten Kontrollebene können Sie die Kapazität und Leistung der Steuerungsebene in allen Staging- und Produktionsumgebungen aufeinander abstimmen, sodass Sie potenzielle Probleme frühzeitig erkennen können, bevor sie in der Produktion eingesetzt werden. Durch die Beibehaltung derselben Kontrollebenenebene in allen Umgebungen können Sie sicherstellen, dass die Testergebnisse das Produktionsverhalten genau widerspiegeln, wodurch das Risiko leistungsbedingter Überraschungen bei der Einführung verringert wird.
**Notfallwiederherstellung und Geschäftskontinuität** — Für Notfallwiederherstellungsszenarien ermöglicht Ihnen Provisioned Control Plane die Bereitstellung von Failover-Umgebungen mit derselben Kapazität wie Ihre primäre Umgebung. Dies gewährleistet minimale Unterbrechungen und eine schnelle Wiederherstellung bei Failover-Ereignissen, da Ihr Disaster Recovery-Cluster ab dem Moment der Aktivierung über identische Leistungsmerkmale auf der Steuerungsebene wie Ihr Produktionscluster verfügt.
## Skalierungsstufen auf der Steuerungsebene
EKS Provisioned Control Plane bietet Skalierungsstufen, die nach T-Shirt-Größen (XL, 2XL, 4XL und 8XL) benannt sind. Jede Stufe definiert ihre Kapazität anhand von drei wichtigen Kubernetes-Attributen, die die Leistungsmerkmale der Kontrollebene Ihres Clusters bestimmen. Wenn Sie diese Attribute verstehen, können Sie die passende Stufe für Ihre Workload-Anforderungen auswählen.
Bei der **Parallelität von API-Anfragen** wird die Anzahl der Anfragen gemessen, die der API-Server der Kubernetes-Steuerebene gleichzeitig verarbeiten kann. Dies ist für Workloads mit hohem Durchsatz von entscheidender Bedeutung.
Die **Pod-Scheduling-Rate** gibt an, wie schnell der standardmäßige Kubernetes-Scheduler Pods auf Knoten einplanen kann, gemessen in Pods pro Sekunde.
Die **Größe der Cluster-Datenbank** gibt den Speicherplatz an, der etcd zugewiesen ist, der Datenbank, die den Clusterstatus/die Metadaten enthält.
Wenn Sie die Steuerungsebene Ihres Clusters mithilfe von Provisioned Control Plane auf einer bestimmten Skalierungsebene bereitstellen, stellt EKS sicher, dass die Steuerungsebene Ihres Clusters die dieser Ebene entsprechenden Grenzwerte einhält. Die Grenzen der Skalierungsebenen auf der Kontrollebene variieren je nach Kubernetes-Version, wie in den folgenden Tabellen dargestellt.
### EKS v1.28 und v1.29
| Skalierungsstufe der bereitgestellten Steuerungsebene | Parallelität von API-Anfragen (Sitze) | Pod-Planungsrate (Pods/Sekunde) | Größe der Cluster-Datenbank (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2 XL | 3400 | 100 | 16 |
| 4 XL | 6800 | 100 | 16 |
| 8 XL | 13600 | 100 | 16 |
### EKS v1.30 und höher
| Skalierungsstufe der bereitgestellten Steuerungsebene | Parallelität von API-Anfragen (Sitze) | Pod-Planungsrate (Pods/Sekunde) | Größe der Cluster-Datenbank (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2 XL | 3400 | 283 | 16 |
| 4 XL | 6800 | 400 | 16 |
| 8 XL | 13600 | 400 | 16 |
### Überwachung der Steuerungsebene, Skalierung der Tier-Auslastung
Amazon EKS bietet mehrere Metriken, mit denen Sie die Tier-Auslastung Ihrer Kontrollebene überwachen können. Diese Metriken werden als [ CloudWatch Amazon-Metriken](cloudwatch.md) veröffentlicht und sind über die CloudWatch EKS-Konsole zugänglich. [Darüber hinaus können diese Metriken vom Prometheus-Endpunkt Ihres EKS-Clusters abgerufen werden (siehe hier).](prometheus.md)
| | **Prometheus-Metrik** | **CloudWatch Metrik** |
| --- | --- | --- |
| **Parallelität von API-Anfragen** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **Tarif für die Planung von Pods** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total, Scheduler\$1Schedule\$1Attempts\$1Scheduled, Scheduler\$1Schedule\$1Attempts\$1Unschedulable |
| **Größe der Cluster-Datenbank** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Sie können die Auslastung der Kontrollebene in der Amazon EKS-Konsole anzeigen. Wählen Sie auf der Übersichtsseite Ihres Clusters die Option **Cluster überwachen** aus, um das Observability-Dashboard aufzurufen, und wählen Sie dann die Registerkarte **Überwachung der Kontrollebene**, um die Auslastung der Kontrollebene im Abschnitt **Skalierung der Kontrollebene** anzuzeigen.
![\[Überwachen Sie den EKS-Cluster\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/monitor-cluster.png)
![\[Überwachung der EKS-Steuerebene\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/control-plane-monitoring.png)
### Überblick über die Tier-Kapazität im Vergleich zur tatsächlichen Leistung
Wenn Sie eine Skalierungsstufe für die bereitgestellte Kontrollebene auswählen, stellen die Tierattribute die zugrunde liegenden Konfigurationen dar, die Amazon EKS auf Ihre Kontrollebene anwendet. Die tatsächliche Leistung, die Sie erzielen, hängt jedoch von Ihren spezifischen Workload-Mustern und Konfigurationen und der Einhaltung der Best Practices von Kubernetes ab. Während bei einer Stufe 4XL beispielsweise API Priority and Fairness (APF) mit 6.800 gleichzeitigen Anforderungsplätzen konfiguriert wird, hängt der tatsächliche Anforderungsdurchsatz, den Sie von der Steuerungsebene erhalten, von der Art der ausgeführten Operationen ab. [Kubernetes bestraft beispielsweise Listenanfragen stärker als Get-Anfragen, sodass die effektive Anzahl von Listenanfragen, die gleichzeitig von der Steuerebene verarbeitet werden, geringer ist als die von Get-Anfragen (siehe hier).](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness) Auch wenn der Standard-Scheduler-QPS für ein 4XL-Tier auf 400 gesetzt ist, hängt Ihre tatsächliche Pod-Scheduling-Rate von Faktoren wie der Bereitschaft und Funktionsfähigkeit der Knoten für die Planung ab. Um eine optimale Leistung zu erzielen, sollten Sie sicherstellen, dass Ihre Anwendungen den Best Practices von Kubernetes folgen (siehe [hier](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)) und dass sie für Ihre Workload-Merkmale richtig konfiguriert sind.
## Überlegungen
+ **Kapazität der Standard-Steuerungsebene** — Der Standard-Steuerungsebenenmodus von EKS bietet das beste Preis-Leistungs-Verhältnis und ist die empfohlene Option für die meisten Anwendungsfälle. Für spezielle Workloads, die keine Leistungsschwankungen aufgrund der Skalierung der Steuerungsebene tolerieren können, oder solche, die eine sehr hohe Kapazität der Steuerungsebene erfordern, können Sie jedoch optional den Bereitstellungsmodus in Betracht ziehen.
+ **Opt-In erforderlich** — Bestehende Cluster werden nicht automatisch von der Standard-Steuerebene auf eine [teurere](https://aws.amazon.com/eks/pricing/) EKS Provisioned Control Plane Stufe hochskaliert. Sie müssen sich ausdrücklich für eine der neuen Skalierungsstufen von EKS Provisioned Control Plane entscheiden.
+ **Ausgangsbeschränkung** — Der Standardmodus der Steuerungsebene unterstützt eine Cluster-Datenbankgröße (etcd) von bis zu 8 GB. Wenn die Datenbankgröße Ihres Clusters im Bereitstellungsmodus 8 GB überschreitet, können Sie erst wieder in den Standardmodus wechseln, wenn Sie die Datenbankgröße auf unter 8 GB reduziert haben. Wenn Sie beispielsweise 14 GB Datenbankspeicher im Bereitstellungsmodus verwenden, müssen Sie zunächst die Datenbankauslastung auf weniger als 8 GB reduzieren, bevor Sie zum Standardmodus zurückkehren.
+ **Keine automatische Stufenskalierung** — EKS Provisioned Control Plane skaliert nicht automatisch zwischen den Stufen. Sobald Sie eine Skalierungsstufe ausgewählt haben, bleibt die Steuerungsebene Ihres Clusters an diese Stufe gebunden, sodass eine konsistente und vorhersehbare Leistung gewährleistet ist. Sie haben jedoch die Flexibilität, Ihre eigene Autoscaling-Lösung zu implementieren, indem Sie die Nutzungskennzahlen der Stufen überwachen und mithilfe der EKS Provisioned Control Plane APIs nach oben oder unten skalieren, wenn diese Metriken die von Ihnen definierten Schwellenwerte überschreiten, sodass Sie die volle Kontrolle über Ihre Skalierungsstrategie und Kostenoptimierung haben.
+ **Aktuelle Stufe anzeigen** — Sie können die Amazon EKS-Konsole, Amazon Web Services CLI oder API verwenden, um die aktuelle Skalierungsstufe der Steuerungsebene anzuzeigen. In der CLI können Sie den `describe-cluster` folgenden Befehl ausführen: `aws eks describe-cluster --name cluster-name`
+ **Zeit für den Tier-Übergang** — Sie können die Amazon EKS-Konsole, Amazon EKS oder CLI verwenden APIs, um die Skalierungsstufen zu beenden oder zwischen ihnen zu wechseln. Amazon EKS hat einen neuen Cluster-Aktualisierungstyp namens eingeführt`ScalingTierConfigUpdate`, den Sie überprüfen können, um den Fortschritt der Umstellung zu überwachen. Nachdem Sie einen Befehl zur Änderung der Stufe ausgeführt haben, können Sie die Updates auf dem Cluster auflisten, um ein neues Update des Typs `ScalingTierConfigUpdate` mit Status zu sehen`Updating`. Der Status `Successful` wird nach Abschluss des Updates oder bei Auftreten eines `Failed` Fehlers auf geändert. Das Fehlerfeld im Update gibt den Grund für den Fehler an. Es gibt keine Einschränkungen, wie oft Sie zwischen den Stufen wechseln können. Das Ändern der Stufe der Steuerungsebene dauert mehrere Minuten. Während dieses Vorgangs gibt es keine Ausfallzeiten der API-Server, da EKS neue API-Server hochfährt, bevor alte beendet werden.
+ **Auswahl der optimalen Stufe** — Um die optimale Skalierungsstufe der Provisioned Control Plane für Ihren Cluster zu ermitteln, können Sie Lasttests durchführen, indem Sie Ihren Cluster auf der höchsten Stufe (8XL) bereitstellen. Führen Sie anschließend einen Lasttest durch, um Spitzenlasten auf der Steuerungsebene Ihres Clusters zu simulieren. Beobachten Sie die Nutzungsmetriken der Kontrollebene bei Spitzenlast und verwenden Sie diese Beobachtungen als Richtschnur für die Auswahl der geeigneten Stufe für den Bereitstellungsmodus.
+ **Preise für die bereitgestellte Kontrollebene** — Ihnen wird der Stundensatz für die Skalierungsstufe „Provisioned Control Plane“ in Rechnung gestellt, auf der sich Ihr Cluster befindet. Dies gilt zusätzlich zu den Stundengebühren für Standard- oder Extended-Support. Weitere Informationen finden Sie auf der Amazon [EKS-Preisseite](https://aws.amazon.com/eks/pricing/).
+ **Größere Skalierungsstufe** — Wenn Sie beabsichtigen, Ihren Cluster auf einer Skalierungsstufe von mehr als 8XL auszuführen, wenden Sie sich an Ihr Amazon Web Services Services-Kundenbetreuungsteam, um weitere Preisinformationen zu erhalten.
+ **Unterstützung für Kubernetes-Versionen und Regionen** — EKS Provisioned Control Plane wird in allen kommerziellen und China Regionen von Amazon Web Services unterstützt. GovCloud Provisioned Control Plane funktioniert auf EKS v1.28 und höher.
# Erste Schritte mit der Amazon EKS Provisioned Control Plane
Dieses Handbuch führt Sie durch die Schritte zur Einrichtung und Verwendung der EKS Provisioned Control Plane mithilfe von AWS CLI und AWS-Managementkonsole.
## Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
+ ** AWS CLI** — Ein Befehlszeilentool für die Arbeit mit AWS Services, einschließlich Amazon EKS. Weitere Informationen finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Wir empfehlen, dass Sie die AWS CLI nach der Installation ebenfalls konfigurieren. Weitere Informationen finden Sie unter [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*. Beachten Sie, dass AWS CLI v2 erforderlich ist, um die auf dieser Seite gezeigte Option **update-kubeconfig** zu verwenden.
+ **Erforderliche IAM-Berechtigungen** — Der von Ihnen verwendete IAM-Sicherheitsprinzipal muss über Berechtigungen verfügen, um mit Amazon EKS-IAM-Rollen, serviceverknüpften Rollen AWS CloudFormation, einer VPC und verwandten Ressourcen zu arbeiten. *Weitere Informationen finden Sie unter [Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) und [Verwenden von serviceverknüpften Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) im IAM-Benutzerhandbuch.* Sie müssen alle Schritte in diesem Handbuch als derselbe Benutzer ausführen. Führen Sie den folgenden Befehl aus, um den aktuellen Benutzer zu überprüfen:
```
aws sts get-caller-identity
```
**Anmerkung**
Wir empfehlen, dass Sie die Schritte in diesem Thema in einer Bash-Shell ausführen. Wenn Sie keine Bash-Shell verwenden, erfordern einige Skript-Befehle wie Zeilenfortsetzungszeichen und die Art und Weise, wie Variablen gesetzt und verwendet werden, eine Anpassung für Ihre Shell. Darüber hinaus können die Zitier- und Escape-Regeln für Ihre Shell unterschiedlich sein. Weitere Informationen finden Sie unter [Verwenden von Anführungszeichen mit Zeichenfolgen in der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*.
## Von EKS bereitgestellte Steuerungsebene — CLI AWS
### Erstellen Sie einen Cluster mit EKS Provisioned Control Plane Scaling Tier
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
Antwort:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Sehen Sie sich die Skalierungsstufe der Steuerungsebene des Clusters an
```
aws eks describe-cluster --name prod-cluster
```
Antwort:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Aktualisieren Sie den Cluster so, dass er die EKS Provisioned Control Plane verwendet
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
Antwort:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### Update zur Skalierung der Steuerungsebene anzeigen
```
aws eks list-updates --name example
```
Antwort:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### Verlassen Sie die bereitgestellte Steuerungsebene auf die Standard-Steuerungsebene
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
Antwort:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## Von EKS bereitgestellte Steuerungsebene - AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie **Cluster erstellen**.
1. Wählen Sie unter *Konfigurationsoptionen* die Option **Benutzerdefinierte Konfiguration** aus.
1. Scrollen Sie nach unten zur **Skalierungsstufe der Kontrollebene**. Wählen Sie **Skalierungsebene verwenden** aus, um Provisioned Control Plane zu aktivieren.
1. Wählen Sie aus verschiedenen Skalierungsstufenoptionen wie XL, 2XL, 4XL und 8XL die Skalierungsstufe der Steuerungsebene aus, die Sie für den Cluster bereitstellen möchten.
1. Wählen Sie nach Bedarf weitere Optionen für die Clusterkonfiguration aus. Wählen Sie im letzten Schritt **Cluster erstellen** aus. Beachten Sie, dass es mehrere Minuten dauern kann, bis die Clustererstellung abgeschlossen ist.
# Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken
Amazon-EKS-Cluster-Erkenntnisse bietet die Erkennung von Problemen und Empfehlungen zu deren Behebung, um Sie bei der Verwaltung Ihres Clusters zu unterstützen. Für jeden Amazon-EKS-Cluster werden automatisch wiederkehrende Überprüfungen anhand einer von Amazon EKS zusammengestellten Liste von Erkenntnissen durchgeführt. Diese *Erkenntnisprüfungen* werden vollständig von Amazon EKS verwaltet und bieten Empfehlungen zum Umgang mit etwaigen Ergebnissen.
## Cluster-Erkenntnis-Typen
+ **Konfigurationserkenntnisse**: Identifizieren Fehlkonfigurationen in Ihrer Einrichtung von EKS-Hybridknoten, welche die Funktionalität Ihres Clusters oder Ihrer Workloads beeinträchtigen könnten.
+ **Upgrade-Erkenntnisse**: Identifizieren Probleme, die sich auf Ihre Fähigkeit auswirken könnten, auf neue Versionen von Kubernetes zu aktualisieren.
## Überlegungen
+ **Häufigkeit**: Amazon EKS aktualisiert die Cluster-Erkenntnisse alle 24 Stunden. Alternativ können Sie sie manuell aktualisieren, um den neuesten Status anzuzeigen. Sie können beispielsweise Cluster-Erkenntnisse nach der Behebung eines Problems manuell aktualisieren, um zu sehen, ob das Problem behoben wurde.
+ **Berechtigungen**: Amazon EKS erstellt automatisch einen Cluster-Zugriffseintrag für Cluster-Erkenntnisse in jedem EKS-Cluster. Dieser Eintrag gewährt EKS die Berechtigung, Informationen zu Ihrem Cluster anzuzeigen Amazon EKS verwendet diese Informationen, um die Erkenntnisse zu generieren. Weitere Informationen finden Sie unter [Amazon EKSCluster InsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy).
## Anwendungsfälle
Cluster-Erkenntnisse in Amazon EKS bietet automatisierte Überprüfungen, um die Integrität, Zuverlässigkeit und optimale Konfiguration Ihrer Kubernetes-Cluster zu gewährleisten. Nachfolgend finden Sie wichtige Anwendungsfälle für Cluster-Erkenntnisse, darunter die Upgrade-Bereitschaft und die Fehlerbehebung bei der Konfiguration.
### Upgrade-Einblicke
Upgrade-Erkenntnisse sind eine bestimmte Art von Erkenntnisüberprüfungen innerhalb von Cluster-Erkenntnissen. Diese Überprüfungen liefern Erkenntnisse zur Bereitschaft für ein Kubernetes-Versions-Upgrade. Amazon EKS führt Upgrade-Erkenntnisüberprüfungen in jedem EKS-Cluster durch.
**Wichtig**
Amazon EKS hat vorübergehend das Feature zurückgesetzt, das bei bestimmten Problemen mit Cluster-Erkenntnissen die Verwendung eines `--force`-Flags für das Upgrade Ihres Clusters erforderlich gemacht hätte. Weitere Informationen finden Sie unter [Vorübergehende Rücknahme der Durchsetzung von Upgrade-Erkenntnisse bei der Aktualisierung der Cluster-Version](https://github.com/aws/containers-roadmap/issues/2570) auf GitHub.
Weitere Informationen zum Aktualisieren Ihres Clusters finden Sie unter [Schritt 3: Cluster-Steuerebene aktualisieren](update-cluster.md#update-cluster-control-plane).
Bevor Sie die Kubernetes-Version Ihres Clusters aktualisieren, können Sie die Registerkarte **Upgrade-Erkenntnisse** des Beobachtbarkeits-Dashboards in der [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters) verwenden. Wenn in Ihrem Cluster Probleme festgestellt wurden, überprüfen Sie diese und nehmen Sie entsprechende Korrekturen vor. Die Probleme enthalten Links zur Amazon-EKS- und Kubernetes-Dokumentation. Aktualisieren Sie nach der Behebung des Problems die Cluster-Erkenntnisse bei Bedarf, um die neuesten Erkenntnisse abzurufen Wenn alle Probleme behoben wurden, [aktualisieren Sie Ihren Cluster](update-cluster.md).
Amazon EKS liefert Erkenntnisse zur Bereitschaft für ein Kubernetes-Versions-Upgrade. Upgrade-Erkenntnisse identifizieren mögliche Probleme, die sich ggf. auf Kubernetes-Cluster-Upgrades auswirken. Dadurch müssen Administratoren weniger Zeit für die Vorbereitung von Upgrades aufwenden und die Zuverlässigkeit von Anwendungen unter neueren Kubernetes-Versionen erhöht sich. Cluster werden von Amazon EKS automatisch anhand einer Liste möglicher Probleme gescannt, die sich auf das Upgrade der Kubernetes-Version auswirken. Amazon EKS aktualisiert die Liste der Erkenntnisüberprüfungen regelmäßig auf der Grundlage der Änderungen, die in den einzelnen veröffentlichten Kubernetes-Versionen vorgenommen wurden.
Upgrade-Erkenntnisse von Amazon EKS beschleunigen den Test- und Überprüfungsprozess für neue Versionen. Sie ermöglichen es Cluster-Administratoren und Anwendungsentwicklern außerdem, die neuesten Kubernetes-Funktionen zu nutzen, indem sie auf mögliche Probleme hinweisen und Tipps zur Problembehandlung geben.
### Konfigurationseinblicke
EKS-Cluster-Erkenntnisse führen automatische Scans von Amazon-EKS-Clustern mit Hybridknoten durch, um Konfigurationsprobleme zu identifizieren, welche die Kommunikation zwischen der Kubernetes-Steuerebene und Webhooks, kubectl-Befehle wie exec und Protokolle und vieles mehr beeinträchtigen. Konfigurationserkenntnisse decken Probleme auf und liefern Empfehlungen zur Behebung, wodurch die Zeit bis zur vollständigen Funktionsfähigkeit der Hybridknoten-Konfiguration verkürzt wird.
## Erste Schritte
Um die Liste der durchgeführten Einblickprüfungen und alle relevanten Probleme anzuzeigen, die Amazon EKS identifiziert hat, können Sie die AWS-Managementkonsole, die AWS-CLI, AWS-SDKs und die Amazon-EKS-`ListInsights`-API-Operation verwenden. Um zu beginnen, sehen Sie sich [Cluster-Erkenntnisse anzeigen](view-cluster-insights.md) an.
# Cluster-Erkenntnisse anzeigen
Amazon EKS bietet zwei Arten von Einblicken: **Konfigurationseinblicke** und **Upgrade-Einblicke**. **Konfigurationseinblicke** identifizieren Fehlkonfigurationen in Ihrer Einrichtung von EKS Hybrid Nodes, welche die Funktionalität Ihres Clusters oder Ihrer Workloads beeinträchtigen könnten. **Upgrade-Einblicke** identifizieren Probleme, die sich auf Ihre Fähigkeit auswirken könnten, auf neue Versionen von Kubernetes zu aktualisieren.
Um die Liste der durchgeführten Insight-Checks und alle relevanten Probleme, die Amazon EKS identifiziert hat, zu sehen, können Sie den Vorgang „Look in the“ AWS-Managementkonsole, „ AWS CLI“ und „Amazon EKS `ListInsights` API“ aufrufen. AWS SDKs
## Konfigurationserkenntnisse anzeigen (Konsole)
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie in der Clusterliste den Namen des Amazon-EKS-Clusters aus, für den Sie die Erkenntnisse anzeigen möchten.
1. Wählen Sie **Cluster überwachen** aus.
1. Wählen Sie die Registerkarte **Cluster-Zustand** aus.
1. In der Tabelle **Konfigurationsinformationen** werden die folgenden Spalten angezeigt:
+ **Name**: Die Überprüfung, die von Amazon EKS für den Cluster durchgeführt wurde.
+ **Erkenntnisstatus ** – Eine Erkenntnis mit dem Status `Error` weist auf eine Fehlkonfiguration hin, die wahrscheinlich die Cluster-Funktionalität beeinträchtigt. Eine Erkenntnis mit dem Status `Warning` bedeutet, dass die Konfiguration nicht dem dokumentierten Ansatz entspricht, die Cluster-Funktionalität jedoch möglicherweise funktioniert, wenn Sie sie absichtlich konfiguriert haben. Eine Erkenntnis mit dem Status `Passing` bedeutet, dass Amazon EKS keine Probleme im Zusammenhang mit dieser Erkenntnisüberprüfung in Ihrem Cluster festgestellt hat.
+ **Version** – Die anwendbare Version.
+ **Zeit der letzten Aktualisierung** – Der Zeitpunkt, zu dem der Status der Erkenntnis für diesen Cluster zuletzt aktualisiert wurde.
+ **Beschreibung**: Informationen der letzten Erkenntnisüberprüfung (einschließlich der Warnung und der empfohlenen Behandlungsmaßnahmen).
## Upgrade-Einblicke anzeigen (Konsole)
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie in der Clusterliste den Namen des Amazon-EKS-Clusters aus, für den Sie die Erkenntnisse anzeigen möchten.
1. Wählen Sie **Cluster überwachen** aus.
1. Wählen Sie die Registerkarte **Upgrade-Erkenntnisse** aus.
1. Um die neuesten Daten anzuzeigen, klicken Sie auf die Schaltfläche **Erkenntnisse aktualisieren** und warten Sie, bis der Aktualisierungsvorgang abgeschlossen ist.
1. In der Tabelle **Upgrade-Erkenntnisse** werden die folgenden Spalten angezeigt:
+ **Name**: Die Überprüfung, die von Amazon EKS für den Cluster durchgeführt wurde.
+ **Erkenntnisstatus:** – Eine Erkenntnis mit dem Status „Fehler“ bedeutet normalerweise, dass die betroffene Kubernetes-Version N\$11 der aktuellen Cluster-Version ist, während der Status „Warnung“ bedeutet, dass die Erkenntnis für eine zukünftige Kubernetes-Version N\$12 oder höher gilt. Eine Erkenntnis mit dem Status „Bestanden“ bedeutet, dass Amazon EKS keine Probleme im Zusammenhang mit dieser Erkenntnisüberprüfung in Ihrem Cluster festgestellt hat. Bei einer Erkenntnis mit dem Status „Unbekannt“ kann Amazon EKS nicht feststellen, ob Ihr Cluster von dieser Erkenntnisüberprüfung betroffen ist.
+ **Version** – Die Kubernetes-Version, die das Erkenntnis auf mögliche Probleme überprüft hat.
+ **Zeit der letzten Aktualisierung** – Der Zeitpunkt, zu dem der Status der Erkenntnis für diesen Cluster zuletzt aktualisiert wurde.
+ **Letzte Übergangszeit** – Der Zeitpunkt, zu dem sich der Status dieser Erkenntnis zuletzt geändert hat.
+ **Beschreibung**: Informationen der letzten Erkenntnisüberprüfung (einschließlich der Warnung und der empfohlenen Behandlungsmaßnahmen).
## Cluster-Einblicke anzeigen (AWS CLI)
1. Um die neuesten Daten anzuzeigen, aktualisieren Sie die Erkenntnisse für einen angegebenen Cluster. Nehmen Sie nach Bedarf die folgenden Änderungen am Befehl vor und führen Sie anschließend den geänderten Befehl aus:
+ *region-code*Ersetzen Sie es durch den Code für Ihre AWS Region.
+ Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. Um den Status einer Erkenntnisaktualisierung zu verfolgen, führen Sie den folgenden Befehl aus. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. Listen Sie die Erkenntnisse für einen angegebenen Cluster auf. Nehmen Sie nach Bedarf die folgenden Änderungen am Befehl vor und führen Sie anschließend den geänderten Befehl aus:
+ Ersetze es *region-code* durch den Code für deine AWS Region.
+ Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. Um beschreibende Informationen zu einer Erkenntnis zu erhalten, führen Sie den folgenden Befehl aus. Nehmen Sie nach Bedarf die folgenden Änderungen am Befehl vor und führen Sie anschließend den geänderten Befehl aus:
+ Ersetze es *region-code* durch den Code für deine AWS Region.
+ *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222*Ersetzen Sie es durch eine Insight-ID, die aus der Auflistung der Cluster-Insights abgerufen wurde.
+ Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version
**Tipp**
[Melden Sie sich](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) für bevorstehende Amazon EKS-Workshops an.
Wenn eine neue Kubernetes-Version in Amazon EKS verfügbar ist, können Sie Ihren Amazon-EKS-Cluster auf die neueste Version aktualisieren.
**Wichtig**
Nach der Aktualisierung eines Clusters ist ein Downgrade auf eine frühere Version nicht mehr möglich. Bevor Sie auf eine neue Kubernetes-Version aktualisieren, empfehlen wir Ihnen, die Informationen unter [Kubernetes-Versionslebenszyklus in EKS verstehen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) und die Aktualisierungsschritte in diesem Thema zu lesen.
Neue Kubernetes-Versionen führen oft bedeutende Änderungen ein. Daher empfehlen wir Ihnen, das Verhalten Ihrer Anwendungen mit einer neuen Kubernetes-Version zu testen, bevor Sie Ihre Produktionscluster aktualisieren. Hierzu erstellen Sie einen kontinuierlichen Integrations-Workflow, um das Verhalten Ihrer Anwendungen zu testen, bevor Sie auf eine neue Kubernetes-Version aktualisieren.
Der Aktualisierungsprozess besteht darin, dass Amazon EKS neue API-Serverknoten mit der aktualisierten Kubernetes-Version startet, um die vorhandenen zu ersetzen. Amazon EKS führt auf diesen neuen Knoten standardmäßige Infrastruktur- und Bereitschafts-Zustandsprüfungen für den Netzwerkverkehr durch, um sicherzustellen, dass sie wie erwartet funktionieren. Sobald Sie das Cluster-Upgrade gestartet haben, können Sie es jedoch weder anhalten noch beenden. Wenn eine dieser Prüfungen fehlschlägt, macht Amazon EKS die Infrastruktur-Bereitstellung rückgängig und der Cluster verbleibt in der vorherigen Kubernetes-Version. Laufende Anwendungen sind davon nicht betroffen und Ihr Cluster befindet sich nie in einem nicht deterministischen oder nicht wiederherstellbaren Zustand. Amazon EKS sichert regelmäßig alle verwalteten Cluster, und es gibt Mechanismen, um Cluster bei Bedarf wiederherzustellen. Wir evaluieren und verbessern unsere Verwaltungsprozesse für die Kubernetes-Infrastruktur fortlaufend.
Um den Cluster zu aktualisieren, benötigt Amazon EKS bis zu fünf verfügbare IP-Adressen aus den Subnetzen, die beim Erstellen des Clusters bereitgestellt wurden. Amazon EKS erstellt in jedem der von Ihnen angegebenen Subnetze neue Elastic-Network-Schnittstellen für den Cluster (Netzwerkschnittstellen). Die Netzwerkschnittstellen können in anderen Subnetzen erstellt werden als Ihre vorhandenen Netzwerkschnittstellen. Stellen Sie daher sicher, dass Ihre Sicherheitsgruppenregeln die [erforderliche Cluster-Kommunikation](sec-group-reqs.md) für jedes der Subnetze zulassen, die Sie bei der Erstellung Ihres Clusters angegeben haben. Wenn eines der Subnetze, die Sie bei der Erstellung des Clusters angegeben haben, nicht vorhanden ist, nicht genügend verfügbare IP-Adressen hat oder nicht über Sicherheitsgruppenregeln verfügt, welche die notwendige Cluster-Kommunikation zulassen, kann die Aktualisierung fehlschlagen.
Um sicherzustellen, dass der API-Server-Endpunkt für Ihren Cluster immer zugänglich ist, bietet Amazon EKS eine hochverfügbare Kubernetes-Steuerebene und führt während Aktualisierungsvorgängen fortlaufende Aktualisierungen der API-Server-Instances durch. Um wechselnde IP-Adressen von API-Server-Instances zu berücksichtigen, die Ihren Kubernetes-API-Server-Endpunkt unterstützen, müssen Sie sicherstellen, dass Ihre API-Server-Clients die Wiederverbindung effektiv verwalten. Aktuelle Versionen von `kubectl` und der Kubernetes-Client-[Bibliotheken](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api), die offiziell unterstützt werden, führen diesen Vorgang zur Wiederherstellung der Verbindung transparent durch.
**Anmerkung**
Weitere Informationen zu den Inhalten einer Cluster-Aktualisierung finden Sie unter [Bewährte Methoden für Cluster-Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) im EKS-Leitfaden für bewährte Methoden. Diese Ressource unterstützt Sie bei der Planung eines Upgrades und vermittelt Ihnen die Strategie für das Upgraden eines Clusters.
## Überlegungen zu Amazon EKS Auto Mode
+ Die Rechenleistung von Amazon EKS Auto Mode steuert die Kubernetes-Version der Knoten. Nach dem Upgrade der Steuerebene beginnt EKS Auto Mode mit der schrittweisen Aktualisierung der verwalteten Knoten. EKS Auto Mode berücksichtigt Budgets für Pod-Unterbrechung.
+ Sie müssen die Funktionen von Amazon EKS Auto Mode, einschließlich der automatischen Skalierung der Rechenleistung, des Blockspeichers und der Load-Balancing-Funktionen, nicht manuell aktualisieren.
## Zusammenfassung
Die allgemeine Zusammenfassung des Upgrade-Prozesses für Amazon-EKS-Cluster lautet wie folgt:
1. Stellen Sie sicher, dass sich Ihr Cluster in einem Zustand befindet, der ein Upgrade unterstützt. Dazu gehört die Überprüfung der Kubernetes-Ressourcen, die von den im Cluster bereitgestellten Ressourcen APIs verwendet werden, um sicherzustellen, dass der Cluster frei von Gesundheitsproblemen ist. Nutzen Sie die Upgrade-Informationen von Amazon EKS, um die Upgrade-Bereitschaft Ihres Clusters zu bewerten.
1. Führen Sie ein Upgrade der Steuerungsebene auf die nächste Nebenversion durch (z. B. von 1.34 auf 1.35).
1. Aktualisieren Sie die Knoten in der Datenebene, sodass sie mit denen der Steuerebene übereinstimmen.
1. Aktualisieren Sie alle weiteren Anwendungen, die in dem Cluster ausgeführt werden (z. B. `cluster-autoscaler`).
1. Aktualisieren Sie die von Amazon EKS bereitgestellten Add-Ons, beispielsweise die standardmäßig enthaltenen:
+ [Empfohlene Amazon-VPC-CNI-Version](managing-vpc-cni.md)
+ [Empfohlene CoreDNS-Version](managing-coredns.md)
+ [Von `kube-proxy` empfohlene Version](managing-kube-proxy.md)
1. Aktualisieren Sie alle Clients, die mit dem Cluster kommunizieren (z. B. `kubectl`).
## Schritt 1: Upgrade vorbereiten
Vergleichen Sie die Kubernetes-Version Ihrer Cluster-Steuerebene mit der Kubernetes-Version Ihrer Knoten.
+ Rufen Sie die Kubernetes-Version Ihrer Cluster-Steuerebene ab.
```
kubectl version
```
+ Rufen Sie die Kubernetes-Version Ihrer Knoten ab. Dieser Befehl gibt alle selbstverwalteten und verwalteten Amazon-EC2-, Fargate- und Hybridknoten zurück. Jeder Fargate-Pod wird als eigener Knoten aufgeführt.
```
kubectl get nodes
```
Bevor Sie Ihre Steuerebene auf eine neue Kubernetes-Version aktualisieren, stellen Sie sicher, dass die Kubernetes-Minor-Version sowohl der verwalteten Knoten als auch der Fargate-Knoten in Ihrem Cluster mit der Version Ihrer Steuerebene übereinstimmt. Wenn auf Ihrer Steuerungsebene beispielsweise Version ausgeführt wird `1.29` und auf einem Ihrer Knoten die Version ausgeführt wird`1.28`, müssen Sie Ihre Knoten auf Version aktualisieren, `1.29` bevor Sie Ihre Kontrollebene auf 1.30 aktualisieren. Wir empfehlen Ihnen außerdem, Ihre selbstverwalteten Knoten und Hybridknoten auf dieselbe Version wie Ihre Steuerebene zu aktualisieren, bevor Sie die Steuerebene aktualisieren. Weitere Informationen finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md), [Selbstverwaltete Knoten für Ihren Cluster aktualisieren](update-workers.md) und [Aktualisierung von Hybridknoten für Ihren Cluster](hybrid-nodes-upgrade.md). Wenn Sie Fargate-Knoten mit einer Nebenversion haben, die niedriger ist als die Version der Steuerebene, löschen Sie zunächst den Pod, der durch den Knoten dargestellt wird. Aktualisieren Sie dann Ihre Steuerebene. Alle verbleibenden Pods werden auf die neue Version aktualisiert, nachdem Sie sie neu bereitgestellt haben.
## Schritt 2: Überlegungen zum Upgrade prüfen
Amazon-EKS-Cluster-Erkenntnisse überprüfen Cluster automatisch anhand einer Liste potenzieller Probleme, die sich auf Upgrades der Kubernetes-Version auswirken können, wie beispielsweise die Verwendung veralteter Kubernetes-APIs Amazon EKS aktualisiert regelmäßig die Liste der durchzuführenden Erkenntnisprüfungen basierend auf Bewertungen von Änderungen im Kubernetes-Projekt. Amazon EKS aktualisiert die Liste der Erkenntnisprüfungen auch, wenn Änderungen im Amazon-EKS-Service zusammen mit neuen Versionen eingeführt werden. Weitere Informationen finden Sie unter [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md).
Lesen Sie den [Migrationsleitfaden für veraltete APIs](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) in den Kubernetes-Dokumenten.
### Upgrade-Erkenntnisse überprüfen
Nutzen Sie die Upgrade-Erkenntnisse von Amazon EKS, um Probleme zu identifizieren. Weitere Informationen finden Sie unter [Upgrade-Einblicke anzeigen (Konsole)](view-cluster-insights.md#view-upgrade-insights-console).
### Detaillierte Überlegungen
+ Da Amazon EKS eine hoch verfügbare Steuerebene ausführt, dürfen Sie jeweils nur um eine Unterversion aktualisieren. Weitere Informationen zu dieser Anforderung finden Sie unter [Kubernetes-Version und Version-Skew-Supportrichtlinie](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver). Angenommen, Ihre aktuelle Cluster-Version ist Version `1.28` und Sie möchten sie auf Version `1.30` aktualisieren. Sie müssen zuerst Ihren Version `1.28`-Cluster auf Version `1.29` und dann Ihren Version `1.29`-Cluster auf Version `1.30` aktualisieren.
+ Überprüfen Sie den Versionsunterschied zwischen Kubernetes `kube-apiserver` und `kubelet` auf Ihren Knoten.
+ Ab der Kubernetes-Version `1.28` kann `kubelet` bis zu drei Nebenversionen älter sein als `kube-apiserver`. Weitere Informationen finden Sie in der [Richtlinie zum Unterschied bei der Kubernetes-Upstream-Version](https://kubernetes.io/releases/version-skew-policy/#kubelet).
+ Wenn das `kubelet` Ihrer verwalteten Knoten und Ihrer Fargate-Knoten mindestens über die `1.25`-Version oder neuer verfügt, können Sie Ihren Cluster um bis zu drei Versionen aktualisieren, ohne die `kubelet`-Version zu aktualisieren. Wenn das `kubelet` also beispielsweise über die Version `1.25` verfügt, können Sie die Version Ihres Amazon EKS-Clusters von `1.25` auf`1.26`, auf `1.27` und auf `1.28` aktualisieren und für `kubelet` die Version `1.25` beibehalten.
+ Vergewissern Sie sich daher vor dem Start einer Aktualisierung, dass das `kubelet` auf Ihren Knoten die gleiche Kubernetes-Version hat wie Ihre Steuerebene.
+ Wenn Ihr Cluster mit einer Version des Amazon-VPC-CNI-Plugins für Kubernetes konfiguriert ist, die älter als `1.8.0` ist, empfehlen wir Ihnen, das Plugin auf die neueste Version zu aktualisieren, bevor Sie Ihren Cluster aktualisieren. Informationen zum Aktualisieren des Plugins finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md).
+ Sie können eine Sicherungskopie Ihres Amazon EKS-Clusters erstellen, damit Sie Ihren Amazon EKS-Clusterstatus und den persistenten Speicher wiederherstellen können, falls während des Upgrade-Vorgangs Fehler auftreten. Siehe [Sichern Sie Ihre EKS-Cluster mit AWS Backup](integration-backup.md)
## Schritt 3: Cluster-Steuerebene aktualisieren
**Wichtig**
Amazon EKS hat vorübergehend das Feature zurückgesetzt, das bei bestimmten Problemen mit Cluster-Erkenntnissen die Verwendung eines `--force`-Flags für das Upgrade Ihres Clusters erforderlich gemacht hätte. Weitere Informationen finden Sie unter [Vorübergehendes Rollback der Durchsetzung von Upgrade-Erkenntnissen bei der Aktualisierung der Cluster-Version auf](https://github.com/aws/containers-roadmap/issues/2570). GitHub
Amazon EKS aktualisiert die Cluster-Erkenntnisse 24 Stunden nach der „letzten Aktualisierungszeit”. Sie können den Zeitpunkt, zu dem Sie ein Problem behoben haben, mit der „letzten Aktualisierungszeit” der Cluster-Übersicht vergleichen.
Darüber hinaus kann es bis zu 30 Tage dauern, bis der Erkenntnis-Status nach der Behebung einer veralteten API-Nutzung aktualisiert wird. Upgrade-Erkenntnisse suchen stets nach veralteter API-Nutzung über einen fortlaufenden Zeitraum von 30 Tagen.
Sie können die Anfrage zum Upgrade Ihrer EKS-Steuerebenen-Version wie folgt senden:
+ [eksctl](#step3-eksctl)
+ [die Konsole AWS](#step3-console)
+ [die AWS CLI](#step3-cli)
### Cluster aktualisieren – eksctl
Für diesen Vorgang ist `eksctl` Version `0.215.0` oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen:
```
eksctl version
```
Eine Installations- und Aktualisierungsanleitung für `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
Aktualisieren Sie die Kubernetes-Version Ihrer Amazon-EKS-Steuerebene. Ersetzen Sie `` mit Ihrem Clusternamen. Ersetzen Sie `` durch die von Amazon EKS unterstützte Versionsnummer, auf die Sie Ihren Cluster aktualisieren möchten. Eine Liste der unterstützten Versionsnummern finden Sie unter [Unterstützte Amazon-EKS-Versionen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
eksctl upgrade cluster --name --version --approve
```
Die Aktualisierung dauert einige Minuten.
Fahren Sie fort mit [Schritt 4: Cluster-Komponenten aktualisieren](#step4).
### Cluster aktualisieren — AWS Konsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie **Jetzt aktualisieren** für den Cluster, den Sie aktualisieren möchten.
1. Wählen Sie die Version aus, auf die Ihr Cluster aktualisiert werden soll, und wählen Sie **Upgrade**.
1. Die Aktualisierung dauert einige Minuten. Fahren Sie fort mit [Schritt 4: Cluster-Komponenten aktualisieren](#step4).
### Cluster aktualisieren — AWS CLI
1. Stellen Sie sicher, dass die AWS CLI installiert ist und ob Sie angemeldet sind. Weitere Informationen finden Sie unter [Installation oder Aktualisierung auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Aktualisieren Sie Ihren Amazon EKS-Cluster mit dem folgenden AWS CLI-Befehl. Ersetzen Sie `` und `` des Clusters, den Sie aktualisieren möchten. Ersetzen Sie `` durch die von Amazon EKS unterstützte Versionsnummer, auf die Sie Ihren Cluster aktualisieren möchten. Eine Liste der unterstützten Versionsnummern finden Sie unter [Unterstützte Amazon-EKS-Versionen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. Die Aktualisierung dauert einige Minuten. Überwachen Sie den Status Ihres Cluster-Updates mit dem folgenden Befehl. Verwenden Sie zusätzlich zur Verwendung desselben `` und `` das ``, das der vorherige Befehl zurückgegeben hat.
```
aws eks describe-update --name \
--region --update-id
```
Wenn der Status `Successful` angezeigt wird, ist das Update abgeschlossen.
1. Fahren Sie fort mit [Schritt 4: Cluster-Komponenten aktualisieren](#step4).
## Schritt 4: Cluster-Komponenten aktualisieren
1. Nachdem Ihre Cluster-Aktualisierung abgeschlossen wurde, aktualisieren Sie Ihre Knoten auf dieselbe Kubernetes-Nebenversion wie Ihr aktualisierter Cluster. Weitere Informationen finden Sie unter [Selbstverwaltete Knoten für Ihren Cluster aktualisieren](update-workers.md), [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md) und [Aktualisierung von Hybridknoten für Ihren Cluster](hybrid-nodes-upgrade.md). Alle neuen Pods, die in Fargate gestartet werden, verfügen über eine `kubelet`-Version, die Ihrer Cluster-Version entspricht. Vorhandene Fargate-Pods werden nicht geändert.
1. (Optional) Wenn Sie den Kubernetes Cluster Autoscaler in Ihrem Cluster bereitgestellt haben, bevor Sie den Cluster aktualisiert haben, aktualisieren Sie den Cluster Autoscaler auf die neueste Version, die der Kubernetes-Haupt- und Nebenversion entspricht, auf die Sie aktualisiert haben.
1. Öffnen Sie die Seite Cluster-Autoscaler-[Versionen](https://github.com/kubernetes/autoscaler/releases) in einem Web-Browser und suchen Sie die neuste Cluster-Autoscaler-Version, die der Haupt- und Nebenversion Ihres Kubernetes-Clusters entspricht. Wenn beispielsweise die Kubernetes-Version Ihres Clusters `1.30` lautet, suchen Sie die neueste Cluster-Autoscaler-Version, die mit `1.30` beginnt. Notieren Sie die semantische Versionsnummer (z. B. `1.30.n`) für diese Version, um sie im nächsten Schritt zu verwenden.
1. Legen Sie das Cluster Autoscaler-Abbild-Tag mit dem folgenden Befehl auf die Version fest, die Sie im vorherigen Schritt notiert haben. Ersetzen Sie ggf. `X.XX.X` durch Ihren eigenen Wert.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (Nur Cluster mit GPU-Knoten) Wenn Ihr Cluster Knotengruppen mit GPU-Unterstützung hat (z. B.`p3.2xlarge`), müssen Sie das [NVIDIA-Geräte-Plugin für Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) DaemonSet auf Ihrem Cluster aktualisieren. Ersetzen Sie es `` durch die gewünschte [s-device-pluginNVIDIA/K8-Version](https://github.com/NVIDIA/k8s-device-plugin/releases), bevor Sie den folgenden Befehl ausführen.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Aktualisieren Sie das Amazon-VPC-CNI-Plugin für Kubernetes, CoreDNS und `kube-proxy`-Add-Ons. Wir empfehlen, die Add-Ons auf die Mindestversionen zu aktualisieren, die unter [Servicekonto-Tokens](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions) aufgeführt sind.
+ Wenn Sie Amazon-EKS-Add-Ons verwenden, wählen Sie **Clusters** (Cluster) in der Amazon-EKS-Konsole und dann im linken Navigationsbereich den Namen des Clusters aus, den Sie aktualisiert haben. In der Konsole werden Benachrichtigungen angezeigt. Diese informieren Sie darüber, dass für jedes Add-On, für das eine Aktualisierung verfügbar ist, eine neue Version verfügbar ist. Um ein Add-on zu aktualisieren, wählen Sie die Registerkarte **Add-ons** aus. Wählen Sie in einem der Felder für ein Add-on, für das eine Aktualisierung verfügbar ist, **Jetzt aktualisieren** aus, wählen Sie eine verfügbare Version aus, und wählen Sie dann **Aktualisieren** aus.
+ Alternativ können Sie die AWS CLI verwenden oder `eksctl` Add-Ons aktualisieren. Weitere Informationen finden Sie unter [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.md).
1. Sofern erforderlich, aktualisieren Sie Ihre Version von `kubectl`. Sie müssen eine `kubectl`-Version verwenden, die nur in der Minor-Version von Ihrer Amazon–EKS-Cluster-Steuerebene abweicht.
## Herabstufen der Kubernetes-Version für einen Amazon-EKS-Cluster
Sie können die Kubernetes-Version eines Amazon-EKS-Clusters nicht herabstufen. Erstellen Sie stattdessen einen neuen Cluster auf einer früheren Amazon-EKS-Version und migrieren Sie die Workloads.
# Einen Cluster löschen
Wenn Sie einen Amazon-EKS-Cluster nicht mehr benötigen, sollten Sie die zugehörigen Ressourcen löschen, um unnötige Kosten zu vermeiden.
Sie können einen Cluster mit `eksctl` AWS-Managementkonsole, der oder der AWS CLI löschen.
## Überlegungen
+ Wenn Sie eine Fehlermeldung erhalten, weil der Cluster-Ersteller entfernt wurde, lesen Sie [diesen Artikel](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error).
+ Amazon Managed Service für Prometheus-Ressourcen liegen außerhalb des Cluster-Lebenszyklus und müssen unabhängig vom Cluster verwaltet werden. Wenn Sie Ihren Cluster löschen, löschen Sie auch alle relevanten Scraper, um damit verbundenen Kosten zu vermeiden. Weitere Informationen finden Sie unter [Suchen und Löschen eine Scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
+ Informationen zum Entfernen eines verbundenen Clusters finden Sie unter [Abmelden eines Kubernetes-Clusters von der Amazon-EKS-Konsole](deregister-connected-cluster.md).
+ Bevor Sie einen Cluster löschen können, stellen Sie sicher, dass der Löschschutz für Ihren Cluster deaktiviert ist.
### Überlegungen zu EKS Auto Mode
+ Alle Knoten von EKS Auto Mode werden gelöscht, einschließlich der verwalteten EC2-Instances.
+ Alle Load Balancer werden gelöscht
Weitere Informationen finden Sie unter [EKS Auto Mode deaktivieren](auto-disable.md).
## Voraussetzungsschritte
Die folgenden Schritte müssen Sie zuerst ausführen, bevor Sie einen Cluster löschen können. Diese Schritte gelten unabhängig von der Methode, die Sie zum Löschen Ihres Clusters verwenden.
1. Listen Sie alle in Ihrem Cluster ausgeführten Services auf.
```
kubectl get svc --all-namespaces
```
1. Löschen Sie alle Services, die dem Wert `EXTERNAL-IP` zugeordnet sind. Diese Services werden hinter einem Elastic-Load-Balancing-Load-Balancer ausgeführt und müssen in Kubernetes gelöscht werden, damit der Load Balancer und die zugeordneten Ressourcen korrekt freigegeben werden können. *service-name*Ersetzen Sie es durch den Namen der einzelnen Dienste, die wie beschrieben aufgeführt sind.
```
kubectl delete svc service-name
```
1. Löschen Sie auch alle eingehenden Ressourcen. Wenn Sie die Eingangsressourcen nicht löschen, bleibt der Application Load Balancer bestehen, auch wenn Sie den Cluster gelöscht haben. *ingress-name*Ersetzen Sie es durch den Namen Ihrer Eingangsressourcen.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## Cluster löschen (eksctl)
Für diesen Vorgang ist `eksctl` Version `0.215.0` oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen:
```
eksctl version
```
Eine Installations- und Upgrade-Anleitung für `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
1. Gehen Sie die [erforderlichen Schritte](#prerequisite-steps) durch. Löschen Sie anschließend Ihren Cluster und die zugehörigen Knoten mit dem folgenden Befehl und ersetzen *prod* Sie ihn durch Ihren Clusternamen.
```
eksctl delete cluster --name prod
```
Ausgabe:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## Cluster löschen (AWS Konsole)
1. Gehen Sie die [erforderlichen Schritte](#prerequisite-steps) durch. Löschen Sie anschließend alle Knotengruppen und Fargate-Profile.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Clusters** (Cluster) für Amazon EKS aus, und wählen Sie dann in der Registerkartenliste der Cluster den Namen des zu löschenden Clusters aus.
1. Wählen Sie auf der Registerkarte **Compute** (Datenverarbeitung) eine zu löschende Knotengruppe aus. Klicken Sie auf **Delete** (Löschen), geben Sie den Namen der Knotengruppe ein und wählen Sie anschließend **Delete** (Löschen) aus. Alle Knotengruppen im Cluster löschen.
**Anmerkung**
Die aufgelisteten Knotengruppen sind nur [verwaltete Knotengruppen](managed-node-groups.md).
1. Wählen Sie ein zu löschendes **Fargate-Profil** aus, wählen Sie **Delete** (Löschen) aus, geben Sie den Namen des Profils ein und wählen Sie dann **Delete** (Löschen). Alle Fargate-Profile im Cluster löschen.
1. Löschen Sie alle [selbstverwalteten Knotenstapel AWS CloudFormation ](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie den Knoten-Stack aus, den Sie löschen möchten, und wählen Sie **Delete** (Löschen) aus.
1. Wählen Sie im Bestätigungsdialogfeld **Stack löschen** **Stack löschen** aus. Löschen Sie alle selbstverwalteten Knoten-Stacks im Cluster.
1. Löschen Sie den Cluster.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Cluster aus, der gelöscht werden soll, und klicken Sie auf **Delete ** (Löschen).
1. Klicken Sie auf dem Bestätigungsbildschirm zum Löschen des Clusters auf **Delete (Löschen)**.
1. (Optional) Löschen Sie den AWS CloudFormation VPC-Stack.
1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie den zu löschenden VPC-Stack und dann **Löschen** aus.
1. Wählen Sie im Bestätigungsdialogfeld **Stack löschen** **Stack löschen** aus.
## Cluster löschen (AWS CLI)
1. Gehen Sie die [erforderlichen Schritte](#prerequisite-steps) durch. Löschen Sie anschließend alle Knotengruppen und Fargate-Profile.
1. Listen Sie die Knotengruppen in Ihrem Cluster mit dem folgenden Befehl auf.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**Anmerkung**
Die aufgelisteten Knotengruppen sind nur [verwaltete Knotengruppen](managed-node-groups.md).
1. Löschen Sie jede Knotengruppe mit folgendem Befehl. Alle Knotengruppen im Cluster löschen.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. Listen Sie die Fargate-Profile in Ihrem Cluster mit dem folgenden Befehl auf.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. Löschen Sie jedes Fargate-Profil mit dem folgenden Befehl. Alle Fargate-Profile im Cluster löschen.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. Löschen Sie alle [selbstverwalteten Knotenstapel AWS CloudFormation ](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Listen Sie Ihre verfügbaren AWS CloudFormation Stacks mit dem folgenden Befehl auf. Suchen Sie den Vorlagennamen des Knotens in der sich daraus ergebenden Ausgabe.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Löschen Sie jeden Knoten-Stack mit dem folgenden Befehl und ersetzen Sie dabei *node-stack* durch den Namen Ihres Knoten-Stacks. Löschen Sie alle selbstverwalteten Knoten-Stacks im Cluster.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. Löschen Sie den Cluster mit dem folgenden Befehl und ersetzen Sie dabei *my-cluster* durch den Namen Ihres Clusters.
```
aws eks delete-cluster --name my-cluster
```
1. (Optional) Löschen Sie den AWS CloudFormation VPC-Stack.
1. Listen Sie Ihre verfügbaren AWS CloudFormation Stacks mit dem folgenden Befehl auf. Suchen Sie die VPC-Vorlage in der sich daraus ergebenden Ausgabe.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Löschen Sie den VPC-Stack mit dem folgenden Befehl und ersetzen Sie dabei *my-vpc-stack* durch den Namen Ihres VPC-Stacks.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# Schützen Ihrer EKS-Cluster vor versehentlichem Löschen
Das versehentliche Löschen eines EKS-Clusters kann den Betrieb des Kubernetes-Clusters beeinträchtigen.
Sie können EKS-Cluster nun vor versehentlichem Löschen schützen. Wenn Sie den Löschschutz für einen Cluster aktivieren, müssen Sie diesen zunächst deaktivieren, bevor Sie den Cluster löschen können.
Der Löschschutz dient dazu, versehentliches Löschen zu verhindern. Sie sollten sorgfältig festlegen, wer zum Löschen von Clustern berechtigt ist.
Wenn Sie versuchen, einen aktiven Cluster zu löschen, für den der Löschschutz aktiviert ist, erhalten Sie eine `InvalidRequestException`.
**Wichtig**
Wenn Sie den Löschschutz auf einem Cluster aktivieren, benötigen Sie **sowohl die als auch** die UpdateClusterConfig DeleteCluster IAM-Berechtigungen, um zuerst den Löschschutz zu entfernen und schließlich den Cluster zu löschen.
**Anmerkung**
Wenn der Cluster-Status „Erstellen“, „Fehler“ oder „Löschen“ lautet, können Sie den Cluster auch dann löschen, wenn der Löschschutz aktiviert ist.
## Aktivierung des Löschschutzes für einen vorhandenen Cluster
Sie können dies nur in einem Cluster im aktiven Status ausführen.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## So deaktivieren Sie den Löschschutz für einen vorhandenen Cluster
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# Cluster-API-Server-Endpunkt
Dieses Thema hilft Ihnen, den privaten Zugriff für den Kubernetes-API-Server-Endpunkt Ihres Amazon-EKS-Clusters zu aktivieren und den öffentlichen Zugriff über das Internet einzuschränken oder vollständig zu deaktivieren.
Wenn Sie einen neuen Cluster erstellen, erstellt Amazon EKS einen Endpunkt für den verwalteten Kubernetes-API-Server, über den Sie mit Ihrem Cluster kommunizieren (mit Kubernetes-Verwaltungswerkzeugen wie `kubectl`). Standardmäßig ist dieser API-Serverendpunkt im Internet öffentlich, und der Zugriff auf den API-Server wird mithilfe einer Kombination aus AWS Identity and Access Management (IAM) und nativer Kubernetes [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) gesichert. Dieser Endpunkt wird als *öffentlicher Cluster-Endpunkt* bezeichnet. Es gibt auch einen *privaten Cluster-Endpunkt*. Weitere Informationen zum privaten Cluster-Endpunkt finden Sie im folgenden Abschnitt [Privater Cluster-Endpunkt](#cluster-endpoint-private).
## `IPv6`-Cluster-Endpunkt-Format
EKS erstellt für neue `IPv6`-Cluster, die nach Oktober 2024 erstellt werden, einen eindeutigen Dual-Stack-Endpunkt im folgenden Format: Ein *IPv6 Cluster* ist ein Cluster, den Sie `IPv6` in der IP-Familie (`ipFamily`) -Einstellung des Clusters auswählen.
**Example**
public/private EKS-Cluster-Endpunkt: `eks-cluster.region.api.aws`
public/private EKS-Cluster-Endpunkt: `eks-cluster.region.api.aws`
public/private EKS-Cluster-Endpunkt: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**Anmerkung**
Der Dual-Stack-Cluster-Endpunkt wurde im Oktober 2024 eingeführt. Weitere Informationen zu `IPv6`-Clustern finden Sie unter [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md). Cluster, die vor Oktober 2024 erstellt wurden, verwenden stattdessen das folgende Endpunkt-Format.
## `IPv4`-Cluster-Endpunkt-Format
EKS erstellt für jeden Cluster, der in der IP-Familieneinstellung (ipFamily) des Clusters `IPv4` auswählt, einen eindeutigen Endpunkt im folgenden Format:
**Example**
public/private EKS-Cluster-Endpunkt `eks-cluster.region.eks.amazonaws.com`
public/private EKS-Cluster-Endpunkt `eks-cluster.region.eks.amazonaws.com`
public/private EKS-Cluster-Endpunkt `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**Anmerkung**
Vor Oktober 2024 verwendeten `IPv6`-Cluster auch dieses Endpunkt-Format. Bei diesen Clustern werden sowohl beim öffentlichen als auch beim privaten Endpunkt nur `IPv4`-Adressen von diesem Endpunkt aufgelöst.
## Privater Cluster-Endpunkt
Sie können den privaten Zugriff auf den Kubernetes-API-Server aktivieren, sodass die gesamte Kommunikation zwischen Ihren Knoten und dem API-Server innerhalb Ihrer VPC bleibt. Sie können die IP-Adressen einschränken, die über das Internet auf Ihren API-Server zugreifen können, oder den Internetzugriff auf den API-Server vollständig deaktivieren.
**Anmerkung**
Da dieser Endpunkt für den Kubernetes-API-Server und kein herkömmlicher AWS PrivateLink Endpunkt für die Kommunikation mit einer AWS API ist, wird er in der Amazon VPC-Konsole nicht als Endpunkt angezeigt.
Wenn Sie den privaten Endpunktzugriff für Ihren Cluster aktivieren, erstellt Amazon EKS in Ihrem Namen eine privat gehostete Route-53-Zone und ordnet diese der VPC Ihres Clusters zu. Diese private gehostete Zone wird von Amazon EKS verwaltet und wird nicht in den Route-53-Ressourcen Ihres Kontos angezeigt. Damit die private gehostete Zone Datenverkehr ordnungsgemäß an Ihren API-Server weiterleiten kann, müssen `enableDnsHostnames` und `enableDnsSupport` für Ihre VPC auf `true` gesetzt sein und die DHCP-Optionen für Ihre VPC müssen `AmazonProvidedDNS` in ihrer Domainnamen-Serverliste enthalten. Weitere Informationen finden Sie unter [Aktualisieren der DNS-Unterstützung für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) im *Amazon-VPC-Benutzerhandbuch*.
Sie können Ihre Anforderungen für den Zugriff auf Ihre API-Server-Endpunkte definieren, wenn Sie einen neuen Cluster erstellen. Sie können den Zugriff auf die API-Server-Endpunkte für einen Cluster jederzeit aktualisieren.
## Ändern des Cluster-Endpunktzugriffs
Verwenden Sie die Verfahren in diesem Abschnitt, um den Endpunktzugriff für einen bestehenden Cluster zu ändern. Die folgende Tabelle zeigt die unterstützten Kombinationen von API-Server-Endpunktzugriffen und das damit verbundene Verhalten.
| Endpunkt für öffentlichen Zugriff | Endpunkt für privaten Zugriff | Behavior |
| --- | --- | --- |
| Enabled | Disabled | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/cluster-endpoint.html) |
| Aktiviert | Aktiviert | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/cluster-endpoint.html) |
| Disabled | Aktiviert | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/cluster-endpoint.html) |
**Zugangskontrollen für Endgeräte**
Beachten Sie, dass sich jede der folgenden Methoden zur Steuerung des Endpunktzugriffs nur auf den jeweiligen Endpunkt auswirkt.
*Cluster-Sicherheitsgruppe*
Die Cluster-Sicherheitsgruppe steuert zwei Arten von Verbindungen: Verbindungen zur *Kubelet-API* und zum privaten Endpunkt. Die Verbindungen zur `kubelet` API werden in den Befehlen`kubectl attach`,, `kubectl cp` `kubectl exec``kubectl logs`, und `kubectl port-forward` verwendet. Die Cluster-Sicherheitsgruppe hat keine Auswirkungen auf den öffentlichen Endpunkt.
*Öffentlicher Zugriff CIDRs*
Der *öffentliche Zugriff CIDRs* steuert den Zugriff auf den öffentlichen Endpunkt anhand einer Liste von CIDR-Blöcken. Beachten Sie, dass der öffentliche Zugriff CIDRs keinen Einfluss auf den privaten Endpunkt hat. Der öffentliche Zugriff CIDRs verhält sich auf den `IPv6` Clustern und `IPv4` Clustern je nach dem Datum, an dem sie erstellt wurden, unterschiedlich. Dies wird im Folgenden beschrieben:
**CIDR-Blöcke im öffentlichen Endpunkt (`IPv6`-Cluster)**
Sie können `IPv6` und `IPv4`-CIDR-Blöcke zum öffentlichen Endpunkt eines `IPv6`-Clusters hinzufügen, da der öffentliche Endpunkt Dual-Stack-fähig ist. Dies gilt nur für neue Cluster mit dem Wert `ipFamily` auf `IPv6`, die Sie im Oktober 2024 oder später erstellt haben. Sie können diese Cluster anhand des neuen Endpunkt-Domain-Namens `api.aws` identifizieren.
**CIDR-Blöcke im öffentlichen Endpunkt (`IPv4`-Cluster)**
Sie können dem öffentlichen Endpunkt eines `IPv4`-Clusters `IPv4`-CIDR-Blöcke hinzufügen. Sie können keine `IPv6`-CIDR-Blöcke zum öffentlichen Endpunkt eines `IPv4`-Clusters hinzufügen. Wenn Sie dies versuchen, gibt EKS die folgende Fehlermeldung zurück: `The following CIDRs are invalid in publicAccessCidrs`
**CIDR-Blöcke im öffentlichen Endpunkt (`IPv6`-Cluster vor Oktober 2024 erstellt)**
Sie können `IPv4`-CIDR-Blöcke zum öffentlichen Endpunkt der alten `IPv6`-Cluster hinzufügen, die Sie vor Oktober 2024 erstellt haben. Sie können diese Cluster anhand des `eks.amazonaws.com`-Endpunkts identifizieren. Sie können dem öffentlichen Endpunkt dieser alten `IPv6`-Cluster, die Sie vor Oktober 2024 erstellt haben, keine `IPv6`-CIDR-Blöcke hinzufügen. Wenn Sie dies versuchen, gibt EKS die folgende Fehlermeldung zurück: `The following CIDRs are invalid in publicAccessCidrs`
## Zugriff auf einen privaten API-Server
Wenn Sie den öffentlichen Zugriff für den Kubernetes-API-Server-Endpunkt Ihres Clusters deaktiviert haben, können Sie nur über Ihre VPC oder ein [verbundenes Netzwerk](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) auf den API-Server zugreifen. Hier sind einige Möglichkeiten, um auf den Kubernetes-API-Server-Endpunkt zuzugreifen:
**Verbundenes Netzwerk**
Verbinden Sie Ihr Netzwerk über ein [AWS -Transit-Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) oder eine andere [Konnektivitätsoption](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) mit der VPC und verwenden Sie dann einen Computer im verbundenen Netzwerk. Sie müssen sicherstellen, dass Ihre Amazon-EKS-Steuerebenen-Sicherheitsgruppe Regeln enthält, die den eingehenden Datenverkehr auf Port 443 von Ihrem verbundenen Netzwerk zulassen.
**Gastgeber bei Amazon EC2 Bastion**
Sie können eine EC2 Amazon-Instance in einem öffentlichen Subnetz in der VPC Ihres Clusters starten und sich dann über SSH bei dieser Instance anmelden, um Befehle auszuführen. `kubectl` Weitere Informationen finden Sie unter [Linux-Bastion-Hosts in AWS](https://aws.amazon.com/quickstart/architecture/linux-bastion/). Sie müssen sicherstellen, dass Ihre Amazon-EKS-Steuerebenen-Sicherheitsgruppe Regeln enthält, die den eingehenden Datenverkehr auf Port 443 von Ihrem Bastion-Host zulassen. Weitere Informationen finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md).
Achten Sie bei der Konfiguration `kubectl` für Ihren Bastion-Host darauf, AWS Anmeldeinformationen zu verwenden, die bereits der RBAC-Konfiguration Ihres Clusters zugeordnet sind, oder fügen Sie den [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), den Ihre Bastion verwenden wird, zur RBAC-Konfiguration hinzu, bevor Sie den öffentlichen Zugriff auf Endgeräte entfernen. Weitere Informationen erhalten Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md) und [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized).
** AWS -Cloud9-IDE**
AWS Cloud9 ist eine cloudbasierte integrierte Entwicklungsumgebung (IDE), mit der Sie Ihren Code mit nur einem Browser schreiben, ausführen und debuggen können. Sie können eine AWS Cloud9-IDE in der VPC Ihres Clusters erstellen und die IDE für die Kommunikation mit Ihrem Cluster verwenden. Weitere Informationen finden Sie unter [Umgebung in AWS Cloud9 erstellen](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html). Sie müssen sicherstellen, dass Ihre Amazon-EKS-Steuerebenen-Sicherheitsgruppe Regeln enthält, die den eingehenden Datenverkehr auf Port 443 von Ihrer IDE-Sicherheitsgruppe zulassen. Weitere Informationen finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md).
Achten Sie bei der Konfiguration `kubectl` für Ihre AWS Cloud9-IDE darauf, AWS Anmeldeinformationen zu verwenden, die bereits der RBAC-Konfiguration Ihres Clusters zugeordnet sind, oder fügen Sie den IAM-Prinzipal, den Ihre IDE verwenden wird, zur RBAC-Konfiguration hinzu, bevor Sie den öffentlichen Endpunktzugriff entfernen. Weitere Informationen erhalten Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md) und [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized).
[📝 Bearbeiten Sie diese Seite auf GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# Konfiguration des Netzwerkzugriffs auf den Endpunkt des Cluster-API-Servers
Sie können den Endpunktzugriff Ihres Cluster-API-Servers mithilfe der AWS-Managementkonsole oder AWS CLI in den folgenden Abschnitten ändern.
## Konfigurieren Sie den Endpunktzugriff — AWS Konsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, um Ihre Cluster-Informationen anzuzeigen.
1. Wählen Sie die Registerkarte **Netzwerk** und anschließend **Endpunktzugriff verwalten** aus.
1. Wählen Sie für den **privaten Zugriff** aus, ob Sie den privaten Zugriff für den Kubernetes-API-Server-Endpunkt Ihres Clusters aktivieren oder deaktivieren möchten. Wenn Sie den privaten Zugriff aktivieren, verwenden Kubernetes-API-Anfragen aus der VPC Ihres Clusters den privaten VPC-Endpunkt. Sie müssen den privaten Zugriff aktivieren, um den öffentlichen Zugriff zu deaktivieren.
1. Wählen Sie für **Öffentlicher Zugriff** aus, ob der öffentliche Zugriff für den Kubernetes-API-Server-Endpunkt Ihres Clusters aktiviert oder deaktiviert werden soll. Wenn Sie den öffentlichen Zugriff deaktivieren, kann der Kubernetes-API-Server Ihres Clusters nur Anfragen aus der VPC des Clusters empfangen.
1. (Optional) Wenn Sie **Öffentlicher Zugriff** aktiviert haben, können Sie angeben, welche Adressen aus dem Internet mit dem öffentlichen Endpunkt kommunizieren können. Wählen Sie **Erweiterte Einstellungen** aus. Geben Sie einen CIDR-Block ein, z. B. *203.0.113.5/32*. Der Block darf keine [reservierten Adressen](https://en.wikipedia.org/wiki/Reserved_IP_addresses) enthalten. Sie können zusätzliche Blöcke eingeben, indem Sie **Quelle hinzufügen** auswählen. Es gibt eine maximale Anzahl von CIDR-Blöcken, die Sie angeben können. Weitere Informationen finden Sie unter [Service Quotas für Amazon EKS und Fargate anzeigen und verwalten](service-quotas.md). Wenn Sie keine Blöcke angeben, empfängt der öffentliche API-Server-Endpunkt Anfragen von allen IP-Adressen sowohl für `IPv4` (`0.0.0.0/0`) als auch zusätzlich `IPv6` (`::/0`) für Dual-Stack-Cluster `IPv6`. Wenn Sie den Zugriff auf Ihren öffentlichen Endpunkt mithilfe von CIDR-Blöcken einschränken, wird empfohlen, dass Sie auch den privaten Endpunktzugriff aktivieren, damit Knoten und Fargate-Pods (falls Sie diese verwenden) mit dem Cluster kommunizieren können. Wenn der private Endpunkt nicht aktiviert ist, müssen Ihre CIDR-Quellen für den öffentlichen Zugriffsendpunkt die Ausgangsquellen aus Ihrer VPC enthalten. Wenn Sie beispielsweise einen Knoten in einem privaten Subnetz haben, der über ein NAT-Gateway mit dem Internet kommuniziert, müssen Sie die ausgehende IP-Adresse des NAT-Gateways als Teil eines erlaubten CIDR-Blocks auf Ihrem öffentlichen Endpunkt hinzufügen.
1. Wählen Sie zum Abschluss **Update (Aktualisieren)** aus.
## Endpunktzugriff konfigurieren — AWS CLI
Führen Sie die folgenden Schritte mit der AWS CLI-Version `1.27.160` oder höher aus. Sie können Ihre aktuelle Version mit `aws --version` überprüfen. Informationen zur Installation oder zum Upgrade der AWS CLI finden Sie unter [AWS CLI installieren](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Aktualisieren Sie den Endpunktzugriff Ihres Cluster-API-Servers mit dem folgenden AWS CLI-Befehl. Verwenden Ihre eigenen Werte für den Clusternamen und den gewünschten Endpunkt. Wenn Sie `endpointPublicAccess=true` festlegen, können Sie (optional) einen einzelnen CIDR-Block oder eine kommagetrennte Liste von CIDR-Blöcken für `publicAccessCidrs` eingeben. Die Blöcke dürfen keine [reservierten Adressen](https://en.wikipedia.org/wiki/Reserved_IP_addresses) enthalten. Wenn Sie CIDR-Blöcke angeben, empfängt der öffentliche API-Server-Endpunkt nur Anforderungen von den aufgelisteten Blöcken. Es gibt eine maximale Anzahl von CIDR-Blöcken, die Sie angeben können. Weitere Informationen finden Sie unter [Service Quotas für Amazon EKS und Fargate anzeigen und verwalten](service-quotas.md). Wenn Sie den Zugriff auf Ihren öffentlichen Endpunkt mithilfe von CIDR-Blöcken einschränken, wird empfohlen, dass Sie auch den privaten Endpunktzugriff aktivieren, damit Knoten und Fargate-Pods (falls Sie diese verwenden) mit dem Cluster kommunizieren können. Wenn der private Endpunkt nicht aktiviert ist, müssen Ihre CIDR-Quellen für den öffentlichen Zugriffsendpunkt die Ausgangsquellen aus Ihrer VPC enthalten. Wenn Sie beispielsweise einen Knoten in einem privaten Subnetz haben, der über ein NAT-Gateway mit dem Internet kommuniziert, müssen Sie die ausgehende IP-Adresse des NAT-Gateways als Teil eines erlaubten CIDR-Blocks auf Ihrem öffentlichen Endpunkt hinzufügen. Wenn Sie keine CIDR-Blöcke angeben, empfängt der öffentliche API-Server-Endpunkt Anfragen von allen (0.0.0.0/0) IP-Adressen und zusätzlich `IPv6` (`::/0`) für Dual-Stack-`IPv6`-Cluster.
**Anmerkung**
Der folgende Befehl ermöglicht den privaten Zugriff und den öffentlichen Zugriff von einer einzelnen IP-Adresse für den API-Server-Endpunkt. Ersetzen Sie *203.0.113.5/32* durch einen einzelnen CIDR-Block oder eine kommagetrennte Liste von CIDR-Blöcken, auf die Sie den Netzwerkzugriff beschränken möchten.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. Überwachen Sie den Status des aktualisierten Endpunktzugriffs mit dem folgenden Befehl unter Verwendung des Cluster-Namens und der Update-ID, die vom vorherigen Befehl zurückgegeben wurden. Ihre Aktualisierung ist abgeschlossen, wenn als Status `Successful` angezeigt wird.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [Bearbeiten Sie diese Seite auf GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# Bereitstellung von Windows-Knoten in EKS-Clustern
Erfahren Sie, wie Sie den Windows-Support für Ihren Amazon-EKS-Cluster aktivieren und verwalten, um Windows-Container neben Linux-Containern auszuführen.
## Überlegungen
Beachten Sie vor der Bereitstellung von Windows-Knoten die folgenden Überlegungen.
+ EKS Auto Mode unterstützt keine Windows-Knoten
+ Sie können Host-Netzwerke auf Windows-Knoten mithilfe von `HostProcess`-Pods verwenden. Weitere Informationen finden Sie HostProcessPod in der Kubernetes-Dokumentation unter [Create a Windows](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/).
+ Amazon-EKS-Cluster müssen einen oder mehrere Linux- oder Fargate-Knoten enthalten, um Kernsystem-Pods auszuführen, die nur unter Linux, z. B. CoreDNS, ausgeführt werden.
+ Die Ereignisprotokolle `kubelet` und `kube-proxy` werden in das `EKS Windows`-Ereignisprotokoll umgeleitet und auf 200 MB begrenzt.
+ Sie können [Sicherheitsgruppen nicht einzelnen Pods zuweisen](security-groups-for-pods.md), wenn Pods in Windows-Knoten ausgeführt werden.
+ Sie können [benutzerdefinierte Netzwerke](cni-custom-network.md) nicht mit Windows-Knoten benutzen.
+ Sie können `IPv6` nicht mit Windows-Knoten verwenden.
+ Windows-Knoten unterstützen eine Elastic-Network-Schnittstelle pro Knoten. Die Anzahl der Pods, die Sie pro Windows-Knoten ausführen können, entspricht standardmäßig der Anzahl der IP-Adressen, die pro Elastic-Network-Schnittstelle für den Instance-Typ des Knotens verfügbar sind, minus eins. Weitere Informationen finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) im * EC2 Amazon-Benutzerhandbuch*.
+ In einem Amazon-EKS-Cluster kann ein einzelner Service mit einem Load Balancer bis zu 1 024 Backend-Pods unterstützen. Jeder Pod hat seine eigene eindeutige IP-Adresse. Das bisherige Limit von 64 Pods trifft nicht mehr zu, nachdem ein [Windows-Server-Update](https://github.com/microsoft/Windows-Containers/issues/93) beginnend mit [Betriebssystem-Build 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4) durchgeführt wurde.
+ Windows-Container werden in Fargate für Amazon-EKS-Pods nicht unterstützt.
+ Es ist nicht möglich, Amazon EKS Hybrid Nodes mit Windows als Betriebssystem für den Host zu verwenden.
+ Sie können keine Protokolle aus dem `vpc-resource-controller`-Pod abrufen. Dies war zuvor möglich, als Sie den Controller auf der Datenebene bereitgestellt haben.
+ Es gibt eine Abkühlungsphase, bevor einem neuen Pod eine `IPv4`-Adresse zugewiesen wird. Dadurch wird verhindert, dass Datenverkehr aufgrund veralteter `IPv4`-Regeln an einen älteren Pod mit derselben `kube-proxy`-Adresse fließt.
+ Die Quelle für den Controller wird auf verwaltet GitHub. Wenn Sie zum Controller beitragen oder Probleme gegen den Controller einreichen möchten, besuchen Sie das [Projekt](https://github.com/aws/amazon-vpc-resource-controller-k8s) unter GitHub.
+ Wenn Sie eine benutzerdefinierte AMI-ID für von Windows verwaltete Knotengruppen angeben, fügen Sie `eks:kube-proxy-windows` diese Ihrer AWS IAM Authenticator-Konfigurationsübersicht hinzu. Weitere Informationen finden Sie unter [Grenzen und Bedingungen bei der Angabe einer AMI-ID](launch-templates.md#mng-ami-id-conditions).
+ Wenn die Beibehaltung Ihrer verfügbaren IPv4 Adressen für Ihr Subnetz von entscheidender Bedeutung ist, finden Sie weitere Informationen im [EKS Best Practices Guide — Windows Networking IP Address Management](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management).
+ Überlegungen zu EKS-Zugriffseinträgen
+ Zugriffseinträge zur Verwendung mit Windows-Knoten erfordern den Typ `EC2_WINDOWS`. Weitere Informationen finden Sie unter [Zugriffseinträge erstellen](creating-access-entries.md).
So erstellen Sie einen Zugriffseintrag für einen Windows-Knoten:
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/ --type EC2_Windows
```
## Voraussetzungen
+ Einen vorhandenen -Cluster.
+ Ihr Cluster muss mindestens einen (wir empfehlen mindestens zwei) Linux-Knoten oder Fargate-Pod haben, um CoreDNS auszuführen. Wenn Sie den veralteten System-Windows-Support aktivieren, müssen Sie einen Linux-Knoten verwenden (Sie können keinen Fargate-Pod verwenden), um CoreDNS auszuführen.
+ Ein vorhandener [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
## Windows-Support aktivieren
1. Wenn Sie keine Amazon-Linux-Knoten in Ihrem Cluster haben und Sicherheitsgruppen für Pods verwenden, fahren Sie mit dem nächsten Schritt fort. Ansonsten bestätigen Sie, dass die verwaltete Richtlinie `AmazonEKSVPCResourceController` Ihrer [Cluster-Rolle](cluster-iam-role.md) angefügt ist. Ersetzen Sie den *eksClusterRole* durch Ihren Clusterrollennamen.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
Wenn die Richtlinie wie in der vorherigen Ausgabe angehängt ist, überspringen Sie den nächsten Schritt.
1. Fügen Sie die von **[Amazon EKSVPCResource Controller](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** verwaltete Richtlinie Ihrer [Amazon EKS-Cluster-IAM-Rolle](cluster-iam-role.md) hinzu. Ersetzen Sie den *eksClusterRole* durch Ihren Clusterrollennamen.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
```
1. Aktualisieren Sie das VPC-CNI, um Windows ConfigMap IPAM zu aktivieren. Hinweis: Wenn das VPC-CNI mithilfe eines Helm-Charts oder als Amazon EKS-Add-on auf Ihrem Cluster installiert ist, können Sie das möglicherweise nicht direkt ändern. ConfigMap Informationen zur Konfiguration von Amazon-EKS-Add-Ons finden Sie unter [Felder für die Anpassung von Amazon-EKS-Add-Ons festlegen](kubernetes-field-management.md).
1. Erstellen Sie eine Datei mit dem Namen *vpc-resource-controller-configmap.yaml* und dem folgenden Inhalt.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. Anwendung der `ConfigMap` auf Ihren Cluster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. Wenn in Ihrem Cluster der Authentifizierungsmodus so eingestellt ist, dass die `aws-auth`-Konfigurationszuordnung aktiviert wird:
+ Stellen Sie sicher, dass Ihre `aws-auth` `ConfigMap` eine Zuordnung für die Instance-Rolle des Windows-Knotens enthält, sodass sie die `eks:kube-proxy-windows`-RBAC-Berechtigungsgruppe einschließt. Prüfen Sie dies durch Ausführung des folgenden Befehls.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
Eine Beispielausgabe sieht wie folgt aus.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws: iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
`eks:kube-proxy-windows` sollte unter „Gruppen“ aufgelistet sein. Wenn die Gruppe nicht angegeben ist, müssen Sie Ihre `ConfigMap` aktualisieren oder sie so erstellen, dass sie die erforderliche Gruppe enthält. Weitere Informationen zur `aws-auth` `ConfigMap` finden Sie unter [Anwenden von `aws-auth` `ConfigMap` auf Ihren Cluster](auth-configmap.md#aws-auth-configmap).
1. Wenn in Ihrem Cluster der Authentifizierungsmodus so eingestellt ist, dass die `aws-auth`-Konfigurationszuordnung deaktiviert wird, können Sie EKS-Zugriffseinträge verwenden. Erstellen Sie eine neue Knoten-Rolle für die Verwendung mit Windows-Instances, und EKS erstellt automatisch einen Zugriffseintrag vom Typ `EC2_WINDOWS`.
## Windows-Pods bereitstellen
Wenn Sie Pods in Ihrem Cluster bereitstellen, müssen Sie das Betriebssystem angeben, das sie verwenden, wenn Sie eine Kombination aus Knotentypen ausführen.
Verwenden Sie für Linux-Pods den folgenden Knotenauswahltext in Ihren Manifesten.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Verwenden Sie für Windows-Pods den folgenden Knoten-Auswahltext in Ihren Manifesten.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
Sie können eine [Beispielanwendung](sample-deployment.md) bereitstellen, um die verwendeten Knotenselektoren zu sehen.
## Unterstützung einer höheren Pod-Dichte in Windows-Knoten
In Amazon EKS wird jedem Pod eine `IPv4`-Adresse aus Ihrer VPC zugewiesen. Aus diesem Grund ist die Anzahl der Pods, die Sie in einem Knoten bereitstellen können, durch die verfügbaren IP-Adressen begrenzt, selbst wenn genügend Ressourcen vorhanden sind, um mehr Pods auf dem Knoten auszuführen. Da von einem Windows-Knoten nur eine elastische Netzwerkschnittstelle unterstützt wird, entspricht die maximale Anzahl verfügbarer IP-Adressen auf einem Windows-Knoten standardmäßig:
```
Number of private IPv4 addresses for each interface on the node - 1
```
Eine IP-Adresse wird als primäre IP-Adresse der Netzwerkschnittstelle verwendet und kann daher Pods nicht zugewiesen werden.
Sie können eine höhere Pod-Dichte in Windows-Knoten aktivieren, indem Sie die IP-Präfix-Delegierung aktivieren. Mit diesem Feature können Sie der primären Netzwerkschnittstelle ein `/28`-`IPv4`-Präfix zuweisen, anstatt sekundäre `IPv4`-Adressen zuzuweisen. Durch die Zuweisung eines IP-Präfixes wird die maximale Anzahl verfügbarer `IPv4`-Adressen auf dem Knoten auf Folgendes erhöht:
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
Angesichts dieser deutlich größeren Anzahl verfügbarer IP-Adressen sollten verfügbare IP-Adressen Ihre Fähigkeit, die Anzahl der Pods auf Ihren Knoten zu skalieren, nicht einschränken. Weitere Informationen finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md).
# Windows-Support deaktivieren
1. Wenn Ihr Cluster Amazon-Linux-Knoten enthält und Sie [Sicherheitsgruppen für Pods](security-groups-for-pods.md) mit ihnen verwenden, überspringen Sie dann diesen Schritt.
Entfernen Sie die `AmazonVPCResourceController`-verwaltete IAM-Richtlinie von Ihrer [Cluster-Rolle](cluster-iam-role.md). Ersetzen Sie *eksClusterRole* durch den Namen Ihrer Cluster-Rolle.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Deaktivieren Sie Windows IPAM im `amazon-vpc-cni`-ConfigMap.
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# Bereitstellung privater Cluster mit eingeschränktem Internetzugang
In diesem Thema wird beschrieben, wie Sie einen Amazon EKS-Cluster bereitstellen, der in der AWS Cloud bereitgestellt wird, aber keinen ausgehenden Internetzugang hat. Wenn Sie einen lokalen Cluster auf AWS Outposts haben[Amazon Linux-Knoten auf AWS Outposts erstellen](eks-outposts-self-managed-nodes.md), finden Sie statt dieses Themas weitere Informationen unter.
Wenn Sie mit dem Amazon-EKS-Netzwerk nicht vertraut sind, finden Sie unter [Entmystifizierung von Cluster-Netzwerken für Amazon-EKS-Worker-Knoten](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Wenn Ihr Cluster nicht über einen ausgehenden Internetzugriff verfügt, muss es die folgenden Anforderungen erfüllen:
## Anforderungen an die Cluster-Architektur
+ Ihr Cluster muss Images von einer Container-Registry in Ihrer VPC abrufen. Sie können eine Amazon Elastic Container Registry in Ihrer VPC erstellen und Container-Images dorthin kopieren, damit Ihre Knoten daraus abrufen können. Weitere Informationen finden Sie unter [Kopieren eines Container-Images von einem Repository in ein anderes](copy-image-to-repository.md).
+ In Ihrem Cluster muss der private Endpunkt-Zugriff aktiviert sein. Dies ist erforderlich, damit sich Knoten beim Cluster-Endpunkt registrieren können. Der Endpunkt für öffentlichen Zugriff ist optional. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md).
## Knoten-Anforderungen
+ Selbstverwaltete Linux- und Windows-Knoten müssen die folgenden Bootstrap-Argumente enthalten, bevor sie gestartet werden. Diese Argumente umgehen die Amazon-EKS-Introspektion und erfordern keinen Zugriff auf die Amazon-EKS-API innerhalb der VPC.
1. Bestimmen Sie den Wert des Endpunkts Ihres Clusters mit dem folgenden Befehl. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
Eine Beispielausgabe sieht wie folgt aus.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Bestimmen Sie den Wert der Zertifizierungsstelle Ihres Clusters mit dem folgenden Befehl. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
Die zurückgegebene Ausgabe ist eine lange Zeichenfolge.
1. Ersetzen Sie die Werte von `apiServerEndpoint` und `certificateAuthority` im NodeConfig Objekt durch die Werte, die in der Ausgabe der vorherigen Befehle zurückgegeben wurden. Weitere Informationen zur Angabe von Bootstrap-Argumenten beim Starten von selbstverwalteten Amazon Linux 2023-Knoten finden Sie unter [Selbstverwaltete Amazon-Linux-Knoten erstellen](launch-workers.md) und. [Selbstverwaltete Microsoft-Windows-Knoten erstellen](launch-windows-workers.md)
+ Für Linux-Knoten:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Weitere Argumente finden Sie im [Bootstrap-Skript](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) unter. GitHub
+ Für Windows-Knoten:
**Anmerkung**
Wenn Sie CIDR für den benutzerdefinierten Service verwenden, müssen Sie diesen mithilfe des `-ServiceCIDR`-Parameters angeben. Andernfalls schlägt die DNS-Auflösung für Pods im Cluster fehl.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Weitere Argumente finden Sie unter [Bootstrap-Skript-Konfigurationsparameter](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ Das `aws-auth` `ConfigMap` Ihres Clusters muss innerhalb Ihrer VPC erstellt werden. Weitere Informationen zum Erstellen und Hinzufügen von Einträgen zu `aws-auth` `ConfigMap` erhalten Sie durch Eingabe von `eksctl create iamidentitymapping --help` in Ihrem Terminal. Falls `ConfigMap` auf Ihrem Server nicht vorhanden ist, wird es von `eksctl` erstellt, wenn Sie den Befehl zum Hinzufügen einer Identitätszuordnung verwenden.
## Pod-Anforderungen
+ **Pod Identity** – Mit EKS Pod Identity konfigurierte Pods erhalten Anmeldeinformationen von der EKS-Auth-API. Wenn kein ausgehender Internetzugang vorhanden ist, müssen Sie einen VPC-Endpunkt für die EKS-Auth-API erstellen und verwenden: `com.amazonaws.region-code.eks-auth`. Weitere Informationen zu den EKS- und EKS-Auth-VPC-Endpunkten finden Sie unter [Zugriff auf Amazon EKS über AWS PrivateLink](vpc-interface-endpoints.md)
+ **IRSA** — Pods, die mit [IAM-Rollen für Dienstkonten](iam-roles-for-service-accounts.md) konfiguriert sind, beziehen Anmeldeinformationen aus einem API-Aufruf des AWS Security Token Service (AWS STS). Wenn es keinen ausgehenden Internetzugang gibt, müssen Sie einen AWS STS-VPC-Endpunkt in Ihrer VPC erstellen und verwenden. Die meisten AWS `v1` SDKs verwenden standardmäßig den globalen AWS STS-Endpunkt (`sts.amazonaws.com`), der den AWS STS-VPC-Endpunkt nicht verwendet. Um den AWS STS-VPC-Endpunkt zu verwenden, müssen Sie Ihr SDK möglicherweise so konfigurieren, dass es den regionalen AWS STS-Endpunkt (`sts.region-code.amazonaws.com`) verwendet. Weitere Informationen finden Sie unter [Konfiguration des Endpunkts des AWS-Sicherheitstoken-Service für ein Servicekonto](configure-sts-endpoint.md).
+ Die VPC-Subnetze Ihres Clusters müssen über einen VPC-Schnittstellenendpunkt für alle AWS Dienste verfügen, auf die Ihre Pods Zugriff benötigen. Weitere Informationen finden Sie unter [Zugreifen auf einen AWS Dienst über einen Schnittstellen-VPC-Endpunkt](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Einige häufig verwendete Services und Endpunkte sind in der folgenden Tabelle aufgeführt. eine vollständige Liste der Endpunkte finden Sie unter [AWS -Services, die mit AWS integriert sindPrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) im [AWS PrivateLink -Handbuch](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Wir empfehlen Ihnen, [private DNS-Namen für Ihre VPC-Endpunkte zu aktivieren](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names), damit Workloads weiterhin ohne Probleme öffentliche AWS Dienstendpunkte verwenden können.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/private-clusters.html)
+ Alle selbstverwalteten Knoten müssen in Subnetzen bereitgestellt werden, die über die von Ihnen benötigten VPC-Schnittstellenendpunkte verfügen. Wenn Sie eine verwaltete Knotengruppe erstellen, muss die Endpunktsicherheitsgruppe der VPC-Schnittstelle das CIDR für die Subnetze zulassen, oder Sie müssen die erstellte Knotensicherheitsgruppe zur Endpunktsicherheitsgruppe der VPC-Schnittstelle hinzufügen.
+ **EFS-Speicher** — Wenn Ihre Pods Amazon EFS-Volumes verwenden, muss vor der Bereitstellung von [Store an elastic file system with Amazon EFS](efs-csi.md) die Datei [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) des Treibers so geändert werden, dass die Container-Images dieselbe AWS Region wie der Amazon EKS-Cluster verwenden.
+ Route53 unterstützt nicht. AWS PrivateLink Es ist nicht möglich, Route53-DNS-Einträge von einem privaten Amazon-EKS-Cluster aus zu verwalten. Dies hat Auswirkungen auf Kubernetes [external-dns](https://github.com/kubernetes-sigs/external-dns).
+ Bei Verwendung der EKS-optimierten AMI sollten Sie den `ec2`-Endpunkt in der obigen Tabelle aktivieren. Alternativ können Sie den Knoten-DNS-Namen manuell festlegen. Das optimierte AMI verwendet EC2 APIs , um den DNS-Namen des Knotens automatisch festzulegen.
+ Sie können den [Load AWS Balancer Controller](aws-load-balancer-controller.md) verwenden, um AWS Application Load Balancers (ALB) und Network Load Balancers in Ihrem privaten Cluster bereitzustellen. Beim Bereitstellen sollten Sie [Befehlszeilen-Flags](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) verwenden, um `enable-shield`, `enable-waf` und `enable-wafv2` auf falsch zu setzen. Die [Zertifikatserkennung](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) mit Hostnamen aus Eingangsobjekten wird nicht unterstützt. Dies liegt daran, dass der Controller AWS Certificate Manager erreichen muss, der keinen VPC-Schnittstellenendpunkt hat.
Der Controller unterstützt Network Load Balancer mit IP-Zielen, die für die Verwendung mit Fargate erforderlich sind. Weitere Informationen erhalten Sie unter [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md) und [Erstellen eines Network Load Balancers](network-load-balancing.md#network-load-balancer).
+ [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) wird unterstützt. Stellen Sie beim Bereitstellen von Cluster-Autoscaler-Pods sicher, dass die Befehlszeile `--aws-use-static-instance-list=true` enthält. Weitere Informationen finden Sie unter [Statische Instanzliste verwenden](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) auf GitHub. Die Worker-Node-VPC muss auch den AWS STS-VPC-Endpunkt und den VPC-Endpunkt für Autoscaling enthalten.
+ Einige Container-Softwareprodukte verwenden API-Aufrufe, die auf den AWS Marketplace Metering Service zugreifen, um die Nutzung zu überwachen. Private Cluster lassen diese Aufrufe nicht zu, daher können Sie diese Containertypen nicht in privaten Clustern verwenden.
# Skalierung von Cluster-Computing mit Karpenter und Cluster Autoscaler
Auto Scaling ist eine Funktion, die Ihre Ressourcen automatisch nach oben oder unten skaliert, um wechselnden Anforderungen gerecht zu werden. Dies ist eine wichtige Kubernetes-Funktion, die ansonsten umfangreiche Personalressourcen erfordern würde, um manuell zu arbeiten.
## EKS Auto Mode
Amazon EKS Auto Mode skaliert die Rechenressourcen des Clusters automatisch. Wenn ein Pod nicht auf die vorhandenen Knoten passt, erstellt EKS Auto Mode einen neuen. EKS Auto Mode konsolidiert außerdem Workloads und löscht Knoten. EKS Auto Mode baut auf Karpenter auf.
Weitere Informationen finden Sie unter:
+ [Automatisieren der Cluster-Infrastruktur mit dem EKS-Automatikmodus](automode.md)
+ [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md)
+ [Bereitstellung einer erhöhten Beispiel-Workload in einem Cluster in Amazon EKS Auto Mode](automode-workload.md)
## Weitere Lösungen
Amazon EKS unterstützt zwei zusätzliche Auto-Scaling-Produkte:
**Karpenter**
Karpenter ist ein flexibler, leistungsstarker Kubernetes-Cluster-Autoscaler, der zur Verbesserung der Anwendungsverfügbarkeit und Cluster-Effizienz beiträgt. Karpenter startet Rechenressourcen in der richtigen Größe (z. B. Amazon-EC2-Instances) als Reaktion auf sich ändernde Anwendungslasten in weniger als einer Minute. Durch die Integration von Kubernetes mit AWS kann Karpenter Just-in-Time-Rechenressourcen bereitstellen, die genau den Anforderungen Ihres Workloads entsprechen. Karpenter stellt automatisch neue Rechenressourcen basierend auf den spezifischen Anforderungen von Cluster-Workloads bereit. Dazu gehören Rechen-, Speicher-, Beschleunigungs- und Planungsanforderungen. Amazon EKS unterstützt Cluster, die Karpenter verwenden, obwohl Karpenter mit jedem konformierten Kubernetes-Cluster zusammenarbeitet. Weitere Informationen finden Sie in der [Karpenter](https://karpenter.sh/docs/)-Dokumentation.
Karpenter ist eine Open-Source-Software, für deren Installation, Konfiguration und Verwaltung in ihren Kubernetes-Clustern die AWS-Kunden verantwortlich sind. AWS bietet technischen Support, wenn Karpenter unverändert mit einer kompatiblen Version in Amazon-EKS-Clustern ausgeführt wird. Es ist wichtig, dass Kunden die Verfügbarkeit und Sicherheit des Karpenter-Controllers sowie entsprechende Testverfahren aufrechterhalten, wenn sie ihn oder den Kubernetes-Cluster, in dem er ausgeführt wird, aktualisieren, genau wie bei jeder anderen vom Kunden verwalteten Software. Für Karpenter besteht kein AWS Service Level Agreement (SLA). Die Kunden sind dafür verantwortlich, sicherzustellen, dass die von Karpenter gestarteten EC2-Instances ihren geschäftlichen Anforderungen entsprechen.
**Cluster Autoscaler**
Der Kubernetes Cluster Autoscaler passt die Anzahl der Knoten in Ihrem Cluster automatisch an, wenn Pods ausfallen oder auf andere Knoten umgeplant werden. Der Cluster Autoscaler verwendet Auto-Scaling-Gruppen. Weitere Informationen finden Sie unter [Cluster Autoscaler on AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
# Weitere Informationen zur Zonenverschiebung von Amazon Application Recovery Controller (ARC) in Amazon EKS
Kubernetes verfügt über native Features, mit denen Sie Ihre Anwendungen stabiler gegenüber Ereignissen wie einer verschlechterten Verfügbarkeit oder Beeinträchtigung einer Availability Zone (AZ) machen können. Wenn Sie Ihre Workloads in einem Amazon-EKS-Cluster ausführen, können Sie die Fehlertoleranz und Anwendungswiederherstellung Ihrer Anwendungsumgebung weiter verbessern, indem Sie [Amazon Application Recovery Controller (ARC)-Zonenverschiebung](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) oder [automatische Zonenverschiebung](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html) einsetzen. ARC-Zonenverschiebung ist als vorübergehende Maßnahme konzipiert, mit der Sie den Datenverkehr für eine Ressource aus einer beeinträchtigten AZ verlagern können, bis die Zonenverschiebung abläuft oder Sie sie abbrechen. Bei Bedarf können Sie die Zonenverschiebung verlängern.
Sie können eine Zonenverschiebung für einen EKS-Cluster starten oder Sie können zulassen AWS , dass der Datenverkehr für Sie verschoben wird, indem Sie Zonal Autoshift aktivieren. Durch diese Verschiebung wird der east-to-west Netzwerkdatenverkehr in Ihrem Cluster so aktualisiert, dass nur Netzwerkendpunkte für Pods berücksichtigt werden, die auf Worker-Knoten ausgeführt werden, die fehlerfrei sind. AZs Darüber hinaus leitet jeder ALB oder NLB, der den eingehenden Datenverkehr für Anwendungen in Ihrem EKS-Cluster verarbeitet, den Datenverkehr automatisch an fehlerfreie Ziele weiter. AZs Für Kunden, die höchste Verfügbarkeit anstreben, kann es im Falle einer Beeinträchtigung einer AZ wichtig sein, den gesamten Datenverkehr von der beeinträchtigten AZ wegleiten zu können, bis diese wiederhergestellt ist. Hierzu können Sie auch [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html).
## Verständnis des Ost-West-Netzwerkdatenverkehrs zwischen Pods
Das folgende Diagramm veranschaulicht zwei Beispiel-Workloads: Bestellungen und Produkte. Der Zweck dieses Beispiels besteht darin, zu zeigen, wie Workloads und Pods in verschiedenen Umgebungen miteinander kommunizieren. AZs
![\[Darstellung des Netzwerk-Datenverkehrs\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[Darstellung des Netzwerk-Datenverkehrs\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Damit Aufträge mit Produkten kommunizieren können, müssen sie zunächst den DNS-Namen des Ziel-Services auflösen. Aufträge kommunizieren mit CoreDNS, um die virtuelle IP-Adresse (Cluster-IP) für diesen Service abzurufen. Nachdem Aufträge den Produktnamen aufgelöst hat, sendet es Datenverkehr an diese Ziel-IP-Adresse.
1. Der Kube-Proxy läuft auf jedem Knoten im Cluster und sucht kontinuierlich nach Diensten. [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) Wenn ein Dienst erstellt wird, EndpointSlice wird ein Dienst im Hintergrund vom Controller erstellt und verwaltet. EndpointSlice Jeder EndpointSlice hat eine Liste oder Tabelle mit Endpunkten, die eine Teilmenge von Pod-Adressen sowie die Knoten enthält, auf denen sie ausgeführt werden. Der Kube-Proxy richtet mithilfe von `iptables` auf den Knoten Routing-Regeln für jeden dieser Pod-Endpunkte ein. Der Kube-Proxy ist auch für eine grundlegende Form des Lastausgleichs zuständig, indem er den für die Cluster-IP-Adresse eines Services bestimmten Datenverkehr umleitet, sodass dieser stattdessen direkt an die IP-Adresse eines Pods gesendet wird. Der kube-proxy erreicht dies, indem er die Ziel-IP-Adresse der ausgehenden Verbindung umschreibt.
1. Die Netzwerkpakete werden dann unter Verwendung von ENIs auf den jeweiligen Knoten an den Produkt-Pod in AZ 2 gesendet, wie im vorherigen Diagramm dargestellt.
### Verständnis der ARC-Zonenverschiebung in Amazon EKS
Sollte in Ihrer Umgebung eine AZ-Beeinträchtigung vorliegen, können Sie eine Zonenverschiebung für Ihre EKS-Cluster-Umgebung initiieren. Alternativ können AWS Sie den wechselnden Verkehr mit zonaler Autoshift für Sie verwalten lassen. Mit Zonal Autoshift wird der gesamte Zustand der AZ AWS überwacht und auf eine mögliche Beeinträchtigung der AZ reagiert, indem der Verkehr in Ihrer Cluster-Umgebung automatisch von der beeinträchtigten AZ weggeleitet wird.
Nachdem Ihr Amazon EKS-Cluster Zonal Shift mit ARC aktiviert hat, können Sie eine Zonal Shift starten oder Zonal Autoshift aktivieren, indem Sie die ARC-Konsole, die AWS CLI oder Zonal Shift und Zonal Autoshift verwenden. APIs Während einer EKS-Zonenverschiebung wird Folgendes automatisch durchgeführt:
+ Alle Knoten in der betroffenen AZ werden gesperrt. Dadurch wird verhindert, dass der Kubernetes-Scheduler neue Pods auf Knoten in der fehlerhaften AZ plant.
+ Wenn Sie [Managed Node Groups](managed-node-groups.md) verwenden, wird das [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) ausgesetzt und Ihre Auto Scaling Scaling-Gruppe wird aktualisiert, um sicherzustellen, dass neue EKS-Datenebenenknoten nur im AZs fehlerfreien Zustand gestartet werden.
+ Die Knoten in der fehlerhaften AZ werden nicht beendet und Pods werden nicht aus den Knoten entfernt. Dadurch wird sichergestellt, dass Ihr Datenverkehr nach Ablauf oder Aufhebung einer Zonenverschiebung sicher in die AZ zurückgeführt werden kann, um die volle Kapazität wiederherzustellen.
+ Der EndpointSlice Controller findet alle Pod-Endpunkte in der beeinträchtigten AZ und entfernt sie aus den entsprechenden. EndpointSlices Dadurch wird sichergestellt, dass nur Pod-Endpunkte, die sich in einem AZs fehlerfreien Zustand befinden, gezielt Netzwerkverkehr empfangen. Wenn eine Zonenverschiebung storniert wird oder abläuft, aktualisiert der EndpointSlice Controller sie so, EndpointSlices dass die Endpunkte in die wiederhergestellte AZ aufgenommen werden.
Die folgenden Diagramme bieten einen allgemeinen Überblick darüber, wie die EKS-Zonenverschiebung sicherstellt, dass nur fehlerfreie Pod-Endpunkte in Ihrer Cluster-Umgebung angesteuert werden.
![\[Darstellung des Netzwerk-Datenverkehrs\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[Darstellung des Netzwerk-Datenverkehrs\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## Anforderungen der EKS-Zonenverschiebung
Damit die Zonenverschiebung mit EKS erfolgreich funktioniert, müssen Sie Ihre Cluster-Umgebung im Voraus so einrichten, dass sie gegenüber einer AZ-Beeinträchtigung widerstandsfähig ist. Nachfolgend finden Sie eine Liste mit Konfigurationsoptionen, die zur Gewährleistung der Ausfallsicherheit beitragen.
+ Stellen Sie die Worker-Knoten Ihres Clusters auf mehrere AZs
+ Bereitstellung von ausreichend Rechenkapazität, um den Ausfall einer einzelnen AZ zu kompensieren
+ Vorskalierung Ihrer Pods, einschließlich CoreDNS, in jeder AZ
+ Verteilen Sie mehrere Pod-Repliken auf alle AZs, um sicherzustellen, dass Sie auch bei einem Wechsel von einer einzigen AZ immer noch über ausreichend Kapazität verfügen
+ Co-Location von voneinander abhängigen oder verwandten Pods in derselben AZ
+ Testen Sie, ob Ihre Cluster-Umgebung ohne eine AZ wie erwartet funktioniert, indem Sie manuell eine Zonenverschiebung weg von einer AZ starten. Alternativ können Sie die automatische Zonenverschiebung aktivieren und sich auf Testläufe der automatischen Verschiebung verlassen. Tests mit manuellen oder praktischen Zonenverschiebungen sind für die Funktion der Zonenverschiebung in EKS nicht erforderlich, werden aber dringend empfohlen.
### Bereitstellung Ihrer EKS-Worker-Knoten über mehrere Availability Zones hinweg
AWS Regionen haben mehrere, separate Standorte mit physischen Rechenzentren, die als Availability Zones (AZs) bezeichnet werden. AZs sind so konzipiert, dass sie physisch voneinander isoliert sind, um gleichzeitige Auswirkungen zu vermeiden, die sich auf eine gesamte Region auswirken könnten. Wenn Sie einen EKS-Cluster bereitstellen, empfehlen wir, dass Sie Ihre Worker-Knoten auf mehreren Knoten AZs in einer Region bereitstellen. Dies trägt dazu bei, dass Ihre Clusterumgebung widerstandsfähiger gegenüber Beeinträchtigungen durch eine einzelne AZ ist, und ermöglicht es Ihnen, die Hochverfügbarkeit Ihrer Anwendungen aufrechtzuerhalten, die in der anderen ausgeführt AZs werden. Wenn Sie mit einer Zonenverlagerung weg von der betroffenen AZ beginnen, wird das Cluster-interne Netzwerk Ihrer EKS-Umgebung automatisch aktualisiert, sodass es nur noch fehlerfrei verwendet wird AZs, um die Hochverfügbarkeit Ihres Clusters aufrechtzuerhalten.
Die Sicherstellung einer Multi-AZ-Konfiguration für Ihre EKS-Umgebung erhöht die allgemeine Zuverlässigkeit Ihres Systems. Multi-AZ-Umgebungen beeinflussen jedoch die Art und Weise, wie Anwendungsdaten übertragen und verarbeitet werden, was sich wiederum auf die Netzwerkgebühren Ihrer Umgebung auswirkt. Insbesondere häufiger ausgehender zonenübergreifender Verkehr (zwischen den einzelnen Zonen verteilter Verkehr AZs) kann erhebliche Auswirkungen auf Ihre Netzwerkkosten haben. Sie können verschiedene Strategien anwenden, um die Menge des zonenübergreifenden Datenverkehrs zwischen Pods in Ihrem EKS-Cluster zu steuern und die damit verbundenen Kosten zu senken. Weitere Informationen zur Optimierung der Netzwerkkosten beim Betrieb hochverfügbarer EKS-Umgebungen finden Sie in diesen [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/).
Das folgende Diagramm zeigt eine hochverfügbare EKS-Umgebung mit drei fehlerfreien Komponenten. AZs
![\[Darstellung des Netzwerks\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-ha-before-failure.png)
Das folgende Diagramm zeigt, wie eine EKS-Umgebung mit drei AZs EKS-Umgebungen eine Beeinträchtigung der AZ aushält und hochverfügbar bleibt, da zwei davon noch intakt sind. AZs
![\[Darstellung des Netzwerks\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-ha-after-failure.png)
### Stellen Sie ausreichend Rechenkapazität bereit, um den Ausfall einer einzelnen Availability Zone zu kompensieren.
Um die Ressourcennutzung und die Kosten für Ihre Recheninfrastruktur in der EKS-Datenebene zu optimieren, empfiehlt es sich, die Rechenkapazität an Ihren Workload-Anforderungen auszurichten. Wenn jedoch **alle Ihre Worker-Knoten voll ausgelastet sind**, sind Sie darauf angewiesen, dass neue Worker-Knoten zur EKS-Datenebene hinzugefügt werden, bevor neue Pods geplant werden können. Wenn Sie wichtige Workloads ausführen, empfiehlt es sich im Allgemeinen, redundante Kapazitäten online zu betreiben, um Szenarien wie plötzliche Lastanstiege und Probleme mit der Knotenintegrität zu bewältigen. Wenn Sie eine Zonenverschiebung planen, beabsichtigen Sie, bei einer Wertminderung die gesamte Kapazität einer AZ zu entfernen. Das bedeutet, dass Sie Ihre redundante Rechenkapazität so anpassen müssen, dass sie ausreicht, um die Last auch dann zu bewältigen, wenn eine der Maschinen AZs offline ist.
Wenn Sie Ihre Rechenressourcen skalieren, dauert der Vorgang des Hinzufügens neuer Knoten zur EKS-Datenebene einige Zeit. Dies kann Auswirkungen auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen haben, insbesondere im Falle einer Beeinträchtigung der Zone. Ihre EKS-Umgebung sollte in der Lage sein, den Ausfall einer AZ zu kompensieren, ohne dass dies zu einer Beeinträchtigung der Benutzererfahrung für Ihre Endbenutzer oder Clients führt. Das heißt, die Verzögerung zwischen dem Zeitpunkt, zu dem ein neuer Pod benötigt wird, und dem Zeitpunkt, zu dem er tatsächlich auf einem Worker-Knoten geplant wird, sollte minimiert oder ganz vermieden werden.
Darüber hinaus sollten Sie bei einer Beeinträchtigung der Zonen darauf achten, das Risiko zu minimieren, dass Rechenkapazitätsengpässe auftreten, die verhindern würden, dass neu benötigte Knoten im fehlerfreien Zustand zu Ihrer EKS-Datenebene hinzugefügt werden. AZs
Um das Risiko dieser potenziellen negativen Auswirkungen zu verringern, empfehlen wir, dass Sie in einigen Worker-Knoten in jedem der Workerknoten zu viel Rechenkapazität bereitstellen. AZs Auf diese Weise verfügt der Kubernetes Scheduler über bereits vorhandene Kapazitäten für neue Pod-Platzierungen. Dies ist besonders wichtig, wenn Sie einen Pod in Ihrer Umgebung verlieren. AZs
### Ausführung und Verteilung mehrerer Pod-Replikate über Availability Zones hinweg
Mit Kubernetes können Sie Ihre Workloads vorab skalieren, indem Sie mehrere Instances (Pod-Replikate) einer einzelnen Anwendung ausführen. Durch die Ausführung mehrerer Pod-Replikate für eine Anwendung werden einzelne Fehlerquellen beseitigt und die Gesamtleistung gesteigert, da die Ressourcenbelastung eines einzelnen Replikats reduziert wird. Um jedoch sowohl eine hohe Verfügbarkeit als auch eine bessere Fehlertoleranz für Ihre Anwendungen zu erreichen, empfehlen wir Ihnen, mehrere Replikate Ihrer Anwendung auszuführen und die Replikate auf verschiedene Ausfall-Domains (auch Topologie-Domains genannt) zu verteilen. Die Ausfall-Domains in diesem Szenario sind die Availability Zones. Durch die Verwendung von [Topologie-Verteilungsbeschränkungen](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) können Sie Ihre Anwendungen so einrichten, dass sie über eine bereits vorhandene, statische Stabilität verfügen. Wenn es dann zu einer Beeinträchtigung der Verfügbarkeit kommt, verfügt Ihre Umgebung über genügend Replikate im fehlerfreien Zustand, um etwaige Datenverkehrsspitzen oder AZs -spitzen sofort zu bewältigen.
Das folgende Diagramm zeigt eine EKS-Umgebung, in der der east-to-west Datenverkehr fließt, wenn alle AZs fehlerfrei sind.
![\[Darstellung des Netzwerks\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-spread-constraints.png)
Das folgende Diagramm zeigt eine EKS-Umgebung mit einem east-to-west Verkehrsfluss, bei dem eine einzelne AZ ausgefallen ist und Sie eine Zonenverschiebung gestartet haben.
![\[Darstellung des Netzwerks\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-spread-constraints-2.png)
Der folgende Code-Ausschnitt ist ein Beispiel dafür, wie Sie Ihre Workload mit mehreren Replikaten in Kubernetes einrichten können.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
Vor allem sollten Sie mehrere Replikate Ihrer DNS-Server-Software (CoreDNS/kube-dns) ausführen und ähnliche Topologie-Verteilungsbeschränkungen anwenden, sofern diese nicht standardmäßig konfiguriert sind. Auf diese Weise können Sie sicherstellen, dass bei einer einzelnen AZ-Beeinträchtigung genügend DNS-Pods fehlerfrei sind, AZs um weiterhin Service Discovery-Anfragen für andere kommunizierende Pods im Cluster bearbeiten zu können. Das [CoreDNS EKS-Add-On](managing-coredns.md) verfügt über Standardeinstellungen für die CoreDNS-Pods, die sicherstellen, dass Knoten, die in mehreren AZs verfügbar sind, über die Availability Zones Ihres Clusters verteilt sind. Falls gewünscht, können Sie diese Standardeinstellungen durch Ihre eigenen benutzerdefinierten Konfigurationen ersetzen.
Wenn Sie [CoreDNS mit Helm](https://github.com/coredns/helm/tree/master) installieren, können Sie `replicaCount` in der Datei [values.yaml](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml) anpassen, um sicherzustellen, dass Sie über ausreichend Replikate in jeder AZ verfügen. Um sicherzustellen, dass diese Replikate auf die verschiedenen Replikate AZs in Ihrer Clusterumgebung verteilt sind, stellen Sie außerdem sicher, dass Sie die `topologySpreadConstraints` Eigenschaft in derselben Datei aktualisieren. `values.yaml` Der folgende Code-Ausschnitt veranschaulicht, wie Sie CoreDNS entsprechend konfigurieren können.
**CoreDNS Helm values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
Bei einer AZ-Beeinträchtigung können Sie die erhöhte Belastung der CoreDNS-Pods durch den Einsatz eines Systems zur automatischen Skalierung für CoreDNS abfedern. Die Anzahl der erforderlichen DNS- Instances hängt von der Anzahl der in Ihrem Cluster ausgeführten Workloads ab. CoreDNS ist CPU-gebunden, wodurch es mithilfe des [Horizontal Pod Autoscaler (HPA)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa) basierend auf der CPU skaliert werden kann. Nachfolgend finden Sie ein Beispiel, das Sie an Ihre Anforderungen anpassen können.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
Alternativ kann EKS die automatische Skalierung der CoreDNS-Bereitstellung in der EKS-Add-On-Version von CoreDNS verwalten. Dieser CoreDNS-Autoscaler überwacht kontinuierlich den Status des Clusters, einschließlich der Anzahl der Knoten und CPU-Kerne. Basierend auf diesen Informationen passt der Controller die Anzahl der Replikate der CoreDNS-Bereitstellung in einem EKS-Cluster dynamisch an.
Um die [Konfiguration für die automatische Skalierung im CoreDNS-EKS-Add-On](coredns-autoscaling.md) zu aktivieren, verwenden Sie die folgende Konfigurationseinstellung:
```
{
"autoScaling": {
"enabled": true
}
}
```
Sie können auch [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) oder den [Cluster Proportional Autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) verwenden, um CoreDNS zu skalieren. Weitere Informationen finden Sie unter [Horizontale Skalierung von CoreDNS](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally).
### Co-Location voneinander abhängiger Pods in derselben Availability Zone
In der Regel haben Anwendungen unterschiedliche Workloads, die miteinander kommunizieren müssen, um einen Prozess erfolgreich abzuschließen. end-to-end Wenn diese unterschiedlichen Anwendungen auf verschiedene Bereiche verteilt sind AZs und sich nicht in derselben AZ befinden, kann sich eine einzelne Beeinträchtigung der AZ auf den Prozess auswirken. end-to-end **Wenn **Anwendung A** beispielsweise mehrere Replikate in AZ 1 und AZ 2 hat, **Anwendung B** jedoch alle Replikate in AZ 3 hat, wirkt sich der Verlust von AZ 3 auf end-to-end Prozesse zwischen den beiden Workloads, **Anwendung A und Anwendung** B, aus.** Wenn Sie Beschränkungen der Topologieverteilung mit Pod-Affinität kombinieren, können Sie die Ausfallsicherheit Ihrer Anwendung verbessern, indem Sie Pods über alle Pods verteilen. AZs Darüber hinaus wird dadurch eine Beziehung zwischen bestimmten Pods konfiguriert, um sicherzustellen, dass sie zusammen platziert sind.
Mit [Pod-Affinitätsregeln](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) können Sie Beziehungen zwischen Workloads definieren, um das Verhalten des Kubernetes-Schedulers so zu beeinflussen, dass Pods auf demselben Worker-Knoten oder in derselben AZ zusammengeführt werden. Sie können auch konfigurieren, wie streng die Planungsbeschränkungen sein sollen.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
Das folgende Diagramm zeigt mehrere Pods, die mithilfe von Pod-Affinitätsregeln auf demselben Knoten zusammen platziert wurden.
![\[Darstellung des Netzwerks\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### Testen Ihrer Cluster-Umgebung für die Bewältigung eines Ausfalls einer AZ
Nachdem Sie die in den vorherigen Abschnitten beschriebenen Anforderungen erfüllt haben, müssen Sie im nächsten Schritt überprüfen, ob Sie über ausreichende Rechen- und Workload-Kapazitäten verfügen, um den Ausfall einer AZ zu bewältigen. Dazu können Sie manuell eine Zonenverschiebung in EKS starten. Alternativ können Sie die automatische Zonenverschiebung aktivieren und Testläufe konfigurieren, mit denen ebenfalls überprüft wird, ob Ihre Anwendungen mit einer AZ weniger in Ihrer Cluster-Umgebung wie erwartet funktionieren.
## Häufig gestellte Fragen
**Warum sollte ich dieses Feature nutzen?**
Durch die Verwendung von ARC-Zonenverschiebung oder automatischer Zonenverschiebung in Ihrem EKS-Cluster können Sie die Verfügbarkeit von Kubernetes-Anwendungen besser aufrechterhalten. Dazu wird der schnelle Wiederherstellungsprozess automatisiert, bei dem der Netzwerk-Datenverkehr innerhalb des Clusters von einer beeinträchtigten AZ weg verlagert wird. Mit ARC können Sie langwierige, komplizierte Schritte vermeiden, die bei Störungen in AZs zu einer verlängerten Wiederherstellungszeit führen können
**Wie funktioniert diese Funktion mit anderen Diensten? AWS **
EKS ist in ARC integriert, das die primäre Schnittstelle für die Durchführung von Wiederherstellungsvorgängen darstellt AWS. Um sicherzustellen, dass der Datenverkehr innerhalb des Clusters ordnungsgemäß von einer beeinträchtigten AZ weggeleitet wird, nimmt EKS Änderungen an der Liste der Netzwerkendpunkte für Pods vor, die in der Kubernetes-Datenebene ausgeführt werden. Wenn Sie Elastic Load Balancing verwenden, um externen Datenverkehr in den Cluster zu leiten, können Sie Ihre Load Balancer bei ARC registrieren und eine Zonenverschiebung auf ihnen starten, um zu verhindern, dass Datenverkehr in die beeinträchtigte AZ gelangt. Zonal Shift funktioniert auch mit Amazon EC2 Auto Scaling Scaling-Gruppen, die von EKS verwalteten Knotengruppen erstellt werden. Um zu verhindern, dass eine beeinträchtigte AZ für neue Kubernetes-Pods oder Knoten-Starts verwendet wird, entfernt EKS die beeinträchtigte AZ aus den Auto-Scaling-Gruppen.
**Inwiefern unterscheidet sich dieses Feature von den standardmäßigen Kubernetes-Schutzmaßnahmen?**
Dieses Feature arbeitet mit mehreren in Kubernetes integrierten Schutzmaßnahmen zusammen, welche die Ausfallsicherheit von Kundenanwendungen verbessern Sie können Pod-Bereitschafts- und Aktivitätsprüfung konfigurieren, die entscheiden, wann ein Pod Datenverkehr aufnehmen soll. Wenn diese Prüfungen fehlschlagen, entfernt Kubernetes diese Pods als Ziele für einen Service, und es wird kein Datenverkehr mehr an den Pod gesendet. Dies ist zwar nützlich, für Kunden ist es jedoch nicht einfach, diese Integritätsprüfungen so zu konfigurieren, dass sie garantiert fehlschlagen, wenn eine AZ beeinträchtigt wird. Feature für die ARC-Zonenverschiebung bietet ein zusätzliches Sicherheitsnetz, mit dem Sie eine beeinträchtigte AZ vollständig isolieren können, wenn der native Schutz von Kubernetes nicht ausreicht. Durch Zonenverschiebung können Sie außerdem auf einfache Weise die Betriebsbereitschaft und Ausfallsicherheit Ihrer Architektur überprüfen.
**Kann ich in meinem Namen eine Zonenverschiebung AWS starten?**
Ja, wenn Sie eine vollständig automatisierte Nutzung der ARC-Zonenverschiebung wünschen, können Sie die automatische ARC-Zonenverschiebung aktivieren. Mit Zonal Autoshift können Sie sich AWS darauf verlassen, dass Sie den Zustand Ihres EKS-Clusters überwachen und automatisch eine Zonenverschiebung starten, wenn eine Beeinträchtigung der AZ festgestellt wird. AZs
**Was geschieht, wenn ich dieses Feature verwende und meine Worker-Knoten und Workloads nicht vorab skaliert sind?**
Wenn Sie nicht vorab skaliert haben und während einer Zonenverschiebung auf die Bereitstellung zusätzlicher Knoten oder Pods angewiesen sind, riskieren Sie eine verzögerte Wiederherstellung. Das Hinzufügen neuer Knoten zur Kubernetes-Datenebene nimmt einige Zeit in Anspruch, was sich auf die Echtzeitleistung und Verfügbarkeit Ihrer Anwendungen auswirken kann, insbesondere bei einer Beeinträchtigung der Zone. Darüber hinaus kann es bei einer Beeinträchtigung der Zonen zu einer potenziellen Einschränkung der Rechenkapazität kommen, die verhindern könnte, dass neu benötigte Knoten zu den fehlerfreien Knoten hinzugefügt werden. AZs
Wenn Ihre Workloads nicht vorab skaliert und auf alle Bereiche Ihres Clusters verteilt sind, kann sich eine zonale Beeinträchtigung auf die Verfügbarkeit einer Anwendung auswirken, die nur auf Worker-Knoten AZs in einer betroffenen AZ ausgeführt wird. Um das Risiko eines vollständigen Ausfalls der Verfügbarkeit Ihrer Anwendung zu mindern, verfügt EKS über eine Ausfallsicherung für den Datenverkehr, der an Pod-Endpunkte in einer beeinträchtigten Zone gesendet wird, wenn alle Endpunkte dieser Workload in der nicht funktionsfähigen AZ liegen. Wir empfehlen jedoch dringend, dass Sie Ihre Anwendungen vorab skalieren und auf alle verteilen, AZs um die Verfügbarkeit im Falle eines zonalen Problems aufrechtzuerhalten.
**Wie funktioniert dies, wenn ich eine zustandsbehaftete Anwendung ausführe?**
Wenn Sie eine zustandsbehaftete Anwendung ausführen, müssen Sie deren Fehlertoleranz auf der Grundlage Ihres Anwendungsfalls und Ihrer Architektur bewerten. Wenn Sie über eine active/standby Architektur oder ein Muster verfügen, kann es vorkommen, dass sich die aktive Komponente in einer beeinträchtigten AZ befindet. Auf Anwendungsebene kann es zu Problemen mit Ihrer Anwendung kommen, wenn der Standby-Modus nicht aktiviert ist. Möglicherweise treten auch Probleme auf, wenn neue Kubernetes-Pods im fehlerfreien Zustand gestartet werden AZs, da sie sich dann nicht mit den persistenten Volumes verbinden können, die auf die beeinträchtigte AZ beschränkt sind.
**Ist dieses Feature mit Karpenter kompatibel?**
Derzeit wird Karpenter nicht mit der ARC-Zonenverschiebung und Zonal Autoshift in EKS unterstützt. Wenn eine AZ beeinträchtigt ist, können Sie die entsprechende NodePool Karpenter-Konfiguration anpassen, indem Sie die fehlerhafte AZ entfernen, sodass neue Worker-Knoten nur in der anderen gestartet werden. AZs
**Ist dieses Feature mit EKS Fargate kompatibel?**
Dieses Feature ist mit EKS Fargate nicht kompatibel. Wenn EKS Fargate ein zonales Gesundheitsereignis erkennt, ziehen es Pods standardmäßig vor, in dem anderen System ausgeführt zu werden. AZs
**Wird die von EKS verwaltete Kubernetes- Steuerebene davon betroffen sein?**
Nein, Amazon EKS führt standardmäßig die Kubernetes-Steuerebene aus und skaliert sie über mehrere, AZs um eine hohe Verfügbarkeit zu gewährleisten. Die ARC-Zonenverschiebung und die automatische Zonenverschiebung wirken sich ausschließlich auf die Kubernetes-Datenebene aus.
**Sind mit diesem neuen Feature Kosten verbunden?**
Sie können ARC-Zonenverschiebung und automatische Zonenverschiebung in Ihrem EKS-Cluster ohne zusätzliche Kosten nutzen. Sie müssen jedoch weiterhin für bereitgestellte Instances bezahlen. Wir empfehlen Ihnen dringend, Ihre Kubernetes-Datenebene vor der Nutzung dieses Features vorab zu skalieren. Sie sollten ein Gleichgewicht zwischen Kosten und Anwendungsverfügbarkeit anstreben.
## Weitere Ressourcen
+ [Funktionsweise einer Zonenverschiebung](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [Bewährte Methoden für Zonenverschiebungen in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [Unterstützte Ressourcen und Szenarien für Zonenverschiebung und automatische Zonenverschiebung](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Ausführung ausfallsicherer Workloads in Amazon EKS](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [Beseitigung von Verzögerungen bei der Skalierung von Kubernetes-Knoten durch Pod-Priorität und Überbereitstellung](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [Skalierung von CoreDNS-Pods für hohen DNS-Datenverkehr](coredns-autoscaling.md)
# Aktivierung der EKS-Zonenverschiebung zur Vermeidung beeinträchtigter Availability Zones
Amazon Application Recovery Controller (ARC) unterstützt Sie bei der Verwaltung und Koordination der Wiederherstellung Ihrer Anwendungen in allen Availability Zones (AZs) und funktioniert mit vielen Services, einschließlich Amazon EKS. Mithilfe des EKS-Supports für ARC-Zonenverschiebung können Sie den Netzwerkverkehr innerhalb des Clusters von einer beeinträchtigten AZ weg verlagern. Sie können auch autorisieren AWS , den Zustand Ihres Netzwerkverkehrs zu überwachen AZs und den Netzwerkverkehr in Ihrem Namen vorübergehend von einer fehlerhaften AZ wegzuverlagern.
**Verwendung der EKS-Zonenverschiebung:**
1. Aktivieren Sie Ihren EKS-Cluster mit Amazon Application Recovery Controller (ARC). Dies erfolgt auf Cluster-Ebene mithilfe der Amazon EKS-Konsole, der AWS CLI oder eksctl. CloudFormation
1. Nach der Aktivierung können Sie Zonal Shifts oder Zonal Autoshift mit der ARC-Konsole, der AWS CLI oder Zonal Shift und Zonal Autoshift verwalten. APIs
Beachten Sie, dass Sie nach der Registrierung eines EKS-Clusters bei ARC noch ARC konfigurieren müssen. Sie können beispielsweise die ARC-Konsole verwenden, um die automatische Zonenverschiebung zu konfigurieren.
Ausführlichere Informationen zur Funktionsweise der EKS-Zonenverschiebung und zur Gestaltung Ihrer Workloads für den Umgang mit beeinträchtigten Availability Zones finden Sie unter [Weitere Informationen zur Zonenverschiebung von Amazon Application Recovery Controller (ARC) in Amazon EKS](zone-shift.md).
## Überlegungen
+ EKS Auto Mode unterstützt weder den Amazon Application Recovery Controller noch Zonenverschiebung und automatische Zonenverschiebung.
+ Wir empfehlen, zwischen den Vorgängen von Zonenverschiebungen mindestens 60 Sekunden zu warten, um eine ordnungsgemäße Verarbeitung jeder Anfrage sicherzustellen.
Bei dem Versuch, Zonenverschiebungen in schneller Folge (innerhalb von 60 Sekunden) durchzuführen, kann es vorkommen, dass der Amazon-EKS-Service nicht alle Verschiebungsanforderungen ordnungsgemäß verarbeitet. Dies ist auf den aktuellen Abfragemechanismus zurückzuführen, der den Zonen-Status des Clusters aktualisiert. Wenn Sie mehrere Zonenverschiebungen durchführen müssen, stellen Sie sicher, dass zwischen den Vorgängen ausreichend Zeit liegt, damit das System jede Änderung verarbeiten kann.
## Was ist Amazon Application Recovery Controller?
Der Amazon Application Recovery Controller (ARC) unterstützt Sie bei der Vorbereitung und Durchführung einer schnelleren Wiederherstellung für Anwendungen, die in AWS ausgeführt werden. Zonal Shift ermöglicht es Ihnen, sich schnell von Beeinträchtigungen der Availability Zone (AZ) zu erholen, indem Sie den Verkehr für eine unterstützte Ressource vorübergehend von einer AZ auf eine gesunde in der Region verlagern. AZs AWS
[Weitere Informationen zu Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## Was ist eine Zonenverschiebung?
Zonal Shift ist eine Funktion in ARC, mit der Sie den Traffic für eine Ressource wie einen EKS-Cluster oder einen Elastic Load Balancer von einer Availability Zone in einer AWS Region wegverlagern können, um ein Problem schnell zu beheben und Ihre Anwendung schnell wiederherzustellen. Sie können sich beispielsweise für eine Verlagerung des Datenverkehrs entscheiden, weil eine fehlerhafte Bereitstellung zu Latenzproblemen führt oder weil die Availability Zone beeinträchtigt ist. Eine Zonenverschiebung erfordert keine vorherigen Konfigurationsschritte.
[Weitere Informationen zur ARC-Zonenverschiebung](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## Was ist die automatische Zonenverschiebung?
Zonal Autoshift ist eine Funktion in ARC, die Sie aktivieren können, um zu autorisieren AWS , dass der Datenverkehr in Ihrem Namen von einer AZ für unterstützte Ressourcen auf gesunde Ressourcen in der Region umgeleitet wird. AZs AWS AWS startet eine automatische Verschiebung, wenn die interne Telemetrie anzeigt, dass in einer AZ in einer Region eine Beeinträchtigung vorliegt, die sich möglicherweise auf Kunden auswirken könnte. Die interne Telemetrie beinhaltet Metriken aus verschiedenen Quellen, darunter dem AWS Netzwerk und den Amazon- EC2 und Elastic Load Balancing Balancing-Diensten.
AWS beendet Autoshifts, wenn Indikatoren anzeigen, dass kein Problem oder potenzielles Problem mehr besteht.
[Weitere Informationen zur automatischen Zonenverschiebung von ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## Was unternimmt EKS während einer automatischen Verschiebung?
EKS aktualisiert die Netzwerkkonfigurationen, um zu verhindern, dass der Datenverkehr an beeinträchtigte Personen weitergeleitet wird. AZs Wenn Sie verwaltete Knotengruppen verwenden, startet EKS außerdem nur AZs während einer Zonenverschiebung neue Knoten im fehlerfreien Zustand. AZs. Wenn die Verschiebung abläuft oder abgebrochen wird, werden die Netzwerkkonfigurationen wiederhergestellt, sodass die zuvor als nicht funktionsfähig erkannte AZ wieder einbezogen wird.
[Weitere Informationen zur EKS-Zonenverschiebung](zone-shift.md)
## Registrieren Sie den EKS-Cluster beim Amazon Application Recovery Controller (ARC) (AWS Konsole)
1. Suchen Sie den Namen und die Region des EKS-Clusters, den Sie bei ARC registrieren möchten.
1. Navigieren Sie zur [EKS-Konsole](https://console.aws.amazon.com/eks) in dieser Region und wählen Sie Ihren Cluster aus.
1. Wählen Sie auf der Seite **Cluster-Informationen** die Registerkarte **Übersicht** aus.
1. Klicken Sie unter der Überschrift **Zonenverschiebung** auf die Schaltfläche **Verwalten**.
1. **Aktivieren** oder **deaktivieren** Sie die *EKS-Zonenverschiebung*.
Ihr EKS-Cluster ist nun bei ARC registriert.
Wenn Sie beeinträchtigte Availability Zones erkennen und vermeiden möchten AWS , müssen Sie ARC Zonal Autoshift konfigurieren. Sie können dies beispielsweise in der ARC-Konsole tun.
## Nächste Schritte
+ Erfahren Sie, wie Sie die [automatische Zonenverschiebung aktivieren](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html).
+ Erfahren Sie, wie Sie eine [automatische Zonenverschiebung](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) manuell starten.