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 sich häufig in großen EKS-Clustern zeigt. 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 wichtiges Anliegen, das von einer Reihe unserer Kunden geäußert wurde und sich von der Kubernetes-Dual-Stack-Funktion 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. Dazu gehört auch die Möglichkeit für externe IPv4-Endpunkte, auf Dienste innerhalb des Clusters zuzugreifen, und für Pods, auf externe IPv4-Endpunkte zuzugreifen.
Die Amazon EKS-IPv6-Unterstützung nutzt die nativen VPC-IPv6-Funktionen. Jeder VPC wird mit einem IPv4-Adresspräfix (die CIDR-Blockgröße kann zwischen /16 und /28 liegen) und einem eindeutigen /56-IPv6-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 als Dual-Stack-VPC bezeichnet und folgt Dual-Stack-Subnetzen. 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 können
Das folgende Diagramm zeigt einen Pod-IPv6-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 Unique Local IPv6 Unicast Addresses (ULA) basieren. Der ULA-Dienst-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äfixmodus.
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 ist nicht mehr die IPs, sondern die Pod-Dichte (was die Ressourcen angeht).
Die IPv6-Präfixzuweisung erfolgt nur zum Zeitpunkt des EKS-Worker-Node-Bootstraps. Dieses Verhalten verhindert bekanntermaßen Szenarien, 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 zeitnah zuzuweisen, häufig verzögert werden. Es ist auch bekannt, dass das Plug-in unnötig mit den erweiterten Reglern MINIMUM_IP optimiert wird. VPC-CNI WARM_IP/ENI
Im folgenden Diagramm wird ein Elastic Network Interface (ENI) auf einem IPv6-Worker-Node vergrößert:
Jedem EKS-Worker-Node sind IPv4- und IPv6-Adressen sowie die entsprechenden DNS-Einträge zugewiesen. Für einen bestimmten Worker-Node wird nur eine einzige IPv4-Adresse aus dem Dual-Stack-Subnetz verbraucht. Die EKS-Unterstützung für IPv6 ermöglicht es Ihnen, mit IPv4-Endpunkten (AWS, vor Ort, Internet) über ein IPv4-Modell zu kommunizieren, das nur für ausgehenden Datenverkehr steht. EKS implementiert ein hostlokales CNI-Plugin, das dem VPC-CNI-Plugin untergeordnet 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 von 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 bietet bis zu 1024 eindeutige IPv4-Adressen, 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 (ohne Internet) herstellt:
Im obigen Diagramm führen Pods eine DNS-Suche für den Endpunkt durch. Nach Erhalt einer IPv4-Antwort „A“ wird die eindeutige IPv4-Adresse des Pods, die nur für den Knoten gilt, durch die Quellnetzwerkadressübersetzung (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 Endpunkte zusammen mit einer IPv4-Adresse zurück. IPv4-only Daher 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 damit verbundenen Kosten führen.
EKS/IPv6 Pods müssen außerdem mithilfe öffentlicher IPv4-Adressen über das Internet eine Verbindung zu IPv4-Endpunkten herstellen, um einen ähnlichen Datenfluss zu gewährleisten. Das folgende Diagramm zeigt den Ablauf eines IPv6-Pods, der eine Verbindung zu einem IPv4-Endpunkt außerhalb der Clustergrenze herstellt (per Internet routbar):
Im obigen Diagramm führen Pods eine DNS-Suche für den Endpunkt durch. Nach Erhalt einer IPv4-Antwort „A“ wird die eindeutige IPv4-Adresse des Pods, die nur für den Knoten gilt, durch die Quellnetzwerkadressübersetzung (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: Primäre EC2-IP) wird dann an das IPv4-NAT-Gateway weitergeleitet, wo die primäre EC2-IP (SNAT) in eine gültige, über das Internet routbare öffentliche IPv4-IP-Adresse (NAT Gateway Assigned Public IP) übersetzt wird.
Jede 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 Unicast Addresses (ULA). https://datatracker.ietf.org/doc/html/rfc4193
Dienste werden mithilfe eines AWS-Load Balancers mit dem Internet verbunden. 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 IPv4-IPv6-Übersetzung durch.
Amazon EKS empfiehlt, Worker-Knoten und Pods in privaten Subnetzen auszuführen. Sie können öffentliche Load Balancer in den öffentlichen Subnetzen erstellen, die den Datenverkehr zu Pods, die auf Knoten laufen, die sich in privaten Subnetzen befinden, ausgleichen. 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 Datenebene von EKS Control Plane
EKS Cross-Account stellt 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 im HostNetwork-Modus ausgeführt und binden 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, der auf IPv6 basiert. X-ENIs Pods kommunizieren mit den API-Servern über den, und die Kommunikation zwischen Pod und API-Server verwendet immer den X-ENIs IPv6-Modus.
Empfehlungen
Zeitplan auf der Grundlage von Rechenressourcen
Ein einziges IPv6-Präfix reicht aus, um viele Pods auf einem einzelnen Knoten auszuführen. Dadurch werden auch 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äfix-Anhänge mit kleineren Instance-Typen wie m5.large verwenden, ist es wahrscheinlich, dass Sie 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 ermitteln, 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.
Bewerten Sie den Zweck vorhandener benutzerdefinierter Netzwerke
Wenn benutzerdefinierte Netzwerke derzeit aktiviert sind, empfiehlt Amazon EKS, Ihren Bedarf mit IPv6 neu zu bewerten. Wenn Sie sich dafür entschieden haben, benutzerdefinierte Netzwerke zu verwenden, um das Problem der IPv4-Erschöpfung zu beheben, 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 einreichen.
Fargate-Pods im Cluster EKS/IPv6
EKS unterstützt IPv6 für Pods, die auf Fargate laufen. Pods, die auf Fargate laufen, verbrauchen 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 zukünftiges 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 neueste Version des AWS Load Balancer "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
