Überlegungen zu Cluster-VPC und Subnetzen - Amazon EKS

Überlegungen zu Cluster-VPC und Subnetzen

Amazon EKS empfiehlt, einen Cluster in einer VPC mit öffentlichen und privaten Subnetzen auszuführen, damit Kubernetes öffentliche Load Balancer in den öffentlichen Subnetzen erstellen kann, die den Datenverkehr auf Pods ausgleichen, die auf Knoten in privaten Subnetzen laufen. Diese Konfiguration ist jedoch nicht erforderlich. Sie können einen Cluster in einer VPC nur mit privaten oder nur mit öffentlichen Subnetzen ausführen, abhängig von Ihren Netzwerk- und Sicherheitsanforderungen. Weitere Informationen zu Clustern, die in einer VPC nur mit privaten Subnetzen bereitgestellt werden, finden Sie unter Private Cluster.

Wenn Sie einen Amazon EKS-Cluster erstellen, geben Sie die VPC-Subnetze an, in denen Amazon EKS Elastic-Network-Schnittstellen platzieren kann. Amazon EKS erfordert Subnetze in mindestens zwei Availability Zones und erstellt bis zu vier Netzwerkschnittstellen über diese Subnetze, um die Kommunikation auf der Steuerebene mit Ihren Knoten zu erleichtern. Dieser Kommunikationskanal unterstützt Kubernetes-Funktionalität, z. B. kubectl exec und kubectl logs. Die von Amazon EKS erstellte Cluster-Sicherheitsgruppe und alle zusätzlichen Sicherheitsgruppen, die Sie beim Erstellen Ihres Clusters angeben, werden auf diese Netzwerkschnittstellen angewendet. Jede von Amazon EKS erstellte Netzwerkschnittstelle enthält Amazon-EKS cluster name in ihrer Beschreibung.

Stellen Sie sicher, dass die Subnetze, die Sie während der Clustererstellung angeben, über genügend verfügbare IP-Adressen für die von Amazon EKS erstellten Netzwerkschnittstellen verfügen. Wenn Sie einen Cluster bereitstellen, der die IPv4-Familie verwendet, empfehlen wir, kleine (/28), dedizierte Subnetze für von Amazon EKS erstellte Netzwerkschnittstellen zu erstellen und diese Subnetze nur als Teil der Clustererstellung anzugeben. Andere Ressourcen, z. B. Knoten und Lastenverteilung, sollten in separaten Subnetzen von den Subnetzen gestartet werden, die während der Clustererstellung angegeben wurden.

Wichtig
  • Knoten und Lastenverteilung können in jedem Subnetz in der VPC Ihres Clusters gestartet werden, einschließlich Subnetze, die während der Clustererstellung nicht bei Amazon EKS registriert wurden. Subnetze erfordern keine Tags für Knoten. Damit die automatische Erkennung des Kubernetes-Lastenverteilung funktioniert, müssen Subnetze wie in beschrieben mit Tags versehen werden Subnetz-Markierung.

  • Subnetze, die Ihrem Cluster zugeordnet sind, können nach der Clustererstellung nicht mehr geändert werden. Wenn Sie genau steuern müssen, in welchen Subnetzen die von Amazon EKS erstellten Netzwerkschnittstellen platziert werden, geben Sie bei der Clustererstellung nur zwei Subnetze an, jedes in einer anderen Availability Zone.

  • Wählen Sie beim Erstellen Ihres Clusters kein Subnetz in AWS Outposts, AWS Wavelength oder einer Lokalen AWS-Zone aus.

  • Cluster, die mit Version v1.14 oder früher erstellt wurden, enthalten ein kubernetes.io/cluster/cluster-name Tag auf Ihrer VPC. Dieses Tag wurde nur von Amazon EKS verwendet und kann sicher entfernt werden.

  • Es kann bis zu fünf Stunden dauern, bis ein aktualisierter Bereich angezeigt wird, der durch das Hinzufügen von CIDR-Blöcken zu einem vorhandenen Cluster verursacht wurde.

  • Wenn Sie möchten, dass Kubernetes Pods und Services IPv6-Adressen zuweist, müssen Sie Ihrer VPC und Ihren Subnetzen IPv4- und IPv6-CIDR-Blöcke zugewiesen haben. Weitere Informationen finden Sie unter Zuordnen eines IPv6-CIDR-Blocks zu Ihrer VPC im Amazon-VPC-Benutzerhandbuch. Ihre Routing-Tabellen und Sicherheitsgruppen müssen ebenfalls IPv6-Adressen enthalten. Weitere Informationen finden Sie unter Migrieren zu IPv6 im Amazon VPC-Benutzerhandbuch.

  • Knoten müssen in der Lage sein, mit der Steuerungsebene und anderen AWS-Services zu kommunizieren. Wenn Ihre Knoten in einem privaten Subnetz bereitgestellt werden und Sie möchten, dass Pods ausgehenden Internetzugang haben, muss das Subnetz eine der folgenden Anforderungen erfüllen:

    • Subnetze mit nur IPv4 CIDR-Blöcken müssen eine Standardroute zu einem NAT-Gateway haben. Dem NAT-Gateway muss eine öffentliche IPv4-Adresse zugewiesen werden, um den Knoten den Internetzugriff zu ermöglichen.

      Subnetze mit nur IPv6-CIDR-Blöcken müssen eine Standardroute zu einem Internet-Gateway mit nur ausgehendem Internet-Gateway haben.

    • Ist mit den notwendigen Einstellungen und Voraussetzungen in konfiguriert Private Cluster.

