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.

IPv6 EKS-Cluster ausführen

EKS im IPv6 Modus löst das Problem der IPv4 Erschöpfung, das häufig bei großen EKS-Clustern auftritt. Die Unterstützung von EKS für konzentriert IPv6 sich auf die Lösung des IPv4 Überlastungsproblems, das auf die begrenzte Größe des Adressraums zurückzuführen ist. IPv4 Dies ist ein erhebliches Problem, das von einer Reihe unserer Kunden geäußert wurde und sich von der IPv4 Kubernetes/Dual-Stack-Funktion unterscheidet. IPv6 EKS/ IPv6 wird auch die Flexibilität bieten, Netzwerkgrenzen miteinander zu verbinden und so die Wahrscheinlichkeit von CIDR-Überschneidungen IPv6 CIDRs zu minimieren, wodurch ein zweifaches Problem gelöst wird (In-Cluster, Cross-Cluster). Bei der Bereitstellung von EKS-Clustern im IPv6 Modus (--ip-family ipv6) kann die Aktion nicht rückgängig gemacht werden. In einfachen Worten, die IPv6 EKS-Unterstützung ist für die gesamte Lebensdauer Ihres Clusters aktiviert.

In einem IPv6 EKS-Cluster erhalten Pods und Services IPv6 Adressen und behalten gleichzeitig die Kompatibilität mit älteren IPv4 Endpunkten bei. Dazu gehört die Möglichkeit, dass externe IPv4 Endpunkte auf Dienste innerhalb des Clusters zugreifen können, und Pods auf externe Endpunkte zugreifen können. IPv4

Die Amazon IPv6 EKS-Unterstützung nutzt die nativen VPC-Funktionen IPv6 . Jeder VPC wird mit einem IPv4 Adresspräfix (die CIDR-Blockgröße kann zwischen /16 und /28 liegen) und einem eindeutigen IPv6 /56-Adresspräfix (fest) aus Amazons GUA (Global Unicast Address) zugewiesen. Sie können jedem Subnetz in Ihrer VPC ein /64-Adresspräfix zuweisen. IPv4 Funktionen wie Routentabellen, Network Access Control Lists, Peering und DNS-Auflösung funktionieren in einer IPv6 aktivierten VPC auf die gleiche Weise. Die VPC wird dann als Dual-Stack-VPC bezeichnet. Nach Dual-Stack-Subnetzen zeigt das folgende Diagramm das IPV4 IPv6 VPC-Grundmuster, das EKS/-basierte Cluster unterstützt: IPv6

Auf der IPv6 Welt ist jede Adresse über das Internet routingfähig. Standardmäßig weist VPC IPv6 CIDR aus dem öffentlichen GUA-Bereich zu. VPCs unterstützen nicht die Zuweisung von privaten IPv6 Adressen aus dem ULA (Unique Local Address) -Bereich, wie in RFC 4193 definiert (fd00: :/8 oder fc00: :/8). Dies gilt auch dann, wenn Sie ein CIDR zuweisen möchten, das Ihnen gehört. IPv6 Der ausgehende Internetzugriff aus privaten Subnetzen wird durch die Implementierung eines ausschließlich ausgehenden Internet-Gateways (EIGW) in einer VPC unterstützt, das ausgehenden Verkehr ermöglicht und gleichzeitig den gesamten eingehenden Verkehr blockiert. Das folgende Diagramm zeigt einen ausgehenden Pod-Internetfluss innerhalb eines EKS/-Clusters: IPv6 IPv6

Bewährte Methoden für die Implementierung von IPv6 Subnetzen finden Sie im VPC-Benutzerhandbuch.

In einem IPv6 EKS-Cluster erhalten Knoten und Pods öffentliche IPv6 Adressen. EKS weist Diensten IPv6 Adressen zu, die auf Unique Local IPv6 Unicast Addresses (ULA) basieren. Der ULA Service CIDR für einen IPv6 Cluster wird während der Clustererstellungsphase automatisch zugewiesen und kann im Gegensatz dazu nicht angegeben werden. IPv4 Das folgende Diagramm zeigt ein auf EKS/C IPv6 basierendes Grundmuster für einen Datenplan auf der Cluster-Steuerungsebene:

