Azure 容器网络接口 (CNI) Pod 子网

在 Azure Kubernetes 服务 (AKS) 中，Azure CNI Pod 子网会从独立于群集节点的单独子网中为 Pod 分配 IP 地址。 此功能分为两种模式：动态 IP 分配和静态块分配。

先决条件

• 查看 AKS CNI 网络先决条件。
• 查看 动态 IP 分配 和 静态块分配的配置指南。
• 不支持 AKS 引擎和 DIY 群集。
• 使用Azure CLI版本2.75.0或更高版本配置静态块分配。

动态 IP 分配模式

动态 IP 分配可通过从子网（该子网独立于托管 AKS 群集的子网）分配 Pod IP 来帮助缓解 Pod IP 地址耗尽问题。

动态 IP 分配模式具有以下优势：

• 更高的 IP 利用率：系统会从 Pod 子网中动态向集群 Pod 分配 IP。 与传统的 CNI 解决方案（为每个节点静态分配 IP）相比，此功能可以优化群集中的 IP 利用率。
• 可缩放性和灵活性：可以单独缩放节点和 Pod 子网。 单个 Pod 子网可以在群集的多个节点池之间或在同一 VNet 中部署的多个 AKS 群集之间共享。 你还可以为节点池配置单独的 Pod 子网。
• 高性能：由于为 Pod 分配了 VNet IP，因此它们直接连接到 VNet 中的其他群集 Pod 和资源。
• 用于 Pod 的单独 VNet 策略：由于 Pod 具有单独的子网，因此你可以单独为它们配置不同于节点策略的 VNet 策略。 此方式可以实现许多有用的方案，例如只允许 Pod 而不允许节点连接 Internet，使用 Azure NAT 网关修复节点池中 Pod 的源 IP，以及使用网络规则组 (NSG) 筛选节点池之间的流量。
• Kubernetes 网络策略：对于 Linux 节点池，请使用由 Cilium 提供支持的 CNI Azure。 对于Windows节点池，请使用 Calico。 新订阅无法启用Azure网络策略管理器（NPM）。 Azure NPM 对 Windows 的支持将于 2026 年 9 月 30 日结束，对 Linux 的支持将于 2028 年 9 月 30 日结束。 有关详细信息，请参阅 AKS 中的网络策略。

局限性

• 支持的最大 Pod 子网大小为 /16。 大型群集也可能因 Azure 地址映射限制而受限于大约 65,000 个 Pod。 对于更大规模的场景，请使用静态块分配。
• 具有动态 IP 分配的 Azure CNI Pod 子网与节点自动预配 (NAP)不兼容。
• 当节点没有可用 IP 地址时启动的 Pod 会一直等待，直到节点获得更多地址。 此行为主要影响 Pod 频繁变动的工作负载。 有关详细信息，请参阅 适用于 Pod 频繁变动工作负载的 Pod 启动。

计划 IP 寻址

借助动态 IP 分配，节点和 Pod 可以独立缩放，以便可以单独规划其地址空间。 由于可以将 Pod 子网配置为节点池的粒度，因此你在添加节点池时始终可以添加新的子网。 群集/节点池中的系统 Pod 也会从 Pod 子网中接收 IP，因此需要考虑此行为。

以 16 个为一组将 IP 分配给节点。 规划群集中每个节点至少 16 个 IP 的 Pod 子网 IP 分配，因为节点在启动时会请求 16 个 IP，并会在其已分配额度中未分配的 IP 少于 8 个时再请求另一批 16 个 IP。 如果工作负荷反复创建和删除许多生存期较短的 Pod，请参阅 Pod 启动，了解具有高 Pod 流失的工作负荷。

Kubernetes 服务和 Docker 网桥的 IP 地址规划将保持不变。

具有高 Pod 变动率的工作负荷的 Pod 启动

使用动态 IP 分配，每个节点都会从 Pod 子网中保留一个小的可用 IP 地址池，以便新 Pod 可以在不等待 IP 地址的情况下启动。 节点在空闲地址不足时请求更多地址，当需求下降时，它会将未使用的地址返回到 Pod 子网。

如果工作负荷在同一节点上重复创建和删除许多生存期较短的 Pod，某些 Pod 可能会在启动之前等待 IP 地址。 常见示例包括每分钟或每隔几分钟运行的 CronJobs、CI/CD 构建代理以及批处理或测试作业。 每次运行时，Pod 都可以比节点接收新地址更快地使用节点的空闲 IP 地址。 如果节点在上一次运行之后返回了地址，则此效果更为明显。

当 Pod 等待 IP 地址时：

• Pod 处于 ContainerCreating 状态。
• Pod 的事件显示 FailedCreatePodSandBox，并带有类似于 not enough IPs available ..., waiting on Azure CNS to allocate more 的消息。
• kubelet 会自动重试，Pod 会在节点接收更多 IP 地址后启动。

此行为是预期的。 它仅影响在节点没有免费 IP 地址时启动的 Pod，并且不会影响正在运行的 Pod。 等待通常较短，但在以下情况下可能更长：

• 许多 Pod 同时在同一节点上启动。
• Pod 子网已接近满额。

等待的 Pod 可能不会在节点收到更多 IP 地址后立即启动，因为 kubelet 必须重试 Pod 沙盒创建。 因此，Pod 可以等待的时间长于节点获取地址所需的时间。

若要针对这种行为进行规划：

