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

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

覆盖网络概述

传统的 Azure 容器网络接口（CNI） 为每个 Pod 分配虚拟网络 IP 地址。 它从每个节点上的一组保留 IP 或 为 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。 必须将 Pod 的应用程序发布为 Kubernetes 负载均衡器服务才能在虚拟网络上访问它。

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

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

kubenet 与 Azure CNI 覆盖之间的差异

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

IP 地址规划

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

群集节点

设置 AKS 群集时，请确保虚拟网络子网有足够的空间，以便未来进行扩展。 可以将每个节点池分配到专用子网。 子网最多可容纳 251 个节点，因为前三个 /24 IP 地址是为管理任务保留的。

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，以便与集群通信。
• 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 出口要求外）：

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

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

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

每个节点的最大 Pod 数

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

选择网络模型

Azure CNI 为 Pod 提供了两个 IP 寻址选项： 覆盖网络 和 将虚拟网络 IP 分配到 Pod 的传统配置。 选择用于 AKS 群集的选项时，需要在灵活性与高级配置需求之间进行平衡。 如果每种网络模型似乎都很合适，以下考虑因素可帮助你做出决策：

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

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

在以下情况下使用传统虚拟网络选项：

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

Azure CNI 覆盖限制

Azure CNI 覆盖具有以下限制：

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

相关内容

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

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