Übersicht

EKS/ IPv6 wird nur im Präfixmodus unterstützt (VPC-CNI Plug-in, ENI IP-Zuweisungsmodus). Erfahren Sie mehr über den Präfixmodus.

Die Präfixzuweisung funktioniert nur auf Nitro-basierten EC2 Instances, daher IPv6 wird EKS/ nur unterstützt, wenn die Cluster-Datenebene Nitro-basierte Instances verwendet. EC2

In einfachen Worten, ein IPv6 Präfix von /80 (pro Worker-Node) ergibt ~10^14 IPv6 Adressen. Der limitierende Faktor wird nicht mehr die Pod-Dichte sein (was die Ressourcen angeht). IPs

IPv6 Die Präfixzuweisung erfolgt nur beim Bootstrap-Zeitpunkt des EKS-Worker-Nodes. Es ist bekannt, dass dieses Verhalten Szenarien abmildert, in denen IPv4 EKS/Cluster mit hoher Pod-Abwanderung bei der Pod-Planung häufig verzögert werden, da vom VPC CNI-Plug-In (ipamd) gedrosselte API-Aufrufe generiert werden, um private Adressen rechtzeitig zuzuweisen. IPv4 Es ist auch bekannt, dass die fortschrittlichen Regler des VPC-CNI-Plug-ins WARM_IP/ENI und MINIMUM_IP unnötig einstellen.

Das folgende Diagramm vergrößert die Ansicht eines Elastic Network Interface (ENI) für Worker-Nodes: IPv6

Jedem EKS-Worker-Knoten werden IPv6 Adressen IPv4 und entsprechende DNS-Einträge zugewiesen. Für einen bestimmten Worker-Node wird nur eine einzige IPv4 Adresse aus dem Dual-Stack-Subnetz verwendet. Die EKS-Unterstützung für IPv6 ermöglicht Ihnen die Kommunikation mit IPv4 Endgeräten (AWS, vor Ort, Internet) über ein äußerst eigenwilliges Modell, das nur für ausgehenden Datenverkehr konzipiert ist. IPv4 EKS implementiert ein hostlokales CNI-Plugin, das dem VPC-CNI-Plugin zweitrangig ist und eine Adresse für einen Pod zuweist und konfiguriert. IPv4 Das CNI-Plugin konfiguriert eine hostspezifische, nicht routbare Adresse für einen Pod aus dem Bereich 169.254.172.0/22. IPv4 Die dem Pod zugewiesene IPv4 Adresse ist für den Worker-Node eindeutig und wird nicht außerhalb des Worker-Nodes bekannt gegeben. 169.254.172.0/22 bietet bis zu 1024 eindeutige Adressen, die große Instance-Typen unterstützen können. IPv4

Das folgende Diagramm zeigt den Ablauf einer Verbindung eines Pods mit einem IPv6 Endpunkt außerhalb der Cluster-Grenze (kein Internet): IPv4

Im obigen Diagramm führen Pods eine DNS-Suche nach dem Endpunkt durch. Nach Erhalt einer IPv4 „A“ -Antwort wird die eindeutige IPv4 Adresse des Pods, die nur für den Knoten bestimmt ist, durch die Quell-Netzwerkadressübersetzung (SNAT) in die private Adresse IPv4 (VPC) der primären Netzwerkschnittstelle übersetzt, die an den Worker-Node angeschlossen ist. EC2

IPv6 EKS/Pods müssen außerdem über öffentliche IPv4 Adressen eine Verbindung zu IPv4 Endpunkten über das Internet herstellen, um sicherzustellen, dass ein ähnlicher Datenfluss besteht. Das folgende Diagramm zeigt den Ablauf eines IPv6 Pods, der sich mit einem IPv4 Endpunkt außerhalb der Clustergrenze verbindet (über das Internet routingfähig):

