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
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 ein 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. Seit August 2024
Das folgende Diagramm zeigt einen IPv6 Pod-Internetausgangsfluss innerhalb eines EKS/-Clusters: 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äfix-Modus.
Die Präfixzuweisung funktioniert nur auf Nitro-basierten EC2-Instances. Daher wird EKS/IPv6 nur unterstützt, wenn die Cluster-Datenebene EC2-Nitro-basierte Instances verwendet.
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
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-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-Worker-Knoten angeschlossen ist.
Anmerkung
Das obige Muster muss DNS64 in Subnetzen, in denen EKS/Pods ausgeführt werden, deaktiviert werden. IPv6 Wenn diese Option aktiviert DNS64 ist, gibt der DNS-Resolver eine synthetisierte IPv6 Adresse für IPv4 reine Endpunkte zusammen mit einer Adresse zurück. IPv4 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 dargestellt. Dies kann zu einer unerwarteten Nutzung des NAT-Gateways und den damit verbundenen Kosten führen.
IPv6 EKS/Pods müssen außerdem über öffentliche IPv4 Adressen eine Verbindung zu IPv4 Endpunkten über das Internet herstellen, um einen ähnlichen Datenfluss sicherzustellen. 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-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-Worker-Knoten angeschlossen ist. 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 routbare IPv4 öffentliche Internet-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
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:
Anmerkung
Das obige Muster erfordert die Bereitstellung der neuesten Version
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
Auf Rechenressourcen basierender Zeitplan
Ein einzelnes IPv6 Präfix reicht aus, um viele Pods auf einem einzigen 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
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, die Clusterdichte Ihrer EKS/Fargate Pods wird auf die verfügbaren Adressen beschränkt. IPv4 IPv6 Es wird empfohlen, Ihren Dual-Stack subnets/VPC 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 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 Verwendung der neuesten Version"alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
