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.
Ausführen von IPv6-EKS-Clustern
EKS im IPv6-Modus löst das Problem der IPv4-Erschöpfung, das häufig in großen EKS-Clustern auftritt. Die Unterstützung von EKS für IPv6 konzentriert sich auf die Lösung des Problems der IPv4-Erschöpfung, das auf die begrenzte Größe des IPv4-Adressraums zurückzuführen ist. Dies ist ein erhebliches Problem, das von einer Reihe unserer Kunden geäußert wurde und sich von der Dual-Stack-Funktion von Kubernetes unterscheidet. IPv4/IPv6
In einem IPv6-EKS-Cluster erhalten Pods und Services IPv6-Adressen und behalten gleichzeitig die Kompatibilität mit älteren IPv4-Endpunkten bei. Dies beinhaltet die Möglichkeit für externe IPv4-Endpunkte, auf Clusterdienste zuzugreifen, und Pods für den Zugriff auf externe IPv4-Endpunkte.
Die IPv6-Unterstützung von Amazon EKS nutzt die nativen VPC-IPv6-Funktionen. Jeder VPC ist mit einem IPv4-Adresspräfix (die CIDR-Blockgröße kann zwischen /16 und /28 liegen) und einem eindeutigen /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-fähigen VPC auf die gleiche Weise. Die VPC wird dann nach Dual-Stack-Subnetzen als Dual-Stack-VPC bezeichnet. Das folgende Diagramm zeigt das IPv4IPv6-VPC-Grundmuster, das basierte Cluster unterstützt: EKS/IPv6
In der IPv6-Welt ist jede Adresse über das Internet routbar. Standardmäßig weist VPC IPv6 CIDR aus dem öffentlichen GUA-Bereich zu. Seit August 2024
Das folgende Diagramm zeigt einen IPv6-Pod-Internetausgangsfluss innerhalb eines Clusters: EKS/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 eindeutigen lokalen IPv6-Unicastadressen (ULA) basieren. Der ULA Service CIDR für einen IPv6-Cluster wird während der Clustererstellungsphase automatisch zugewiesen und kann im Gegensatz zu IPv4 nicht angegeben werden. Das folgende Diagramm zeigt ein auf der Cluster-Steuerungsebene EKS/IPv6 basierendes Grundmuster für den Datenplan:
-Übersicht
EKS/IPv6 wird nur im Präfixmodus (VPC-CNI Plug-in ENI IP-Zuweisungsmodus) unterstützt. Erfahren Sie mehr über den Präfix-Modus.
Die Präfixzuweisung funktioniert nur auf Nitro-based EC2-Instances und EKS/IPv6 wird daher nur unterstützt, wenn die Cluster-Datenebene Nitro-based EC2-Instances verwendet.
In einfachen Worten, ein IPv6-Präfix von /80 (pro Worker-Node) ergibt ~10^14 IPv6-Adressen. Der limitierende Faktor werden nicht mehr IPs sein, sondern die Pod-Dichte (was die Ressourcen angeht).
Die IPv6-Präfixzuweisung erfolgt nur beim Bootstrap-Zeitpunkt des EKS-Worker-Nodes. Es ist bekannt, dass dieses Verhalten Szenarien abmildert, in denen EKS/IPv4 Cluster mit hoher Pod-Abwanderung bei der Pod-Planung aufgrund gedrosselter API-Aufrufe, die vom VPC CNI-Plug-in (ipamd) generiert werden, um private IPv4-Adressen rechtzeitig zuzuweisen, häufig verzögert werden. Es ist auch bekannt, dass die erweiterten Regler des Plug-ins unnötig auf MINIMUM_IP eingestellt werden. VPC-CNI WARM_IP/ENI
Das folgende Diagramm vergrößert die Ansicht eines Elastic Network Interface (ENI) für IPv6-Worker-Nodes:
Jedem EKS-Worker-Knoten werden IPv4- und IPv6-Adressen sowie entsprechende DNS-Einträge zugewiesen. Für einen bestimmten Worker-Knoten 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-Endpunkten (AWS, vor Ort, Internet) über ein äußerst eigenwilliges IPv4-Modell, das nur für ausgehenden Ausgang bestimmt ist. EKS implementiert ein hostlokales CNI-Plugin, das dem VPC-CNI-Plugin zweitrangig ist und eine IPv4-Adresse für einen Pod zuweist und konfiguriert. Das CNI-Plugin konfiguriert eine hostspezifische, nicht routbare IPv4-Adresse für einen Pod aus dem 169.254.172. 0/22 Bereich. 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 stellt bis zu 1024 eindeutige IPv4-Adressen bereit, die große Instance-Typen unterstützen können.
Das folgende Diagramm zeigt den Ablauf eines IPv6-Pods, der eine Verbindung zu einem IPv4-Endpunkt außerhalb der Clustergrenze (kein Internet) herstellt:
Im obigen Diagramm führen Pods eine DNS-Suche nach dem Endpunkt durch. Nach Erhalt einer IPv4-Antwort „A“ wird die eindeutige IPv4-Adresse des Pods, die nur für den Knoten bestimmt ist, durch Source Network Address Translation (SNAT) in die private IPv4-Adresse (VPC) der primären Netzwerkschnittstelle übersetzt, die an den EC2 angeschlossen ist. Worker-node
Anmerkung
Das obige Muster erfordert, dass DNS64 in Subnetzen deaktiviert ist, in denen Pods ausgeführt werden. EKS/IPv6 Wenn DNS64 aktiviert ist, gibt der DNS-Resolver eine synthetisierte IPv6-Adresse für Endgeräte zusammen mit einer IPv4-Adresse zurück. IPv4-only Infolgedessen wird der Datenverkehr über die NAT64-Funktionalität des NAT-Gateways (sofern in der Architektur enthalten) geleitet, anstatt innerhalb der VPC zu bleiben, wie im obigen Muster gezeigt. Dies kann zu einer unerwarteten Nutzung des NAT-Gateways und den damit verbundenen Kosten führen.
EKS/IPv6 Pods müssen außerdem über das Internet über öffentliche IPv4-Adressen eine Verbindung zu IPv4-Endpunkten herstellen, um einen ähnlichen Datenfluss sicherzustellen. Das folgende Diagramm zeigt den Ablauf eines IPv6-Pods, der eine Verbindung zu einem IPv4-Endpunkt außerhalb der Clustergrenze herstellt (über das Internet routbar):
Im obigen Diagramm führen Pods eine DNS-Suche nach dem Endpunkt durch. Nach Erhalt einer IPv4-Antwort „A“ wird die eindeutige IPv4-Adresse des Pods, die nur für den Knoten bestimmt ist, durch Source Network Address Translation (SNAT) in die private IPv4-Adresse (VPC) der primären Netzwerkschnittstelle übersetzt, die an den EC2 angeschlossen ist. Worker-node Die Pod-IPv4-Adresse (Quell-IPv4: EC2 Primary IP) wird dann an das IPv4-NAT-Gateway weitergeleitet, wo die primäre EC2-IP (SNAT) in eine gültige öffentliche IPv4-IP-Adresse (NAT Gateway Assigned Public IP) übersetzt wird (SNAT Gateway Assigned Public IP).
Jegliche Pod-to-Pod Kommunikation zwischen den Knoten verwendet immer eine IPv6-Adresse. VPC CNI konfiguriert iptables so, dass es IPv6 verarbeitet und gleichzeitig alle IPv4-Verbindungen blockiert.
Kubernetes-Dienste erhalten nur IPv6-Adressen (ClusterIP) von Unique Local IPv6
Dienste werden über einen AWS-Load Balancer dem Internet zugänglich gemacht. Der Load Balancer empfängt öffentliche IPv4- und IPv6-Adressen, auch bekannt als Dual-Stack-Load Balancer. Für IPv4-Clients, die auf IPv6-Cluster-Kubernetes-Dienste zugreifen, führt der Load Balancer die Übersetzung von IPv4 in IPv6 durch.
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 Internet-IPv4-Benutzer, der auf einen Ingress-basierten Dienst zugreift: EKS/IPv6
Anmerkung
Das obige Muster erfordert die Bereitstellung der neuesten Version
Kommunikation auf der EKS-Kontrollebene auf der Datenebene
EKS Cross-Account wird ENIs (X-ENIs) im Dual-Stack-Modus (IPv4/IPv6) bereitstellen. 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 sowohl an IPv4- als auch an IPv6-Adressen, die an die primäre Netzwerkschnittstelle eines Knotens angeschlossen sind. Der Kubernetes-API-Server kommuniziert mit Pods und Knotenkomponenten über den ist IPv6-basiert. X-ENIs Pods kommunizieren mit den API-Servern über, und die Pod-zu-API-Server-Kommunikation verwendet immer den X-ENIs IPv6-Modus.
Empfehlungen
Auf Rechenressourcen basierender Zeitplan
Ein einziges 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. IPv6 beseitigt zwar die direkte Abhängigkeit von Max-Pods, 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 dafür 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 IPv6 nicht mehr erforderlich. 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
Fargate-Pods im Cluster EKS/IPv6
EKS unterstützt IPv6 für Pods, die auf Fargate laufen. Pods, die auf Fargate laufen, verwenden IPv6- und VPC Routable Private IPv4-Adressen, die aus den VPC-CIDR-Bereichen () stammen. IPv4IPv6 In einfachen Worten, die Clusterdichte Ihrer EKS/Fargate Pods wird auf die verfügbaren IPv4- und IPv6-Adressen beschränkt. Es wird empfohlen, Ihre subnets/VPC Dual-Stack-CIDRs für future Wachstum zu dimensionieren. Sie können keine neuen Fargate-Pods planen, wenn das zugrunde liegende Subnetz keine verfügbare IPv4-Adresse enthält, unabhängig von den verfügbaren IPv6-Adressen.
Stellen Sie den AWS Load Balancer Controller (LBC) bereit
Der Upstream-In-Tree-Kubernetes-Service-Controller unterstützt IPv6 nicht. Wir empfehlen die Verwendung der neuesten Version"alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