Im obigen Diagramm führen Pods eine DNS-Suche nach dem Endpunkt durch. Nach Erhalt einer IPv4 „A“ -Antwort wird die eindeutige IPv4 Adresse des Pods, die nur für den Knoten bestimmt ist, durch die Quell-Netzwerkadressübersetzung (SNAT) in die private Adresse IPv4 (VPC) der primären Netzwerkschnittstelle übersetzt, die an den Worker-Node angeschlossen ist. EC2 Die IPv4 Pod-Adresse (Quelle IPv4: EC2 Primäre IP) wird dann an das IPv4 NAT-Gateway weitergeleitet, wo die EC2 primäre IP (SNAT) in eine gültige, über das Internet routbare IPv4 öffentliche IP-Adresse (NAT Gateway Assigned Public IP) übersetzt wird.

Jegliche Pod-to-Pod Kommunikation zwischen den Knoten verwendet immer eine Adresse. IPv6 VPC CNI konfiguriert iptables so, dass es Verbindungen verarbeitet IPv6 und gleichzeitig blockiert. IPv4

Kubernetes-Dienste erhalten nur IPv6 Adressen (ClusterIP) von Unique Local IPv6 Unicast Addresses (ULA). Der ULA Service CIDR für einen IPv6 Cluster wird bei der Erstellung des EKS-Clusters automatisch zugewiesen und kann nicht geändert werden. Das folgende Diagramm zeigt den Dienstablauf zwischen Pod und Kubernetes:

Dienste werden über einen AWS-Load Balancer dem Internet zugänglich gemacht. Der Load Balancer empfängt öffentliche IPv6 Adressen IPv4 und wird auch als Dual-Stack-Loadbalancer bezeichnet. Bei IPv4 Clients, die auf IPv6 Cluster-Kubernetes-Dienste zugreifen, übernimmt der Load Balancer die Übersetzung. IPv4 IPv6

Amazon EKS empfiehlt, Worker-Knoten und Pods in privaten Subnetzen auszuführen. Sie können in den öffentlichen Subnetzen öffentliche Load Balancer einrichten, die den Datenverkehr auf Pods ausgleichen, die auf Knoten in privaten Subnetzen ausgeführt werden. Das folgende Diagramm zeigt einen IPv4 Internetbenutzer, der auf einen IPv6 EKS/Ingress-basierten Dienst zugreift:

Kommunikation auf der EKS-Kontrollebene auf der Datenebene

EKS stellt Cross-account ENIs (X-ENIs) im Dual-Stack-Modus (IPv4/IPv6) bereit. Kubernetes-Knotenkomponenten wie Kubelet und Kube-Proxy sind so konfiguriert, dass sie Dual-Stack unterstützen. Kubelet und Kube-Proxy werden in einem HostNetwork-Modus ausgeführt und binden sich an beide IPv4 und IPv6 an Adressen, die an die primäre Netzwerkschnittstelle eines Knotens angeschlossen sind. Der Kubernetes-API-Server kommuniziert mit Pods und Knotenkomponenten über die X-basierte Schnittstelle. ENIs IPv6 Pods kommunizieren mit den API-Servern über das X-ENIs, und die Pod-zu-API-Server-Kommunikation verwendet immer den Modus. IPv6

Empfehlungen

Behalten Sie den Zugriff auf IPv4 EKS bei APIs

Auf EKS kann IPv4 nur zugegriffen APIs werden. Dazu gehört auch der Cluster-API-Endpunkt. Sie werden nicht in der Lage sein, auf Cluster-Endpunkte zuzugreifen und das IPv6 nur APIs von einem Netzwerk aus. Es ist erforderlich, dass Ihr Netzwerk (1) einen IPv6 Übergangsmechanismus wie NAT64/unterstützt, der DNS64 die Kommunikation zwischen IPv4 Hosts IPv6 und Hosts erleichtert, und (2) einen DNS-Dienst, der Übersetzungen von IPv4 Endpunkten unterstützt.

