Windows 前缀模式 - Amazon EKS
建议

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

Windows 前缀模式

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

为了提高 Windows 主机上的容器密度，尤其是在使用较小的实例类型时，您可以为 Windows 节点启用前缀委派。启用前缀委派后，将为 ENI 插槽分配 /28 IPv4 前缀，而不是辅助 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保存的前缀数量。

  • warm-prefix-target，即要分配的超出当前需求的前缀数量。

  • warm-ip-target，要分配的超出当前需求的 IP 地址数量。

  • minimum-ip-target，任何时候可用的 IP 地址的最小数量。

  • warm-ip-target and/or minimum-ip-target如果设置则会覆盖warm-prefix-target。

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

为 pod 分配 IP 的过程流程图

图：向 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 分配 /28 IPv4 前缀时，它必须是子网中连续的 IP 地址块。如果生成前缀的子网是碎片化的（具有分散的辅助 IP 地址的高度使用子网），则前缀连接可能会失败，您将看到以下节点事件：

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

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

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

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

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

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

  • 增加集群中的容量，以便新节点能够容纳您的工作负载

  • 启用/禁用 Windows 的前缀委派功能

  • 封锁并耗尽所有现有节点，以安全地驱逐所有现有 Pod。为了防止服务中断，我们建议在生产集群上为关键工作负载实施 Pod 中断预算。

  • 确认 Pod 正在运行后，您可以删除旧的节点和节点组。新节点上的 Pod 将从分配给节点 ENI 的前缀中分配一个 IPv4 地址。

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

  • 启用/禁用 Windows 的前缀委派功能

  • 使用此处提到的步骤更新节点组。其执行的步骤与上述类似，但由 EKS 管理。

警告

以相同模式运行节点上的所有 Pod

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

虽然这不会影响你正在运行的 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 将继续正常运行，并且：

  • 从辅助 IP 模式切换到前缀委派模式时，分配给正在运行的 pod 的辅助 IP 地址不会被释放。前缀将分配给空闲插槽。Pod 终止后，它使用的辅助 IP 和插槽将被释放。

  • 从前缀委托模式切换到辅助 IP 模式时，当其 IPs 范围内的所有前缀都不再分配给 pod 时，将释放前缀。如果将前缀中的任何 IP 分配给 pod，则该前缀将一直保留到 pod 终止。

前缀委派的调试问题

你可以在这里使用我们的调试指南来深入探讨你在Windows上前缀委托所面临的问题。