Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze

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.

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. 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 Befehlekubectl attach,, kubectl cp kubectl execkubectl logs, und (diese kubectl port-forward Befehle verwenden diekubelet 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 und Muster zur Aufbewahrung routingfähiger IP-Adressen von Amazon EKS VPC in einem Hybridnetzwerk. Weitere Informationen finden Sie auf der Seite Überlegungen zu VPC und Subnetzen 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 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 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.

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.

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 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:

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 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 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. Weitere Informationen finden Sie unter Ändern des öffentlichen IPv4 Adressierungsattributs für Ihr Subnetz und Ändern des IPv6 Adressierungsattributs für Ihr Subnetz im Amazon VPC-Benutzerhandbuch.

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) () oder einem reinen Ausgangsgateway (IPv4IPv6) 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 und AWS Dienste, die sich in integrieren lassen AWS PrivateLink. Eine Liste weiterer Amazon-EKS-Anforderungen finden Sie unter Bereitstellung privater Cluster mit eingeschränktem Internetzugang.

Wenn Sie Load Balancer in einem Subnetz bereitstellen möchten, muss das Subnetz das folgende Tag haben:

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.

Verwaltete Knotengruppen  – 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.

Selbstverwaltete Linux-, Windows- oder Arm-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 oder Zuweisen einer öffentlichen IPv4 Adresse beim Instance-Start.

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:

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 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.