Auf Rechenressourcen basierender Zeitplan

Ein einzelnes IPv6 Präfix reicht aus, um viele Pods auf einem einzelnen Knoten auszuführen. Dadurch werden auch die ENI- und IP-Beschränkungen für die maximale Anzahl von Pods auf einem Knoten effektiv aufgehoben. Die direkte IPv6 Abhängigkeit von MAX-Pods wird zwar aufgehoben, aber wenn Sie Präfixanhänge mit kleineren Instance-Typen wie m5.large verwenden, werden Sie wahrscheinlich die CPU- und Speicherressourcen der Instance erschöpfen, lange bevor Sie ihre IP-Adressen erschöpfen. Sie müssen den von EKS empfohlenen maximalen Pod-Wert manuell festlegen, wenn Sie selbstverwaltete Knotengruppen oder eine verwaltete Knotengruppe mit einer benutzerdefinierten AMI-ID verwenden.

Sie können die folgende Formel verwenden, um die maximale Anzahl von Pods zu bestimmen, die Sie auf einem Knoten für einen IPv6 EKS-Cluster bereitstellen können.

((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2

((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)

Verwaltete Knotengruppen berechnen automatisch die maximale Anzahl von Pods für Sie. Vermeiden Sie es, den von EKS empfohlenen Wert für die maximale Anzahl von Pods zu ändern, um Fehler bei der Pod-Planung aufgrund von Ressourcenbeschränkungen zu vermeiden.

Evaluieren Sie den Zweck vorhandener benutzerdefinierter Netzwerke

Wenn benutzerdefinierte Netzwerke derzeit aktiviert sind, empfiehlt Amazon EKS, Ihren Bedarf daran mit IPv6 neu zu bewerten. Wenn Sie sich dafür entschieden haben, benutzerdefinierte Netzwerke zu verwenden, um das Problem der IPv4 Erschöpfung zu lösen, ist dies mit nicht mehr erforderlich. IPv6 Wenn Sie benutzerdefinierte Netzwerke verwenden, um eine Sicherheitsanforderung zu erfüllen, z. B. ein separates Netzwerk für Knoten und Pods, sollten Sie eine EKS-Roadmap-Anfrage einreichen.

Fargate-Pods im EKS/Cluster IPv6

EKS unterstützt IPv6 Pods, die auf Fargate laufen. Pods, die auf Fargate laufen, verbrauchen IPv6 und routbare private IPv4 VPC-Adressen, die aus den VPC-CIDR-Bereichen () stammen. IPv4 IPv6 In einfachen Worten, Sie sind EKS/Fargate Pods cluster wide density will be limited to the available IPv4 and IPv6 addresses. It is recommended to size your dual-stack subnets/VPC CIDRs für future Wachstum. Sie können keine neuen Fargate-Pods planen, wenn das zugrunde liegende Subnetz keine verfügbare IPv4 Adresse enthält, unabhängig von den IPv6 verfügbaren Adressen.

Stellen Sie den AWS Load Balancer Controller (LBC) bereit

Der Upstream-In-Tree-Kubernetes-Servicekontroller unterstützt nicht. IPv6 Wir empfehlen, die neueste Version des AWS Load Balancer Controller-Add-ons zu verwenden. Das LBC stellt nur dann eine Dual-Stack-NLB oder eine Dual-Stack-ALB bereit, wenn sie die entsprechende Kubernetes-Service/Ingress-Definition verwendet, die wie folgt annotiert ist: und "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"

AWS Network Load Balancer unterstützt keine Adresstypen für das Dual-Stack-UDP-Protokoll. Wenn Sie hohe Anforderungen an Echtzeit-Streaming, Online-Gaming und IoT mit niedriger Latenz haben, empfehlen wir die Ausführung von IPv4 Clustern. Weitere Informationen zur Verwaltung von Integritätsprüfungen für UDP-Dienste finden Sie unter „So leiten Sie UDP-Verkehr nach Kubernetes weiter“.