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

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

覆盖网络概述

传统的 Azure 容器网络接口 （CNI） 将虚拟网络 （VNet） IP 地址分配给每个 Pod。 它从每个节点上预先保留的 IP 集 或 为 Pod 保留的单独子网分配此 IP 地址。 此方法需要 IP 地址规划，并可能导致地址耗尽，这会导致随着应用程序需求的增长而难以缩放群集。

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

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

通过 NAT，使用节点 IP 与群集外部的终结点（如本地和对等互连 VNet）进行通信。 Azure CNI 将流量的源 IP（Pod 的覆盖 IP）转换为 VM 的主 IP 地址，从而使 Azure 网络堆栈能够将流量路由到目标。 群集外部的终结点无法直接连接到 Pod。 必须将 Pod 的应用程序发布为 Kubernetes 负载均衡器服务，使其可在 VNet 上访问。

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

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

Kubenet 和 Azure CNI 覆盖之间的区别

与 Azure CNI Overlay 一样，kubenet 从与 VNet 逻辑上不同的地址空间中为 Pod 分配 IP 地址，但它存在缩放和其他限制。 下表提供了 Kubenet 和 Azure CNI 覆盖之间的详细对比：

IP 地址规划

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

群集节点

设置 AKS 群集时，请确保 VNet 子网有足够的增长空间，以便于将来缩放。 可以将每个节点池分配到专用子网。 /24 子网最多可容纳 251 个节点，因为前三个 IP 地址保留用于管理任务。

Pod

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

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

• 可以在同一 VNet 中的多个独立 AKS 群集上使用同一 Pod CIDR 空间。
• Pod CIDR 空间不得与群集子网范围重叠。
• Pod CIDR 空间不得与直接连接的网络重叠（如 VNet 对等互连、ExpressRoute 或 VPN）。 如果外部流量的源 IP 在 Pod CIDR 范围内，则需要通过 SNAT 转换为不重叠的 IP，以便与集群进行通信。
• Pod CIDR 空间只能扩展。

Kubernetes 服务地址范围

服务地址 CIDR 的大小取决于计划创建的群集服务的数量。 它必须小于 /12。 此范围不应与对等互连 VNet 和本地网络中使用的 Pod CIDR 范围、群集子网范围和 IP 范围重叠。

Kubernetes DNS 服务 IP 地址

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

网络安全组

未封装使用 Azure CNI 覆盖的 Pod 到 Pod 流量，并应用了子网网络安全组规则。 如果子网 NSG 包含会影响 Pod CIDR 流量的拒绝规则，请确保以下规则到位，以确保除了满足所有 AKS 出口要求之外，群集的功能可以正常运行：

• 所有端口和协议上从节点 CIDR 到节点 CIDR 的流量。
• 所有端口和协议上从节点 CIDR 到 Pod CIDR 的流量（服务流量路由所需的）。
• 所有端口和协议上从 Pod CIDR 到 Pod CIDR 的流量（Pod 到 Pod 和 Pod 到服务流量所需的，包括 DNS）。

从 Pod 到 Pod CIDR 块外部的任何目标的流量将利用 SNAT 将源 IP 设置为运行 Pod 的节点的 IP。

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

每个节点的最大 Pod 数

可以在创建群集时或添加新节点池时配置每个节点的最大 Pod 数。 Azure CNI 覆盖的默认值为 250。 可以在 Azure CNI 覆盖中指定的最大值为 250，最小值为 10。 在节点池创建期间配置的每个节点值的最大 Pod 数值仅适用于该节点池中的节点。

选择网络模型

Azure CNI 为 Pod 提供了两个 IP 寻址选项：将 VNet IP 分配到 Pod 和 覆盖网络的传统配置。 选择用于 AKS 群集的选项时，需要在灵活性与高级配置需求之间进行平衡。 以下注意事项有助于概述每个网络模型何时最合适：

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

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

在以下情况下使用传统 VNet 选项：

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

Azure CNI 覆盖限制

Azure CNI 覆盖具有以下限制：

• 虚拟机可用性集 (VMAS) 不支持覆盖。
• 不能在节点池中使用 DCsv2 系列虚拟机。 为了满足机密计算要求，请考虑改用 DCasv5 或 DCadsv5 系列机密 VM。
• 如果使用自己的子网来部署群集，则包含 VNET 的子网、VNET 和资源组的名称必须为 63 个字符或更少。 这些名称在 AKS 工作器节点中用作标签，因此受 Kubernetes 标签语法规则的约束。

相关内容

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

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