Amazon EKS: VPC- und Subnetz-Anforderungen und -Überlegungen - Amazon EKS

Amazon EKS: VPC- und Subnetz-Anforderungen und -Überlegungen

Wenn Sie einen Cluster erstellen, geben Sie eine VPC 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 über keine VPC verfügen, die Sie mit Amazon EKS nutzen können, dann können Sie eine mit der von Amazon EKS bereitgestellten AWS CloudFormation-Vorlage erstellen. Wenn Sie einen lokalen oder erweiterten Cluster auf AWS Outposts erstellen, lesen Sie Amazon EKS lokale Cluster-VPC- und Subnetz-Anforderungen und -Überlegungen anstelle dieses Themas.

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. Das ist möglich, indem Sie zusätzliche CIDR-Blöcke (Classless Inter-Domain Routing) mit Ihrer VPC verbinden. Sie können entweder vor oder nach der Erstellung Ihres Clusters private (RFC 1918) und öffentliche (nicht RFC 1918) CIDR-Blöcke mit Ihrer VPC verbinden. Es kann bis zu fünf Stunden dauern, bis ein Cluster einen CIDR-Block, den Sie mit einer VPC verbunden haben, erkennt.

    Sie können bei der Verwendung von IP-Adressen sparen, indem Sie ein Transit-Gateway mit einer Shared-Services-VPC verwenden. Weitere Informationen finden Sie unter Isolierte VPCs mit gemeinsam genutzten Services und Amazon-EKS-VPC-Routable-IP-Adressspeicherungsmuster in einem Hybridnetzwerk.

  • 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 Zuordnen eines IPv6-CIDR-Blocks zu Ihrer VPC im Amazon-VPC-Benutzerhandbuch.

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

  • Diese VPC benötigt ggf. VPC-Endpunkte, die AWS PrivateLink verwenden. Weitere Informationen finden Sie unter Subnetz-Anforderungen und -Überlegungen.

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 in den von Ihnen angegebenen Subnetzen. Diese Netzwerkschnittstellen ermöglichen die Kommunikation zwischen Ihrem Cluster und Ihrer VPC. Die Netzwerkschnittstellen ermöglichen außerdem Kubernetes-Funktionen wie kubectl exec und kubectl logs. 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 nicht mehr ä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.

Die Subnetze, die Sie angeben, wenn Sie einen Cluster erstellen, 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 dürfen sich nicht in AWS Outposts, AWS Wavelength oder einer AWS Local Zone befinden. Wenn Sie sich in Ihrer VPC befinden, können Sie jedoch selbstverwaltete Knoten und Kubernetes-Ressourcen für diese Subnetz-Typen bereitstellen.

  • Die Subnetze müssen eine IP-Adressen-basierte Benennung aufweisen. Die ressourcenbasierte Benennung von Amazon EC2 wird nicht von Amazon EKS unterstützt.

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

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.

  • Die Subnetze müssen eine IP-Adressen-basierte Benennung aufweisen. Die ressourcenbasierte Benennung von Amazon EC2 wird nicht von Amazon EKS unterstützt.

  • Wenn Sie möchten, dass Kubernetes pods und Services IPv6-Adressen zuweist, benötigen Sie einen IPv6-CIDR-Block und einen IPv4-CIDR-Block, 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 eine Amazon-EKSAWS CloudFormation-Vorlage verwendet haben, um Ihre VPC nach dem 26. März 2020 bereitzustellen, 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. Weitere Informationen finden Sie unter Ändern des IPv4-Adressierungsattributs Ihres Subnetzes und Ändern des IPv6-Adressierungsattributs Ihres Subnetzes im Amazon-VPC-Benutzerhandbuch.

  • Wenn das Subnetz, in dem Sie einen Knoten bereitstellen, ein privates Subnetz ist und seine Routing-Tabelle keine Route zu einem NAT-Gerät (Network Address Translation) (IPv4) oder einem Gateway für ausgehenden Datenverkehr (IPv6) enthält, fügen Sie mit AWS PrivateLink VPC-Endpunkte zu Ihrer VPC hinzu. VPC-Endpunkte werden für alle AWS-Services benötigt, mit denen Ihre Knoten und pods kommunizieren müssen. Beispiele sind Amazon ECR, Elastic Load Balancing, Amazon CloudWatch, 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-Services unterstützen VPC-Endpunkte. Weitere Informationen finden Sie unter Was ist AWS PrivateLink? und AWS-Services, die sich mit AWS PrivateLink integrieren lassen. Eine Liste weiterer Amazon-EKS-Anforderungen finden Sie unter Anforderungen an private Cluster.

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

    • Private Subnetze

      Schlüssel Wert
      kubernetes.io/role/internal-elb 1
    • Öffentliche Subnetze

      Schlüssel Wert
      kubernetes.io/role/elb 1

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.

Schlüssel 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. Version 2.1.1 oder früher des AWS Load Balancer Controller benötigt dieses Tag. Wenn Sie eine neuere Version des Load Balancer Controllers verwenden, können Sie das Tag entfernen, ohne Ihre Services zu unterbrechen.

Wenn Sie eine VPC mit eksctl oder mithilfe einer der AWS CloudFormation-VPC-Vorlagen für Amazon EKS 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: