Azure Kubernetes 服务 （AKS） 中的 Azure CNI 覆盖网络概述

Azure CNI 覆盖是 Azure Kubernetes 服务（AKS）的网络模型，可提供高效的 IP 地址管理和高性能 Pod 通信。 本文概述了 Azure CNI 覆盖，包括其体系结构、IP 地址规划和传统 kubenet 网络模型之间的差异。

Azure CNI 覆盖网络的工作原理

平面Azure容器网络接口（CNI）模型为每个 Pod 分配虚拟网络 IP 地址。 Azure CNI Pod 子网会从专门为 Pod 预留的独立子网中为 Pod 分配 IP 地址。 Azure CNI 节点子网（旧版）从节点子网中分配 Pod IP 地址。 这些平面网络选项需要虚拟网络 IP 地址规划，并可能导致地址耗尽，这会导致随着应用程序需求的增长而难以缩放群集。

在覆盖网络中，只有 Kubernetes 集群的节点被分配来自子网的 IP 地址。 Pod 从集群创建时提供的专用无类域间路由（CIDR）范围接收 IP 地址。 每个节点获取一个从同一 CIDR 中划分出来的 /24 地址空间。 横向扩展群集时创建的额外节点会自动从同一 CIDR 获得 /24 地址空间。 Azure CNI 从此 /24 空间将 IP 分配到 Pod。

在 Azure 网络堆栈中为 Pod 的专用 CIDR 空间创建单独的路由域。 此域为 Pod 之间的直接通信创建覆盖网络。 无需在群集子网上预配自定义路由，也无需使用封装方法实现流量隧道，从而在 Pod 之间提供与虚拟网络中的虚拟机（VM）相媲美的连接性能。 Pod 中运行的工作负载甚至不知道网络地址转换正在发生。

与群集外部终结点（如本地部署网络和对等互连虚拟网络）通信时，通过网络地址转换（NAT）使用节点IP。 Azure CNI 会将流量的源 IP（Pod 的覆盖 IP）转换为节点 VM 的主 IP 地址。 此转换使 Azure 网络堆栈能够将流量路由到目标。

群集外部的终结点无法直接连接到 Pod。 若要使应用程序可访问，请通过 Kubernetes 服务或应用程序路由层（例如 LoadBalancer 服务或入口控制器）公开应用程序。 有关详细信息，请参阅 规划 AKS 的应用程序网络。

可以使用 标准负载均衡器 或 托管 NAT 网关为 Overlay Pod 提供到 Internet 的出站连接。 还可以通过 群集子网上的用户定义的路由将其定向到防火墙来控制出口流量。

可以使用入口控制器（例如用于容器的应用程序网关、NGINX 或应用程序路由加载项）配置到群集的入口连接。

kubenet 与 Azure CNI 覆盖之间的差异

与 Azure CNI Overlay 覆盖网络类似，kubenet 从逻辑上与虚拟网络不同的地址空间中为 Pod 分配 IP 地址，但其存在扩展性和其他限制。 下表提供了 kubenet 与 Azure CNI 覆盖之间的详细比较：

最大节点和每个节点 Pod 值是独立的限制。 不要将它们相乘来确定集群支持的 Pod 总容量。 规划群集规模时，请查看 AKS 服务配额和限制 以及 大型群集可伸缩性指南。 控制平面层、工作负荷行为和其他服务限制会影响可实现的规模。

由 Cilium 提供支持的 Azure CNI 采用 eBPF 数据平面，并内置 Cilium 网络策略实施功能。 借助 Azure iptables 数据平面，可以使用 Calico 或 Azure NPM，但截至 2026 年 9 月 30 日，Windows节点上不再支持 Azure NPM，Linux 节点上的支持将于 2028 年 9 月 30 日结束。 有关当前建议和迁移指南，请参阅 AKS 中的网络策略选项。

IP 地址规划

以下部分提供有关如何规划 Azure CNI 覆盖的 IP 地址空间的指导。

群集节点

设置 Azure CNI Overlay AKS 群集时，请确保虚拟网络子网有足够的空间，以便为将来的扩展预留容量。 可以将每个节点池分配到专用子网。 子网包含 256 个 /24 IP 地址。 Azure保留前四个和最后一个 IP 地址，留下 251 个可用地址。 确定子网大小时，还要为升级、扩缩容操作以及子网中的其他资源预留地址空间。