Ihre VPC muss Unterstützung für DNS-Hostnamen und DNS-Auflösung haben oder Ihre Knoten können sich nicht bei Ihrem Cluster registrieren. Weitere Informationen finden Sie unter Verwendung von DNS in Ihrer VPC im Amazon VPC Benutzerhandbuch.

VPC-IP-Adressierung

Wenn Sie möchten, dass Pods, die auf Knoten in öffentlichen Subnetzen bereitgestellt werden, über ausgehenden Internetzugang verfügen, müssen Ihre öffentlichen Subnetze so konfiguriert sein, dass sie öffentliche IPv4-Adressen oder IPv6-Adressen automatisch zuweisen. Stellen Sie mit dem folgenden Befehl fest, ob Ihre öffentlichen Subnetze für die automatische Zuweisung öffentlicher IPv4- oder IPv6-Adressen konfiguriert sind. Ersetzen Sie example values durch Ihre eigenen Werte.

IPv4
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=VPC-ID" | grep 'SubnetId\|MapPublicIpOnLaunch'
IPv6
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=VPC-ID" | grep 'SubnetId\|AssignIpv6AddressOnCreation'

Ausgabe

IPv4
"MapPublicIpOnLaunch": true, "SubnetId": "subnet-ID1", "MapPublicIpOnLaunch": false, "SubnetId": "subnet-ID2", ...
IPv6
"SubnetId": "subnet-ID1", "AssignIpv6AddressOnCreation": true, "SubnetId": "subnet-ID2", "AssignIpv6AddressOnCreation": false, ...

Bei allen Subnetzen, in denen MapPublicIpOnLaunch oder AssignIpv6AddressOnCreation auf false eingestellt ist, ändern Sie die Einstellung auf true.

IPv4
aws ec2 modify-subnet-attribute --subnet-id subnet-ID2 --map-public-ip-on-launch
IPv6
aws ec2 modify-subnet-attribute --subnet-id subnet-ID2 --assign-ipv6-address-on-creation
Wichtig

Wenn Sie vor dem 26. März 2020 eine AWS CloudFormation-Vorlage von Amazon EKS zum Bereitstellen Ihrer VPC verwendet haben, müssen Sie die Einstellung für Ihre öffentlichen Subnetze ändern.

Sie können sowohl private (RFC 1918) als auch öffentliche (Nicht-RFC 1918) klassenlose Inter-Domain-Routing (CIDR)-IPv4-Bereiche innerhalb der VPC definieren, die für Ihren Amazon-EKS-Cluster verwendet wird. Weitere Informationen finden Sie unter Hinzufügen von IPv4 CIDR-Blöcken zu einer VPC in Amazon-VPC-Benutzerhandbuch. Stellen Sie bei der Auswahl der CIDR-Blöcke für Ihre VPC und Subnetze sicher, dass die Blöcke genügend IPv4-Adressen für alle Amazon-EC2-Knoten und -Pods enthalten, die Sie bereitstellen möchten. Für jeden Ihrer Pods sollte mindestens eine IP-Adresse vorhanden sein. Sie können die Verwendung von IP-Adressen sparen, indem Sie ein Transit-Gateway mit einer Shared-Services-VPC implementieren. Weitere Informationen finden Sie unter Isolierte VPCs mit gemeinsam genutzten Services und Amazon-EKS-VPC-Routable-IP-Adressspeicherungsmuster in einem Hybridnetzwerk.

Subnetz-Markierung

Für 1.18 und frühere Cluster fügt Amazon EKS das folgende Tag zu allen Subnetzen hinzu, die während der Clustererstellung übergeben werden. Amazon EKS fügt das Tag nicht zu Subnetzen hinzu, die beim Erstellen von 1.19-Clustern übergeben wurden. Falls das Tag in Subnetzen vorhanden ist, die von einem Cluster verwendet werden, der in einer früheren Version als 1.19 erstellt wurde, und Sie den Cluster auf 1.19 aktualisieren, wird das Tag nicht aus den Subnetzen entfernt.

  • Schlüsselkubernetes.io/cluster/cluster-name

  • Wertshared

Sie können dieses Tag optional verwenden, um zu steuern, wo Elastic Load Balancer bereitgestellt werden, zusätzlich zu den erforderlichen Subnetz-Tags für die Verwendung automatisch bereitgestellter Elastic Load Balancer. Weitere Informationen zum Subnetz-Tagging des Load Balancers finden Sie unter Anwendungslastenverteilung auf Amazon EKS und Netzwerklastenausgleich auf Amazon EKS.

Erhöhen Sie die verfügbaren IPv4-Adressen für Ihre VPC

Wenn Ihrer Amazon VPC die IPv4-Adressen ausgehen, können Sie einer vorhandenen VPC ein sekundäres CIDR zuordnen. Weitere Informationen finden Sie unter Hinzufügen von IPv4 CIDR-Blöcken zu einer VPC in Amazon-VPC-Benutzerhandbuch. Mit dem neuen zugeordneten CIDR können Sie Subnetze erstellen, indem Sie eine Teilmenge des neu zugeordneten CIDR verwenden. Nachdem Sie das neue Subnetz oder die neuen Subnetze erstellt haben, können Sie zusätzliche verwaltete oder selbstverwaltete Knotengruppen erstellen, die das neu zugeordnete CIDR und die neu zugeordneten Subnetze verwenden.