**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.
# Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze
Wenn Sie einen Cluster erstellen, geben Sie eine [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html) und mindestens zwei Subnetze an, die sich in unterschiedlichen Availability Zones befinden. Dieses Thema bietet einen Überblick über die spezifischen Amazon-EKS-Anforderungen und Überlegen zur VPC und den Subnetzen, die Sie in Ihrem Cluster verwenden. Wenn Sie nicht über VPC für die Verwendung mit Amazon EKS verfügen, lesen Sie [Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md). Wenn Sie einen lokalen oder erweiterten Cluster auf AWS Outposts erstellen, lesen Sie [Erstellung einer VPC und von Subnetzen für Amazon-EKS-Cluster in AWS Outposts](eks-outposts-vpc-subnet-requirements.md) statt dieses Themas weiter. Der Inhalt dieses Themas bezieht sich auf Amazon-EKS-Cluster mit Hybridknoten. Weitere Netzwerkanforderungen für Hybridknoten finden Sie unter [Vorbereitung der Vernetzung für Hybridknoten](hybrid-nodes-networking.md).
## VPC-Anforderungen und -Überlegungen
Wenn Sie einen Cluster erstellen, muss die von Ihnen angegebene VPC die folgenden Anforderungen und Überlegungen erfüllen:
+ Die VPC muss über eine ausreichende Anzahl von IP-Adressen für den Cluster, alle Knoten und andere Kubernetes-Ressourcen, die Sie erstellen möchten, verfügen. Wenn die VPC, die Sie verwenden möchten, nicht über eine ausreichende Anzahl von IP-Adressen verfügt, versuchen Sie, die Anzahl der verfügbaren IP-Adressen zu erhöhen.
Sie können dies tun, indem Sie die Clusterkonfiguration aktualisieren, um zu ändern, welche Subnetze und Sicherheitsgruppen der Cluster verwendet. Sie können von der AWS-Managementkonsole, der neuesten Version der AWS CLI AWS CloudFormation, und `eksctl` Version `v0.164.0-rc.0` oder höher aus aktualisieren. Möglicherweise müssen Sie dies tun, um Subnetzen mehr verfügbare IP-Adressen zur Verfügung zu stellen, damit eine Clusterversion erfolgreich aktualisiert werden kann.
**Wichtig**
Alle Subnetze, die Sie hinzufügen, müssen sich in derselben Gruppe befinden, die ursprünglich bei der AZs Erstellung des Clusters bereitgestellt wurde. Neue Subnetze müssen alle anderen Anforderungen erfüllen, z. B. müssen sie über ausreichend IP-Adressen verfügen.
Angenommen, Sie haben einen Cluster erstellt und vier Subnetze angegeben. In der Reihenfolge, in der Sie sie angegeben haben, befindet sich das erste Subnetz in der `us-west-2a` Availability Zone, das zweite und dritte Subnetz in der `us-west-2b` Availability Zone und das vierte Subnetz in der `us-west-2c` Availability Zone. Wenn Sie die Subnetze ändern möchten, müssen Sie in jeder der drei Availability Zones mindestens ein Subnetz bereitstellen, und die Subnetze müssen sich in derselben VPC wie die ursprünglichen Subnetze befinden.
Wenn Sie mehr IP-Adressen benötigen, als die CIDR-Blöcke in der VPC haben, können Sie zusätzliche CIDR-Blöcke hinzufügen, indem Sie Ihrer VPC [zusätzliche Classless Inter-Domain Routing (CIDR)-Blöcke zuordnen](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr). Sie können entweder vor oder nach der Erstellung Ihres Clusters private (RFC 1918) und öffentliche (nicht RFC 1918) CIDR-Blöcke mit Ihrer VPC verbinden.
Sie können Knoten hinzufügen, die den neuen CIDR-Block verwenden, unmittelbar nachdem Sie ihn hinzugefügt haben. Da die Steuerebene den neuen CIDR-Block jedoch erst nach Abschluss der Abstimmung erkennt, kann es bis zu einer Stunde dauern, bis ein CIDR-Block, den Sie einer VPC zugeordnet haben, von einem Cluster erkannt wird. Anschließend können Sie die Befehle`kubectl attach`,, `kubectl cp` `kubectl exec``kubectl logs`, und (diese `kubectl port-forward` Befehle verwenden die`kubelet API`) für Knoten und Pods im neuen CIDR-Block ausführen. Wenn Sie Pods haben, die als Webhook-Backend fungieren, müssen Sie außerdem warten, bis die Abstimmung der Steuerebene abgeschlossen ist.
+ Vermeiden Sie Überschneidungen von IP-Adressbereichen, wenn Sie Ihren EKS-Cluster VPCs über Transit Gateway, VPC-Peering oder andere Netzwerkkonfigurationen mit anderen verbinden. CIDR-Konflikte treten auf, wenn sich der Service-CIDR Ihres EKS-Clusters mit dem CIDR einer verbundenen VPC überschneidet. In diesen Szenarien haben Service-IP-Adressen Vorrang vor Ressourcen, die VPCs mit derselben IP-Adresse verbunden sind, obwohl das Routing des Datenverkehrs unvorhersehbar werden kann und Anwendungen möglicherweise keine Verbindung zu den vorgesehenen Ressourcen herstellen können.
Um CIDR-Konflikte zu vermeiden, stellen Sie sicher, dass sich Ihr EKS-Dienst-CIDR nicht mit einer verbundenen VPC überschneidet, CIDRs und führen Sie eine zentrale Aufzeichnung aller CIDR-Zuweisungen. Wenn Sie CIDR-Überschneidungen feststellen, können Sie ein Transit-Gateway mit einer freigegebenen Service-VPC verwenden. Weitere Informationen finden Sie unter [Isoliert VPCs mit Shared Services](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-isolated-shared.html) und [Muster zur Aufbewahrung routingfähiger IP-Adressen von Amazon EKS VPC in einem Hybridnetzwerk](https://aws.amazon.com/blogs/containers/eks-vpc-routable-ip-address-conservation). Weitere Informationen finden Sie auf der Seite [Überlegungen zu VPC und Subnetzen](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html) im EKS Best Practices Guide im VPCs Abschnitt Kommunikation zwischen beiden Seiten.
+ Wenn Sie möchten, dass Kubernetes `IPv6`-Adressen zu Pods und Services zuweist, ordnen Sie Ihrer VPC einen `IPv6`-CIDR-Block zu. Weitere Informationen finden Sie unter [Verknüpfen eines IPv6 CIDR-Blocks mit Ihrer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) im Amazon VPC-Benutzerhandbuch. Sie können keine `IPv6`-Adressen mit Pods und Services verwenden, die auf Hybridknoten ausgeführt werden, und Sie können keine Hybridknoten mit Clustern verwenden, die mit der `IPv6`-IP-Adressfamilie konfiguriert sind.
+ Die VPC muss `DNS`-Hostnamen und die `DNS`-Auflösung unterstützen. Andernfalls können keine Knoten dem Cluster beitreten. Weitere Informationen finden Sie unter [DNS-Attribute für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) im Amazon-VPC-Benutzerhandbuch.
+ Die VPC erfordert möglicherweise die Verwendung von VPC-Endpunkten. AWS PrivateLink Weitere Informationen finden Sie unter [Subnetz-Anforderungen und -Überlegungen](#network-requirements-subnets).
Wenn Sie einen Cluster mit Kubernetes `1.14` oder früher erstellt haben, hat Amazon EKS das folgende Tag zu Ihrer VPC hinzugefügt:
| Schlüssel | Wert |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `owned` |
Dieses Tag wurde nur von Amazon EKS verwendet. Sie können das Tag entfernen, ohne Ihre Services zu beeinträchtigen. Es wird nicht mit Clustern der Version `1.15` oder höher verwendet.
## Subnetz-Anforderungen und -Überlegungen
Wenn Sie einen Cluster erstellen, erstellt Amazon EKS 2–4 [Elastic-Network-Schnittstellen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) in den von Ihnen angegebenen Subnetzen. Diese Netzwerkschnittstellen ermöglichen die Kommunikation zwischen Ihrem Cluster und Ihrer VPC. Diese Netzwerkschnittstellen ermöglichen auch Kubernetes-Funktionen, die die verwenden. `kubelet API` Die Verbindungen zur `kubelet` API werden in den Befehlen`kubectl attach`,, `kubectl cp` `kubectl exec``kubectl logs`, und `kubectl port-forward` verwendet. Jede von Amazon EKS erstellte Netzwerkschnittstelle enthält den Text `Amazon EKS cluster-name ` in ihrer Beschreibung.
Amazon EKS kann Netzwerkschnittstellen in jedem Subnetz erstellen, dass Sie bei der Erstellung eines Clusters angeben. Nach der Erstellung Ihres Clusters können Sie ändern, in welchen Subnetzen Amazon EKS seine Netzwerkschnittstellen erstellt. Wenn Sie die Kubernetes-Version eines Clusters aktualisieren, löscht Amazon EKS die ursprünglichen Netzwerkschnittstellen, die es erstellt hat, und erstellt neue Netzwerkschnittstellen. Diese Netzwerkschnittstellen können in denselben Subnetzen wie die ursprünglichen Netzwerkschnittstellen oder in anderen Subnetzen als die ursprünglichen Netzwerkschnittstellen erstellt werden. Um zu steuern, in welchen Subnetzen Netzwerkschnittstellen erstellt werden, können Sie die Anzahl der von Ihnen angegebenen Subnetze beim Erstellen eines Clusters auf zwei beschränken oder die Subnetze nach der Erstellung des Clusters aktualisieren.
### Subnetzanforderungen für Cluster
Die [Subnetze](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types), die Sie angeben, wenn Sie einen Cluster erstellen oder aktualisieren, müssen die folgenden Anforderungen erfüllen:
+ Die Subnetze müssen jeweils mindestens 6 IP-Adressen zur Verwendung durch Amazon EKS haben. Wir empfehlen jedoch mindestens 16 IP-Adressen.
+ Die Subnetze müssen sich in mindestens zwei verschiedenen Availability Zones befinden.
+ Die Subnetze können sich nicht in AWS Outposts oder Wavelength befinden. AWS Wenn Sie sich in Ihrer VPC befinden, können Sie jedoch selbstverwaltete Knoten und Kubernetes-Ressourcen für diese Subnetz-Typen bereitstellen. Weitere Informationen zu Ihren selbstverwalteten Knoten finden Sie unter [Knoten selbst mit selbstverwalteten Knoten verwalten](worker.md).
+ Die Subnetze können öffentlich oder privat sein. Es wird jedoch empfohlen, wenn möglich private Subnetze anzugeben. Ein öffentliches Subnetz ist ein Subnetz mit einer Routing-Tabelle, die eine Route zu einem [Internet-Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) enthält. Ein privates Subnetz ist ein Subnetz mit einer Routing-Tabelle, die keine Route zu einem Internet-Gateway enthält.
+ Die Subnetze dürfen sich nicht in folgenden Availability Zones befinden:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/network-reqs.html)
### Verwendung der IP-Adressfamilie nach Komponenten
Die folgende Tabelle enthält die IP-Adressfamilie, die von jeder Komponente von Amazon EKS verwendet wird. Sie können eine Network Address Translation (NAT) oder ein anderes Kompatibilitätssystem verwenden, um eine Verbindung zu diesen Komponenten von Quell-IP-Adressen in Familien herzustellen, deren Tabelleneintrag den Wert „Nein“ aufweist.
Die Funktionalität kann je nach Einstellung der IP-Familie (`ipFamily`) des Clusters variieren. Diese Einstellung ändert den Typ der IP-Adressen, die für den CIDR-Block verwendet werden, den Kubernetes den Services zuweist. Ein Cluster mit dem Einstellungswert von IPv4 wird als *IPv4 Cluster* bezeichnet, und ein Cluster mit dem Einstellungswert von IPv6 wird als *IPv6 Cluster* bezeichnet.
| Komponente | IPv4 Adressen | IPv6 adressen | Dual-Stack-Adressen |
| --- | --- | --- | --- |
| Öffentlicher Endpunkt der EKS-API | Ja1,3 | Ja1,3 | Ja1,3 |
| EKS-API-VPC-Endpunkt | Ja | Nein | Nein |
| Öffentlicher Endpunkt der EKS-Auth-API (EKS Pod Identity) | Ja1 | Ja1 | Ja1 |
| VPC-Endpunkt der EKS-Auth-API (EKS Pod Identity) | Ja1 | Ja1 | Ja1 |
| Öffentlicher Endpunkt des `IPv4`-Kubernetes-Clusters2 | Ja | Nein | Nein |
| Privater Endpunkt des `IPv4`-Kubernetes-Clusters2 | Ja | Nein | Nein |
| Öffentlicher Endpunkt des `IPv6`-Kubernetes-Clusters2 | Ja1,4 | Ja1,4 | Ja4 |
| Privater Endpunkt des `IPv6`-Kubernetes-Clusters2 | Ja1,4 | Ja1,4 | Ja4 |
| Kubernetes-Cluster-Subnetze | Ja2 | Nein | Ja2 |
| Primäre IP-Adressen der Knoten | Ja2 | Nein | Ja2 |
| Cluster-CIDR-Bereich für Service-IP-Adressen | Ja2 | Ja2 | Nein |
| Pod-IP-Adressen vom VPC CNI | Ja2 | Ja2 | Nein |
| IRSA OIDC-Emittent URLs | Ja1,3 | Ja1,3 | Ja1,3 |
**Anmerkung**
1 Der Endpunkt ist ein Dual-Stack mit sowohl `IPv4`- als auch `IPv6`-Adressen. Ihre Anwendungen außerhalb AWS, Ihre Knoten für den Cluster und Ihre Pods innerhalb des Clusters können diesen Endpunkt entweder mit oder erreichen. `IPv4` `IPv6`
2 Sie wählen beim Erstellen eines Clusters in der IP-Familieneinstellung (`ipFamily`) des Clusters zwischen einem `IPv4`-Cluster und einem `IPv6`-Cluster. Dies kann nicht geändert werden. Stattdessen müssen Sie beim Erstellen eines weiteren Clusters und beim Migrieren Ihrer Workloads eine andere Einstellung wählen.
3 Der Dual-Stack-Endpunkt wurde im August 2024 eingeführt. *Informationen zur Verwendung der Dual-Stack-Endpunkte mit der AWS CLI finden Sie in der Konfiguration von [Dual-Stack- und FIPS-Endpunkten](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) im AWS SDKs Referenzhandbuch zu Tools.* Nachfolgend sind die neuen Endpunkte aufgeführt:
**Öffentlicher Endpunkt der EKS-API**
`eks.region.api.aws`
**IRSA OIDC-Emittent URLs**
`oidc-eks.region.api.aws`
4 Der Dual-Stack-Cluster-Endpunkt wurde im Oktober 2024 eingeführt. EKS erstellt den folgenden Endpunkt für neue Cluster, die nach diesem Datum erstellt werden und die `IPv6` in der IP-Familieneinstellung (ipFamily) des Clusters auswählen
** public/private EKS-Cluster-Endpunkt**
`eks-cluster.region.api.aws`
### Subnetzanforderungen für Knoten
Sie können Knoten und Kubernetes-Ressourcen in denselben Subnetzen bereitstellen, die Sie beim Erstellen Ihres Clusters angeben. Das ist aber nicht unbedingt notwendig. Sie können Knoten und Kubernetes-Ressourcen auch in Subnetzen bereitstellen, die Sie nicht beim Erstellen des Clusters angegeben haben. Wenn Sie Knoten in verschiedenen Subnetzen bereitstellen, erstellt Amazon EKS keine Cluster-Netzwerkschnittstellen in diesen Subnetzen. Jedes Subnetz, für das Sie Knoten und Kubernetes-Ressourcen bereitstellen, muss die folgenden Anforderungen erfüllen:
+ Die Subnetze müssen über genügend verfügbare IP-Adressen verfügen, um alle Ihre Knoten und Kubernetes-Ressourcen bereitzustellen.
+ Wenn Kubernetes Pods und Services `IPv6`-Adressen zuweisen soll, müssen Sie über einen `IPv6`-CIDR-Block und einen `IPv4`-CIDR-Block verfügen, die Ihrem Subnetz zugeordnet sind. Weitere Informationen finden Sie unter [Zuordnen eines IPv6 CIDR-Blocks zu Ihrem Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-associate-ipv6-cidr) im Amazon VPC-Benutzerhandbuch. Die Routing-Tabellen, die Ihren Subnetzen zugeordnet sind, müssen Routen zu `IPv4`- und `IPv6`-Adressen enthalten. Weitere Informationen finden Sie unter [Routen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-table-routes) im Amazon-VPC-Benutzerhandbuch. Pods werden nur einer `IPv6`-Adresse zugewiesen. Die Netzwerkschnittstellen, die Amazon EKS für Ihren Cluster und Ihre Knoten erstellt, werden jedoch einer `IPv4`- und einer `IPv6`-Adresse zugewiesen.
+ Wenn Sie eingehenden Zugriff aus dem Internet auf Ihre Pods benötigen, stellen Sie sicher, dass Sie mindestens ein öffentliches Subnetz mit genügend verfügbaren IP-Adressen haben, in denen Sie Load Balancer und Ingresse bereitstellen können. Sie können Load Balancer in öffentlichen Subnetzen bereitstellen. Load Balancer können ein Load Balancing zu Pods in privaten und öffentlichen Subnetzen vornehmen. Wir empfehlen, Ihre Knoten nach Möglichkeit in privaten Subnetzen bereitzustellen.
+ Wenn Sie planen, Knoten in einem öffentlichen Subnetz bereitzustellen, muss das Subnetz automatisch öffentliche `IPv4`- oder `IPv6`-Adressen zuweisen. Wenn Sie Knoten in einem privaten Subnetz bereitstellen, das einen zugeordneten `IPv6`-CIDR-Block hat, muss das private Subnetz zudem `IPv6`-Adressen automatisch zuweisen. Wenn Sie die von Amazon EKS bereitgestellte AWS CloudFormation Vorlage für die Bereitstellung Ihrer VPC nach dem 26. März 2020 verwendet haben, ist diese Einstellung aktiviert. Wenn Sie die Vorlagen verwendet haben, um Ihre VPC vor diesem Datum bereitzustellen oder Ihre eigene VPC verwenden, müssen Sie diese Einstellung manuell aktivieren. Informationen zur Vorlage finden Sie unter [Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md). Weitere Informationen finden Sie unter [Ändern des öffentlichen IPv4 Adressierungsattributs für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-public-ip) und [Ändern des IPv6 Adressierungsattributs für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-ipv6) im [Amazon VPC-Benutzerhandbuch](https://docs.aws.amazon.com/vpc/latest/userguide/).
+ Wenn es sich bei dem Subnetz, in dem Sie einen Knoten bereitstellen, um ein privates Subnetz handelt und die Routing-Tabelle keine Route zu einem [NAT-Gerät (Network Address Translation) ()](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html) oder einem [reinen Ausgangsgateway](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) (`IPv4``IPv6`) enthält, fügen Sie Ihrer VPC VPC-Endpunkte hinzu, die Sie verwenden. AWS PrivateLink VPC-Endpunkte werden für alle AWS Dienste benötigt, mit denen Ihre Knoten und Pods kommunizieren müssen. Beispiele hierfür sind Amazon ECR, Elastic Load Balancing CloudWatch, Amazon, AWS Security Token Service und Amazon Simple Storage Service (Amazon S3). Der Endpunkt muss das Subnetz enthalten, in dem sich die Knoten befinden. Nicht alle AWS Dienste unterstützen VPC-Endpunkte. Weitere Informationen finden Sie unter [Was ist? AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) und [AWS Dienste, die sich in integrieren lassen AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html). Eine Liste weiterer Amazon-EKS-Anforderungen finden Sie unter [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md).
+ Wenn Sie Load Balancer in einem Subnetz bereitstellen möchten, muss das Subnetz das folgende Tag haben:
+ Private Subnetze
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/network-reqs.html)
+ Öffentliche Subnetze
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/network-reqs.html)
Wenn ein Kubernetes-Cluster mit der Version `1.18` oder früher erstellt wurde, fügt Amazon EKS das folgende Tag zu allen Subnetzen hinzu, die angegeben wurden.
| Key (Schlüssel) | Value (Wert) |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `shared` |
Wenn Sie jetzt einen neuen Kubernetes-Cluster erstellen, fügt Amazon EKS das Tag nicht zu Ihren Subnetzen hinzu. Wenn sich das Tag in Subnetzen befand, die von einem Cluster verwendet wurden, der zuvor eine Version vor `1.19` war, wurde das Tag nicht automatisch aus den Subnetzen entfernt, als der Cluster auf eine neuere Version aktualisiert wurde. Für Version `2.1.1` oder früher des Load AWS Balancer Controllers ist dieses Tag erforderlich. Wenn Sie eine neuere Version des Load Balancer Controllers verwenden, können Sie das Tag entfernen, ohne Ihre Services zu unterbrechen. Weitere Informationen über den Controller finden Sie unter [Internetverkehr mit AWS Load Balancer Controller weiterleiten](aws-load-balancer-controller.md).
Wenn Sie eine VPC mithilfe einer `eksctl` oder einer der Amazon AWS CloudFormation EKS-VPC-Vorlagen bereitgestellt haben, gilt Folgendes:
+ **Am oder nach dem 26. März 2020** – Öffentliche `IPv4`-Adressen werden von öffentlichen Subnetzen automatisch neuen Knoten zugewiesen, die in öffentlichen Subnetzen bereitgestellt werden.
+ **Vor dem 26. März 2020** – Öffentliche `IPv4`-Adressen werden von öffentlichen Subnetzen nicht automatisch neuen Knoten zugewiesen, die in öffentlichen Subnetzen bereitgestellt werden.
Diese Änderung wirkt sich folgendermaßen auf neue Knotengruppen aus, die in öffentlichen Subnetzen bereitgestellt werden:
+ ** [Verwaltete Knotengruppen](create-managed-node-group.md) ** – Wenn die Knotengruppe am oder nach dem 22. April 2020 in einem öffentlichen Subnetz bereitgestellt wird, muss für das öffentliche Subnetz die automatische Zuweisung öffentlicher IP-Adressen aktiviert sein. Weitere Informationen finden Sie unter [Ändern des Public IPv4 Addressing-Attributs für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
+ **Selbstverwaltete [Linux](launch-workers.md)-, [Windows](launch-windows-workers.md)- oder [Arm](eks-optimized-ami.md#arm-ami)-Knotengruppen** – Wenn die Knotengruppe am oder nach dem 26. März 2020 in einem öffentlichen Subnetz bereitgestellt wird, muss für das öffentliche Subnetz die automatische Zuweisung öffentlicher IP-Adressen aktiviert sein. Andernfalls müssen die Knoten mit einer öffentlichen IP-Adresse gestartet werden. Weitere Informationen finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) oder [Zuweisen einer öffentlichen IPv4 Adresse beim](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-public-ip) Instance-Start.
## Anforderungen und Überlegungen für gemeinsam genutzte Subnetze
Sie können *VPC Sharing* verwenden, um Subnetze mit anderen AWS Konten innerhalb derselben AWS Organizations zu teilen. Sie können Amazon-EKS-Cluster in gemeinsam genutzten Subnetzen erstellen. Beachten Sie dabei die folgenden Überlegungen:
+ Der Eigentümer des VPC-Subnetzes muss ein Subnetz für ein Teilnehmerkonto freigeben, bevor dieses Konto darin einen Amazon-EKS-Cluster erstellen kann.
+ Sie können keine Ressourcen mit der Standardsicherheitsgruppe für die VPC starten, da diese dem Eigentümer gehört. Außerdem können Teilnehmer keine Ressourcen mit Sicherheitsgruppen starten, die anderen Teilnehmern oder dem Eigentümer gehören.
+ In einem gemeinsam genutzten Subnetz kontrollieren der Teilnehmer und der Eigentümer die Sicherheitsgruppen innerhalb des jeweiligen Kontos separat. Der Subnetzbesitzer kann von den Teilnehmern erstellte Sicherheitsgruppen zwar anzeigen, jedoch keine Aktionen bei diesen durchführen. Wenn der Subnetzbesitzer diese Sicherheitsgruppen entfernen oder ändern möchte, muss der Teilnehmer, der die Sicherheitsgruppe erstellt hat, die Aktion durchführen.
+ Wenn ein Cluster von einem Teilnehmer erstellt wird, gelten die folgenden Überlegungen:
+ Die Cluster-IAM-Rolle und die Knoten-IAM-Rollen müssen in diesem Konto erstellt werden. Weitere Informationen erhalten Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md) und [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md).
+ Alle Knoten müssen vom selben Teilnehmer erstellt werden, einschließlich verwalteter Knotengruppen.
+ Der Eigentümer einer gemeinsam genutzten VPC kann einen Cluster, den ein Teilnehmer im gemeinsam genutzten Subnetz erstellt, nicht anzeigen, aktualisieren oder löschen. Dies gilt zusätzlich zu den VPC-Ressourcen, auf die jedes Konto unterschiedlich zugreifen kann. Weitere Informationen finden Sie unter [Verantwortlichkeiten und Berechtigungen für Besitzer und Teilnehmer](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) im *Amazon-VPC-Benutzerhandbuch*.
+ Wenn Sie das Feature für das *benutzerdefinierte Netzwerk* des Amazon-VPC-CNI-Plugins für Kubernetes verwenden, müssen Sie die im Eigentümerkonto aufgeführten Zuordnungen der Availability-Zone-IDs verwenden, um jede `ENIConfig` zu erstellen. Weitere Informationen finden Sie unter [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md).
Weitere Informationen zur Freigabe von VPC-Subnetzen finden Sie unter [Freigeben Ihrer VPC für andere Konten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) im *Amazon-VPC-Benutzerhandbuch*.