本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

适用于 Windows 的前缀模式

在亚马逊 EKS 中，默认情况下，VP C 资源控制器会为在 Windows 主机上运行的每个 Pod 分配一个辅助 IP 地址。此 IP VPC-routable 地址是从主机的子网分配的地址。在 Linux 上，连接到实例的每个 ENI 都有多个插槽，可以由辅助 IP 地址或 /28 CIDR（前缀）填充。但是，Windows 主机仅支持单个 ENI 及其可用插槽。即使有大量可供分配的 IP 地址，仅使用辅助 IP 地址也会人为地限制你可以在 Windows 主机上运行的 pod 的数量。

为了增加 Windows 主机上的 pod 密度，尤其是在使用较小的实例类型时，您可以为 Windows 节点启用前缀委托。启用前缀委派后，/28 IPv4 前缀会分配给 ENI 插槽，而不是辅助 IP 地址。通过将enable-windows-prefix-delegation: "true"条目添加到amazon-vpc-cni配置映射中，可以启用前缀委托。这与配置映射相同，你需要设置enable-windows-ipam: "true"条目才能启用 Windows 支持。

请按照 EKS 用户指南中提及的说明为 Windows 节点启用前缀委派模式。

图：辅助 IP 模式与前缀委派模式的比较

您可以分配给网络接口的最大 IP 地址数取决于实例类型及其大小。分配给网络接口的每个前缀都会占用一个可用插槽。例如，一个c5.large实例对每个网络接口的10插槽数有限制。网络接口上的第一个插槽始终由接口的主 IP 地址占用，剩下的 9 个插槽用于作为 and/or 辅助 IP 地址的前缀。如果为这些插槽分配了前缀，则节点可以支持 (9 * 16) 144 个 IP 地址，而如果为它们分配了辅助 IP 地址，则只能支持 9 个 IP 地址。有关更多信息，请参阅有关每种实例类型的每个网络接口的 IP 地址和为网络接口分配前缀的文档。

在工作节点初始化期间，VPC 资源控制器为主 ENI 分配一个或多个前缀，以便通过维护 IP 地址的热池来更快地启动 Pod。通过在配置图中设置以下配置参数，可以控制在温水池中amazon-vpc-cni保存的前缀数量。

随着节点上调度了更多 Pod，将为现有 ENI 请求额外的前缀。当 Pod 调度到节点上时，VPC 资源控制器将首先尝试从节点上的现有前缀中分配 IPv4 地址。如果不可能，则只要子网具有所需的容量，就会请求新的 IPv4 前缀。

图：为 Pod 分配 IPv4 地址期间的工作流程

建议

在以下情况下使用前缀委托

如果你在工作节点上遇到 Pod 密度问题，请使用前缀委托。为避免错误，我们建议在迁移到前缀模式之前，检查子网中是否有 /28 前缀的连续地址块。有关子网预留的详细信息，请参阅 “使用子网预留避免子网分段 (IPv4)” 部分。

默认情况下，Windows 节点max-pods上的设置为110。对于绝大多数实例类型来说，这应该足够了。如果您想增加或减少此限制，请在用户数据中的 bootstrap 命令中添加以下内容：

-KubeletExtraArgs '--max-pods=example-value'

有关 Windows 节点的引导配置参数的更多详细信息，请访问此处的文档。

在以下情况下避免前缀委托

如果您的子网非常分散，可用的 IP 地址不足以创建 /28 前缀，请避免使用前缀模式。如果生成前缀的子网是分段的（频繁使用的子网，辅助 IP 地址分散），则前缀连接可能会失败。通过创建新子网和保留前缀可以避免此问题。

为前缀委派配置参数以保存 IPv4 地址

warm-prefix-targetwarm-ip-target、和minimum-ip-target可用于微调带有前缀的预缩放和动态缩放的行为。默认情况下，使用以下值：

warm-ip-target: "1"
minimum-ip-target: "3"

通过微调这些配置参数，你可以在保存 IP 地址和确保减少因分配 IP 地址而导致的 Pod 延迟之间实现最佳平衡。有关这些配置参数的更多信息，请访问此处的文档。

使用子网预留来避免子网分段 (IPv4)

当 EC2 为 ENI 分配 /28 IPv4 前缀时，它必须是子网中连续的 IP 地址块。如果生成前缀的子网是分段的（具有分散的辅助 IP 地址的高度使用的子网），则前缀连接可能会失败，并且您将看到以下节点事件：

InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

为避免分段并有足够的连续空间来创建前缀，请使用 VPC 子网 CIDR 预留在子网内预留 IP 空间以供前缀专用。创建预留后，预留区块中的 IP 地址将不会分配给其他资源。这样，VPC 资源控制器将能够在对节点 ENI 的分配调用期间获得可用的前缀。

建议创建一个新子网，为前缀预留空间，并为在该子网中运行的工作节点启用前缀分配。如果新子网仅供在 EKS 集群中运行且启用了前缀委派的 Pod 专用，则可以跳过前缀预留步骤。

从辅助 IP 模式迁移到前缀委派模式时替换所有节点，反之亦然

强烈建议您创建新的节点组以增加可用 IP 地址的数量，而不是滚动替换现有的工作节点。

使用自管理节点组时，过渡步骤将是：

使用托管节点组时，过渡步骤将是：

对于 Windows，我们建议你避免同时在辅助 IP 模式和前缀委托模式下运行 Pod。当你从辅助 IP 模式迁移到前缀委托模式时，可能会出现这种情况，反之亦然，运行Windows工作负载。

虽然这不会影响你正在运行的 Pod，但节点的 IP 地址容量可能存在不一致。例如，假设一个 t3.xlarge 节点有 14 个二级 IPv4 地址插槽。如果你运行 10 个 Pod，那么 ENI 上的 10 个插槽将被辅助 IP 地址占用。启用前缀委托后，向 kube-API 服务器通告的容量将是（14 个插槽 * 每个前缀 16 个 IP 地址）244，但当时的实际容量将是（剩余 4 个插槽 * 每个前缀 16 个地址）64。如果您运行的 Pod 多于可供分配的 IP 地址，则公布的容量与实际容量（剩余插槽）之间的这种不一致可能会导致问题。

话虽如此，你可以使用上面描述的迁移策略来安全地将你的 Pod 从辅助 IP 地址过渡到从前缀获得的地址。在模式之间切换时，Pod 将继续正常运行并且：

前缀委派的调试问题

你可以使用此处的调试指南来深入探讨你在Windows上面临的前缀委派问题。