• 为 Pod 启动留出时间。 不要假定 Pod 在创建后几秒钟内启动。 设置以下值时，请为 Pod 启动预留余量，例如至少 60 秒：
  • activeDeadlineSeconds 用于作业，包括 CronJobs 创建的作业。 此截止时间包括作业的 Pod 等待启动的时间。
  • startingDeadlineSeconds 供使用 concurrencyPolicy: Forbid 的 CronJobs 使用。 如果运行在下一个计划时间点仍在运行，例如，由于其 Pod 等待启动，则下一个运行将延迟启动。 如果错过此截止时间，Kubernetes 则会跳过该次运行。
  • 应用程序和管道中的超时，例如 CI/CD 系统等待构建代理 Pod 启动的时间。 请确保这些超时不会将处于 ContainerCreating 状态的 Pod 视为失败。
• 错开排程。 如果多个 CronJobs 按相同的计划运行，请将它们分散到不同的分钟偏移量，以便它们不会同时启动。
• 将突发流量分布到各节点。 将 拓扑分布约束 与 kubernetes.io/hostname 拓扑键一起使用，以便 Pod 突然大量创建时不会落在单个节点上。
• 调整 Pod 子网的大小，以满足高峰期需求。 规划 Pod 的峰值数量，包括要替换的 Pod 以及每个节点保留的免费地址，而不是平均 Pod 数。 若要跟踪 Pod 子网使用情况，请参阅 监视 IP 子网使用情况。
• 考虑针对高度突发工作负荷的另一个 IP 分配选项。 使用 静态块分配时，每个节点在节点创建时接收其 Pod CIDR 块并保留这些块，因此 Pod 不会在启动时等待 IP 地址。 若要在现有群集中使用它， 请添加一个节点池，该节点池使用具有新 Pod 子网的静态块分配，并在该节点池中运行高变动工作负荷。 对于新群集，Azure CNI Overlay还会从每个节点的本地范围分配 Pod IP 地址。

静态块分配模式

静态块分配通过将 CIDR 块分配给节点而不是单个 IP 来帮助缓解潜在的 Pod 子网大小调整和 Azure 地址映射限制。

静态块分配模式具有以下优势：

• 更好的 IP 可伸缩性：CIDR 块会静态分配到群集节点，并在节点的生存期内一直存在，这与使用传统 CNI 动态分配单个 IP 不同。 这可以启用基于 CIDR 块的路由，并有助于将群集限制从传统的每个群集 65,000 个 Pod 扩展到 100 万个 Pod。 Azure 虚拟网络必须足够大，才能适应群集的规模。
• 灵活性：可以独立缩放节点和 Pod 子网。 单个 Pod 子网可以在群集的多个节点池之间或在同一 VNet 中部署的多个 AKS 群集之间共享。 你还可以为节点池配置单独的 Pod 子网。
• 高性能：由于为 Pod 分配了虚拟网络 IP，因此它们已直接连接到 VNet 中的其他群集 Pod 和资源。
• 用于 Pod 的单独 VNet 策略：由于 Pod 具有单独的子网，因此你可以单独为它们配置不同于节点策略的 VNet 策略。 这样可以实现许多有用的方案，例如只允许 Pod 而不允许节点连接 Internet，使用 Azure NAT 网关修复节点池中 Pod 的源 IP 以及使用 NSG 筛选节点池之间的流量。
• Kubernetes 网络策略：对于 Linux 节点池，请使用由 Cilium 提供支持的 CNI Azure。 对于Windows节点池，请使用 Calico。 新订阅无法启用Azure NPM。 Azure NPM 对 Windows 的支持将于 2026 年 9 月 30 日结束，对 Linux 的支持将于 2028 年 9 月 30 日结束。 有关详细信息，请参阅 AKS 中的网络策略。

局限性

下面是使用 Azure CNI 静态块分配时存在的一些限制：

• 所需的最低 Kubernetes 版本为 1.28。
• 支持的最大子网大小为 x.x.x.x/12 ~ 100 万个 IP。
• Azure CNI Pod 子网不支持Windows Server 2019节点。
• 每个子网只能使用一种操作模式。 如果子网使用静态块分配模式，则不能在同一子网的不同群集或节点池中使用动态 IP 分配模式，反之亦然。
• 不支持就地迁移或现有节点池的更新。 若要将现有群集从动态 IP 分配迁移到静态块分配，请在 新子网上添加静态块分配节点池并移动工作负荷。
• 在分配到节点池中某个节点的所有 CIDR 块中，将选择一个 IP 作为该节点的主 IP。 因此，对于选择 --max-pods 值的网络管理员，可以尝试使用以下计算来最好地满足需求并优化子网中 IP 的使用：

max_pods = (N * 16) - 1，其中 N 为任何正整数和 N> 0

计划 IP 寻址

使用静态块分配，节点和 Pod 可以独立扩展，便于单独规划其地址空间。 由于可以将 Pod 子网配置为节点池的粒度，因此你在添加节点池时始终可以添加新的子网。 群集/节点池中的系统 Pod 也会从 Pod 子网中接收 IP，因此需要考虑此行为。

/28（16 个 IP）CIDR 块将根据节点池的 --max-pods 配置分配到节点，这定义了每个节点的最大 Pod 数量。 在每个节点上，将保留该节点上所有可用 IP 中的 1 个 IP，以便在内部使用。

规划 IP 时，请务必使用以下计算定义 --max-pods 配置：max_pods_per_node = (16 * N) - 1，其中 N 为大于 0 的任何正整数。

不浪费 IP 的理想值要求最大 Pod 值符合上述表达式。

请参阅以下示例情况：

Kubernetes 服务的 IP 地址规划将保持不变。