本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
IPv6 模式下的 EKS 解決了 IPv4 耗盡挑戰，通常出現在大規模 EKS 叢集中。EKS 對 IPv6 的支援專注於解決 IPv4 耗盡問題，這源自於 IPv4 地址空間的大小有限。這是許多客戶提出的重大考量，與 Kubernetes IPv4/IPv6 雙堆疊
在 IPv6 EKS 叢集中，Pod 和服務將接收 IPv6 地址，同時保持與舊版 IPv4 端點的相容性。這包括外部 IPv4 端點存取叢集內服務的能力，以及 Pod 存取外部 IPv4 端點的能力。
Amazon EKS IPv6 支援會利用原生 VPC IPv6 功能。每個 VPC 配置 IPv4 地址字首 (CIDR 區塊大小可以是 /16 到 /28)，以及來自 Amazon GUA （全球單點傳送地址） 內唯一的 /56 IPv6 地址字首 （固定）；您可以將 /64 地址字首指派給 VPC 中的每個子網路。IPv4 功能，例如路由表、網路存取控制清單、對等和 DNS 解析，在啟用 IPv6 的 VPC 中以相同方式運作。然後，VPC 稱為雙堆疊 VPC，遵循雙堆疊子網路，下圖說明支援 EKS/IPV4IPv6IPv6 VPC 基礎模式：
在 IPv6 世界中，每個地址都是網際網路路由。根據預設，VPC 會從公有 GUA 範圍配置 IPv6 CIDR。不過，自 2024 年 8 月
下圖說明 EKS/IPv6 叢集內的 Pod IPv6 網際網路輸出流程：IPv6
您可以在 VPC 使用者指南中找到實作 IPv6 子網路的最佳實務。
在 IPv6 EKS 叢集中，節點和 Pod 會收到公有 IPv6 地址。EKS 會根據唯一本機 IPv6 單點傳送地址 (ULA) 將 IPv6 地址指派給服務。IPv6 叢集的 ULA 服務 CIDR 會在叢集建立階段自動指派，而且無法指定，與 IPv4 不同。下圖說明以 EKS/IPv6 為基礎的叢集控制平面資料計劃基礎模式：
概觀
EKS/IPv6 僅支援字首模式 (VPC-CNI 外掛程式 ENI IP 指派模式）。進一步了解字首模式。
字首指派僅適用於 Nitro 型 EC2 執行個體，因此只有在叢集資料平面使用 EC2 Nitro 型執行個體時，才支援 EKS/IPv6。
簡單來說，IPv6 字首 /80 （每個工作者節點） 會產生 ~10^14 個 IPv6 地址，限制因素將不再是 IPs而是 Pod 密度 （依資源）。
IPv6 字首指派只會在 EKS 工作者節點引導時間進行。此行為已知可以緩解高 Pod 流失 EKS/IPv4 叢集經常因 VPC CNI 外掛程式 (ipamd) 產生的限流 API 呼叫而延遲 Pod 排程的情況，旨在及時配置私有 IPv4 地址。也已知會使 VPC-CNI 外掛程式進階旋鈕不需要調校 WARM_IP/ENI、MINimUM_IP
下圖放大 IPv6 工作者節點彈性網路界面 (ENI)：
每個 EKS 工作者節點都會指派 IPv4 和 IPv6 地址，以及對應的 DNS 項目。對於指定的工作者節點，只會使用來自雙堆疊子網路的單一 IPv4 地址。IPv6 的 EKS 支援可讓您透過高度評價的輸出限定 IPv4 模型與 IPv4 端點 (AWS、內部部署、網際網路） 通訊。EKS 實作主機本機 CNI 外掛程式，次要於 VPC CNI 外掛程式，它會配置和設定 Pod 的 IPv4 地址。CNI 外掛程式為 169.254.172.0/22 範圍的 Pod 設定主機特定的不可路由 IPv4 地址。指派給 Pod 的 IPv4 地址對 worker-node 是唯一的，不會在 worker-node 之外公告。 169.254.172.0/22 提供最多 1024 個唯一 IPv4 地址，可支援大型執行個體類型。
下圖說明連接至叢集邊界 （非網際網路） 外 IPv4 端點的 IPvIPv6 Pod 流程：
在上圖中，Pod 將對端點執行 DNS 查詢，並在收到 IPv4 "A" 回應時，Pod 的節點限定唯一 IPv4 地址會透過來源網路位址轉譯 (SNAT) 轉譯為連接到 EC2 工作者節點之主要網路界面的私有 IPv4 (VPC) 地址。
EKS/IPv6 Pod 還需要使用公有 IPv4 地址透過網際網路連線至 IPv4 端點，以實現存在類似的流程。下圖說明連接至叢集邊界外 IPv4 端點的 IPv6 Pod 流程 （網際網路可路由）：
在上圖中，Pod 將對端點執行 DNS 查詢，並在收到 IPv4 "A" 回應時，Pod 的節點限定唯一 IPv4 地址會透過來源網路位址轉譯 (SNAT) 轉譯為連接到 EC2 工作者節點之主要網路界面的私有 IPv4 (VPC) 地址。然後，Pod IPv4 地址 （來源 IPv4：EC2 主要 IP) 會路由至 IPv4 NAT 閘道，其中 EC2 主要 IP 會轉譯 (SNAT) 為有效的網際網路可路由 IPv4 公有 IP 地址 (NAT 閘道指派的公有 IP)。
節點之間的任何 Pod-to-Pod 通訊一律使用 IPv6 地址。VPC CNI 會設定 iptables 來處理 IPv6，同時封鎖任何 IPv4 連線。
Kubernetes 服務只會從唯一本機 IPv6 單點傳送地址 (ULA) 接收 IPv6 地址 (ClusterIP)。 IPv6
使用 AWS 負載平衡器將服務公開至網際網路。負載平衡器會接收公有 IPv4 和 IPv6 地址，即 a.k.a 雙堆疊負載平衡器。對於存取 IPv6 叢集 kubernetes 服務的 IPv4 用戶端，負載平衡器會執行 IPv4 到 IPv6 轉譯。
Amazon EKS 建議在私有子網路中執行工作者節點和 Pod。您可以在公有子網路中建立公有負載平衡器，以平衡私有子網路中節點上執行之 Pod 的流量。下圖說明存取 EKS/IPv6 傳入型服務的網際網路 IPv4 使用者：
注意
上述模式需要部署最新版本
EKS 控制平面資料平面通訊
EKS 將以雙堆疊模式 (IPv4/IPv6) 佈建跨帳戶 ENIs (X-ENIs)。kubelet 和 kube-proxy 等 Kubernetes 節點元件已設定為支援雙堆疊。Kubelet 和 kube-proxy 在 hostNetwork 模式下執行，並繫結至連接至節點主要網路界面的 IPv4 和 IPv6 地址。Kubernetes api-server 透過以 IPv6 為基礎的 X-ENIs 與 Pod 和節點元件通訊。Pod 透過 X-ENIs 與 api-server 通訊，而 Pod 與 api-server 通訊一律使用 IPv6 模式。
建議
根據運算資源排程
單一 IPv6 字首足以在單一節點上執行許多 Pod。這也會有效地移除節點上 Pod 數目上限的 ENI 和 IP 限制。雖然 IPv6 會移除對 max-Pod 的直接相依性，但使用具有 m5.large 等較小執行個體類型的字首附件時，您可能會在耗盡執行個體的 IP 地址之前就耗盡執行個體的 CPU 和記憶體資源。如果您使用自我管理節點群組或具有自訂 AMI ID 的受管節點群組，則必須手動設定 EKS 建議的 Pod 值上限。
您可以使用下列公式來判斷可在 IPv6 EKS 叢集節點上部署的 Pod 數量上限。
((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)
受管節點群組會自動為您計算 Pod 的數量上限。避免變更最大 Pod 數量的 EKS 建議值，以避免由於資源限制而導致 Pod 排程失敗。
評估現有自訂聯網的目的
如果目前已啟用自訂聯網
EKS/IPv6 叢集中的 Fargate Pod
EKS 支援在 Fargate 上執行之 Pod 的 IPv6。在 Fargate 上執行的 Pod 將使用從 VPC CIDR 範圍 (IPv4IPv6) 雕刻的 IPv6 和 VPC 可路由私有 IPv4 地址。簡單來說，EKS/Fargate Pods 叢集寬密度將限制為可用的 IPv4 和 IPv6 地址。建議調整雙堆疊子網路/VPC CIDRs的大小，以供未來成長使用。如果基礎子網路不包含可用的 IPv4 地址，無論 IPv6 可用的地址為何，您將無法排程新的 Fargate Pod。
部署 AWS Load Balancer 控制器 (LBC)
上游樹狀內 Kubernetes 服務控制器不支援 IPv6。建議使用最新版本"alb.ingress.kubernetes.io/ip-address-type: dualstack" 和 "alb.ingress.kubernetes.io/target-type: ip"
AWS Network Load Balancer 不支援雙堆疊 UDP 通訊協定地址類型。如果您對低延遲、即時串流、線上遊戲和 IoT 有強烈的需求，建議您執行 IPv4 叢集。若要進一步了解如何管理 UDP 服務的運作狀態檢查，請參閱「如何將 UDP 流量路由至 Kubernetes」