Pod

Azure CNI Overlay 分配的大小是固定的，无法增加或减少。 最多可在一个节点上运行 250 个 Pod。 规划 Pod 地址空间时，请确保专用 CIDR 足够大，以便为新节点提供 /24 地址空间，以支持将来的群集扩展。

规划 Pod 的 IP 地址空间时，请考虑以下因素：

• 可以在同一虚拟网络中的多个独立 AKS 群集上使用同一 Pod CIDR 空间。
• Pod CIDR 空间不得与群集子网范围重叠。
• Pod CIDR 空间不得与直接连接的网络（如虚拟网络对等互连、Azure ExpressRoute 或 VPN）重叠。 如果外部流量的源 IP 在 Pod 的 CIDR 范围内，则需要通过源网络地址转换（SNAT）将其转换为一个非重叠的 IP，以便与集群通信。
• 在仅包含 Linux 节点的 Azure CNI Overlay 群集中，可以将 Pod CIDR 扩展到包含原始范围的、更大的连续超集。 不支持缩小或替换该范围。 扩展也不支持用于 Windows 节点或混合节点场景、IPv6 Pod CIDR，或多个 Pod CIDR 块。

Kubernetes 服务地址范围

服务地址 CIDR 的大小取决于计划创建的群集服务数。 它必须小于 /12。 此范围不应与 Pod CIDR 范围、群集子网范围、对等虚拟网络中的 IP 范围以及本地网络中的 IP 范围重叠。

Kubernetes 的 DNS 服务 IP 地址

DNS 的 IP 地址位于群集服务发现使用的 Kubernetes 服务地址范围内。 请勿在地址范围内使用第一个 IP 地址，因为此地址是用于 kubernetes.default.svc.cluster.local 地址的。

网络安全组

使用 Azure CNI Overlay 的 Pod 到 Pod 流量不封装，并应用子网 网络安全组 (NSG) 的规则。 如果子网 NSG 中包含会影响 Pod CIDR 流量的拒绝规则，请确保制定以下规则来保证群集的正常功能（除所有 AKS 出口要求外）：

从 Pod 流向 Pod CIDR 块之外任意目标的流量，将使用 SNAT 技术把源 IP 地址设置为 Pod 所在节点的 IP。

若要限制群集中工作负荷之间的流量，建议使用 网络策略。

每个节点的最大 Pod 数

创建群集或添加新节点池时，可以配置每个节点的最大 Pod 数。

在创建节点池期间配置的最大 Pod 数的值仅适用于该节点池中的节点。

对于Windows Server容器，建议的最大值为每个节点 110 个 Pod。 此建议值低于 Azure CNI Overlay 可配置的每个节点最多 250 个 Pod 的上限。 有关详细信息，请参阅 AKS 服务配额和限制。

选择网络模型

在以下情况下使用覆盖网络：

• 你想要扩展到大量 Pod，但受限于虚拟网络中的 IP 地址空间。
• 大部分 Pod 通信在群集中进行。
• 不需要高级 AKS 功能，例如虚拟节点。

在以下情况下使用平面网络：

• 有可用的 IP 地址空间。
• 大多数 Pod 通信都与群集外部的资源通信。
• 群集外部的资源需要直接到达 Pod。
• 需要 AKS 高级功能，例如虚拟节点。

Azure CNI 为覆盖网络提供 Azure CNI Overlay，并为平面网络提供 Azure CNI Pod 子网或 Azure CNI 节点子网（旧版）。 有关这些 IP 地址管理选项的详细比较，请参阅 为 AKS 规划 Pod 网络。

Azure CNI 覆盖限制

Azure CNI 覆盖具有以下限制：

• 不支持 VM 可用性集。
• 如果使用自己的子网来部署群集，则子网的名称、虚拟网络和包含虚拟网络的资源组必须为 63 个字符或更少。 这些名称用作 AKS 工作器节点中的标签，因此它们受 标签的 Kubernetes 语法规则的约束。

相关内容

若要开始使用 AKS 中的 Azure CNI 覆盖，请参阅以下文章：

• 在 Azure Kubernetes 服务 (AKS) 中配置 Azure CNI 覆盖网络
• 在 Azure CNI Overlay 的 Azure Kubernetes 服务 (AKS) 群集中扩展 Pod CIDR 空间