本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 正在运行 IPv6 EKS 集群
IPv6 模式下的 EKS 解决了大规模 EKS 集群中经常出现的 IPv4 精疲力尽挑战。EKS 的支持侧重 IPv6 于解决因 IPv4 地址空间有限而导致的 IPv4 耗尽问题。这是我们的许多客户提出的一个重大问题，与 Kubernetes [IPv4/IPv6 ](https://kubernetes.io/docs/concepts/services-networking/dual-stack/)双栈功能截然不同。EKS/ IPv6 还将提供灵活性来互连网络边界， IPv6 CIDRs 从而最大限度地减少出现 CIDR 重叠的机会，从而解决双重问题（集群内、跨集群）。在 IPv6 模式（--ip-family ipv6）下部署 EKS 集群时，该操作是不可逆的。简而言之，EKS IPv6 支持将在集群的整个生命周期内启用。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/zdXpTT0bZXo?rel=0)
在 IPv6 EKS 集群中，Pod 和服务将接收 IPv6 地址，同时保持与传统 IPv4 终端节点的兼容性。这包括外部 IPv4 终端节点访问集群内服务的能力，以及 Pod 访问外部 IPv4 端点的能力。
Amazon EKS IPv6 支持利用原生 VPC IPv6 功能。每个 VPC 都分配了一个 IPv4 地址前缀（CIDR 块大小可以介于 /16 到 /28 之间）和来自 Amazon GUA（全球单播 IPv6 地址）的唯一 /56 地址前缀（固定）；您可以为 VPC 中的每个子网分配一个 /64 地址前缀。 IPv4 路由表、网络访问控制列表、对等互连和 DNS 解析等功能在 IPv6 启用的 VPC 中的工作方式相同。然后，VPC 被称为双栈 VPC，按照双栈子网，下图描述了支持IPv6 基于 EKS/ 的 IPV4IPv6 集群的 VPC 基础模式：
在 IPv6 世界上，每个地址都可以通过互联网进行路由。默认情况下，VPC 会从公共 GUA 范围内分配 IPv6 CIDR。但是，自 [2024 年 8 月](https://aws.amazon.com/about-aws/whats-new/2024/08/aws-private-ipv6-addressing-vpcs-subnets/)起，您还可以通过 Amazon VPC IP 地址管理器 (IPAM) 为 VPCs 和子网使用私 IPv6 有地址。有关更多信息，请参阅[此 AWS 网络博客文章](https://aws.amazon.com/blogs/networking-and-content-delivery/understanding-ipv6-addressing-on-aws-and-designing-a-scalable-addressing-plan)和 [VPC 文档](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-ipv6-addresses)。
下图描绘了 EK IPv6 S/ 集群内的 Pod IPv6 互联网出口流：
在 [VPC 用户指南](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/IPv6-on-AWS.html)中可以找到实现 IPv6 子网的最佳实践。
在 E IPv6 KS 集群中，节点和 Pod 接收公有 IPv6 地址。EKS 根据唯一的本地 IPv6 单播 IPv6 地址 (ULA) 为服务分配地址。不同的是 IPv4， IPv6 集群的 ULA 服务 CIDR 是在集群创建阶段自动分配的，无法指定。下图描绘了基于 EKS/ 的集群控制平面数据计划IPv6 基础模式：
## 概述
IPv6 仅在前缀模式（VPC-CNI 插件 ENI IP 分配模式）中支持 EKS/。了解有关[前缀模式](prefix-mode-linux.md)的更多信息。
前缀分配仅适用于基于 Nitro的 EC2 实例，因此只有当集群数据平面使用基于 EC2 Nitro的实例时，才支持 EKS/IPv6。
简而言之， IPv6 前缀 /80（每个工作节点）将产生大约 10^14 个 IPv6 地址，限制因素将不再 IPs 是 Pod 密度（资源方面）。
IPv6 前缀分配仅在 EKS 工作节点引导时发生。众所周知，这种行为可以缓解由于旨在及时分配私 IPv4 有地址的 VPC CNI 插件 (ipamd) 生成的 API 调用受限，Pod 流失率高 EKS/ IPv4 集群经常在 Pod 调度中延迟的情况。[https://github.com/aws/amazon-vpc-cni-k8s#warm_ip_target](https://github.com/aws/amazon-vpc-cni-k8s#warm_ip_target)
下图放大了 IPv6 工作节点弹性网络接口 (ENI)：
每个 EKS 工作节点都分配了 IPv4 和 IPv6 地址以及相应的 DNS 条目。对于给定的工作节点，只消耗双栈子网中的一个 IPv4 地址。EKS 对的支持 IPv6 使您能够通过高度自以为是的仅限出口的模式与 IPv4 终端节点（AWS、本地、互联网）进行通信。 IPv4 EKS 实现了一个主机本地 CNI 插件，该插件是 VPC CNI 插件的辅助插件，后者为 Pod 分配和配置地址。 IPv4 CNI 插件为 169.254.172.0/22 范围内的 Pod 配置主机特定的不可路由 IPv4 地址。分配给 Pod IPv4 的地址对工作节点来说是*唯一的，不会在工作节点**之外公*布。169.254.172.0/22 提供多达 1024 个可以支持大型实例类型的唯一地址。 IPv4
下图描绘了 IPv6 Pod 连接到集群边界以外的 IPv4 终端节点（非互联网）的流程：
在上图中，Pod 将对终端节点执行 DNS 查找，在收到 IPv4 “A” 响应后，Pod 的仅限节点的唯一 IPv4 地址通过源网络地址转换 (SNAT) 转换为连接到 EC2 工作节点的主网络接口的私有 IPv4 (VPC) 地址。
**注意**
以上模式需要 DNS64 在运行 EKS/ IPv6 Pod 的子网上禁用。启用后 DNS64 ，DNS 解析器会返回 IPv4仅限终端节点的合成 IPv6 地址和地址。 IPv4 因此，流量会通过 NAT 网关（如果包含在架构中）的 NAT64 功能进行路由，而不是像上面的模式所示停留在 VPC 内。这可能会导致意外的 NAT 网关使用量和相关成本。
EKS/ IPv6 Pod 还需要使用公共 IPv4 地址通过互联网连接到 IPv4 端点，以实现类似的流量。下图描绘了 IPv6 Pod 连接到集群边界之外的 IPv4 终端节点（互联网可路由）的流程：
在上图中，Pod 将对终端节点执行 DNS 查找，在收到 IPv4 “A” 响应后，Pod 的仅限节点的唯一 IPv4 地址通过源网络地址转换 (SNAT) 转换为连接到 EC2 工作节点的主网络接口的私有 IPv4 (VPC) 地址。然后，Pod IPv4 地址（源 IPv4：EC2 主 IP）被路由到 IPv4 NAT 网关，在那里将 EC2 主 IP（SNAT）转换为有效的互联网可路由公有 IP 地址（NAT 网关分配的 IPv4 公有 IP）。
所有跨节点的 Pod-to-Pod通信始终使用 IPv6 地址。VPC CNI 将 iptables 配置为在阻止任何连接的 IPv6 同时进行处理。 IPv4
[Kubernetes 服务将仅接收来自唯一本地单播地址 IPv6 (ULA) 的地址 (clusterIP)。 IPv6 ](https://datatracker.ietf.org/doc/html/rfc4193) IPv6 集群的 ULA 服务 CIDR 是在 EKS 集群创建阶段自动分配的，无法修改。下图描述了 Pod 到 Kubernetes 的服务流程：
使用 AWS 负载均衡器将服务公开到互联网。负载均衡器接收公共 IPv6 地址 IPv4 和地址，也就是双栈负载均衡器。对于访问 IPv6 集群 kubernetes 服务的 IPv4 客户端，负载均衡器会 IPv4 进行转换。 IPv6
Amazon EKS 建议在私有子网中运行工作节点和 Pod。你可以在公有子网中创建公有负载均衡器，对私有子网中节点上运行的 Pod 的流量进行负载均衡。下图描绘了互联网 IPv4 用户访问基于 EKS/In IPv6 gress 的服务：
**注意**
上述模式需要部署[最新版本](https://kubernetes-sigs.github.io/aws-load-balancer-controller)的 AWS 负载均衡器控制器
### EKS 控制平面数据平面通信
EKS 将在双堆栈模式 ENIs (IPv4/ENIs) 下配置跨账户 (X-IPv6)。Kubernetes 节点组件（例如 kubelet 和 kube-proxy）被配置为支持双堆栈。Kubelet 和 kube-proxy 在 HostNetwork 模式下运行， IPv4 并绑定到节点主网络接口 IPv6 的地址。Kubernetes api 服务器通过 X-is 基础与 Pod 和节点组件进行通信。ENIs IPv6 Pod 通过 X-与 api 服务器通信ENIs，而 Pod 到 api 服务器的通信始终使用模式。 IPv6
## 建议
### 基于计算资源的时间安排
单个 IPv6 前缀足以在单个节点上运行多个 Pod。这也有效地消除了对节点上最大 Pod 数量的 ENI 和 IP 限制。尽管 IPv6 消除了对 Max-Pods 的直接依赖，但在使用具有较小实例类型（例如 m5.large）的前缀附件时，您很可能会在耗尽实例的 IP 地址之前很久就耗尽实例的 CPU 和内存资源。如果您使用的是自管理节点组或带有自定义 AMI ID 的托管节点组，则必须手动设置 EKS 建议的最大 Pod 值。
您可以使用以下公式来确定在 E IPv6 KS 集群的节点上可以部署的最大 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 的最大数量。避免更改 EKS 对最大 Pod 数量的建议值，以避免由于资源限制而导致的 Pod 调度失败。
### 评估现有自定义网络的用途
如果当前启用了[自定义联网](https://docs.aws.amazon.com/eks/latest/best-practices/custom-networking.html)，Amazon EKS 建议您使用 IPv6重新评估您的需求。如果您选择使用自定义网络来解决 IPv4 耗尽问题，则不再需要使用 IPv6。如果您使用自定义网络来满足安全要求，例如为节点和 Pod 设置单独的网络，我们建议您提交 [EKS 路线图请求](https://github.com/aws/containers-roadmap/issues)。
### EKS/集群中的 Fargate 吊舱 IPv6
EKS IPv6 支持在 Fargate 上运行的 Pod。在 Fargate 上运行的 Pod 将消耗 IPv6 从 VPC CIDR 范围划分的 VPC 可路由私有 IPv4 地址 ()。IPv4 IPv6简而言之，你 EKS/Fargate 的 Pods 集群的宽密度将仅限于可用 IPv4 和 IPv6 地址。建议调整双堆栈的大小，以 subnets/VPC CIDRs 备将来的增长之需。如果底层子网不包含可用地址，则无论可用 IPv4 地址如何，都无法安排新的 Fargate Pod。 IPv6
### 部署 AWS Load Balancer 控制器 (LBC)
**上游的树内 Kubernetes 服务控制器**不支持。 IPv6我们建议使用[最新版本](https://kubernetes-sigs.github.io/aws-load-balancer-controller)的 AWS Load Balancer Controller 附加组件。LBC 只有在使用带有以下注释的相应的 kub service/ingress ernetes 定义后才会部署双栈 NLB 或双栈 ALB `"alb.ingress.kubernetes.io/ip-address-type: dualstack"` `"alb.ingress.kubernetes.io/target-type: ip"`