Kubernetes 使用容器网络接口 （CNI） 插件来管理 Kubernetes 群集中的网络。 CNIS 负责将 IP 地址分配给 Pod、Pod 之间的网络路由、Kubernetes 服务路由等。
AKS 提供了多个 CNI 插件，可以根据网络要求在群集中使用。
AKS 中的网络模型
为 AKS 群集选择 CNI 插件在很大程度上取决于哪种网络模型最适合你的需求。 每个模型都有自己的优点和缺点，在规划 AKS 群集时应考虑。
AKS 使用两个主要网络模型： 覆盖网络 和 平面网络。
这两种网络模型都有多个受支持的 CNI 插件选项。 模型之间的主要区别在于如何分配 Pod IP 地址以及流量如何离开群集。
覆盖网络
覆盖网络是 Kubernetes 中使用的最常见网络模型。 在覆盖网络中，Pods 被分配来自一个专用、逻辑上独立的 CIDR 的 IP 地址，该 CIDR 与部署 AKS 节点的 Azure VNet 子网分开。 这使其可伸缩性比平面网络模型更简单且通常更好。
在覆盖网络中，Pod 可以直接相互通信。 离开集群的流量会通过源网络地址转换（SNAT）转换为节点的 IP 地址，而入站的 Pod IP 流量则通过某个服务（例如负载均衡器）进行路由。 这意味着 Pod IP 地址在节点的 IP 地址后面“隐藏”。 此方法可减少群集所需的 VNet IP 地址数。
Azure Kubernetes 服务提供以下用于覆盖网络的 CNI 插件：
- Azure CNI Overlay 是在大多数情况下推荐使用的 CNI 插件。
平面网络
与覆盖网络不同，AKS 中的平面网络模型从与 AKS 节点相同的 Azure VNet 中的子网将 IP 地址分配给 Pod。 这意味着离开群集的流量没有经过 SNAT 处理，Pod 的 IP 地址直接暴露给目标网络。 这对于某些方案非常有用，例如需要向外部服务公开 Pod IP 地址时。
Azure Kubernetes 服务为平面网络提供两个 CNI 插件。 本文不会深入介绍每个插件选项。 有关详细信息，请参阅链接的文档：
- Azure CNI Pod 子网，是适用于平面网络场景的推荐 CNI 插件。
- Azure CNI 节点子网（旧版平面网络模型 CNI 通常仅建议在群集 需要 托管 VNet 时使用）。
选择 CNI
选择 CNI 时，需要考虑几个因素。 每个网络模型都有自己的优点和缺点，群集的最佳选择将取决于你的特定要求。
选择网络模型
AKS 中的两个主要网络模型是覆盖和平面网络。
覆盖网络：
- 使用 Pod 的逻辑分隔 CIDR 范围来节省 VNet IP 地址空间。
- 最大群集规模支持。
- 简单的 IP 地址管理。
平面网络：
- Pod 获得完整的 VNet 连接，可以直接通过连接的网络的专用 IP 地址进行访问。
- 需要大型非分段 VNet IP 地址空间。
用例比较
选择网络模型时，请考虑每个 CNI 插件的用例及其使用的网络模型类型：
| CNI 插件 | 网络模型 | 用例要点 |
|---|---|---|
| Azure CNI 覆盖 | 覆盖 | - 最适合 VNET IP 保护 - API 服务器支持的最大节点数 + 每个节点 250 个 Pod - 更简单的配置 - 无法直接从外部访问 Pod IP |
| Azure CNI Pod 子网 | 平坦 | - 可直接从外部访问 Pod - 适用于高效 VNet IP 使用或大型群集缩放支持的模式（预览） |
| Kubenet （旧版） | 覆盖 | - 确定 IP 保护的优先级 - 规模有限 - 手动路由管理 |
| Azure CNI 节点子网（旧版，历史版本） | 平坦 | - 可直接从外部访问 Pod - 更简单的配置 - 扩展性受限 - VNet IP 使用效率低下 |
功能对比
你可能还希望比较每个 CNI 插件的功能。 下表提供了每个 CNI 插件支持的功能的高级比较：
| 功能 / 特点 | Azure CNI 覆盖 | Azure CNI Pod 子网 | Azure CNI 节点子网（旧版） | Kubenet |
|---|---|---|---|---|
| 在现有或新的 VNet 中部署群集 | 已支持 | 已支持 | 已支持 | 支持 - 手动 UDR |
| Pod-VM 与同一 VNet 或对等互连 VNet 中的 VM 的连接 | Pod 已启动 | 这两种方式 | 这两种方式 | Pod 已启动 |
| 通过 VPN/Express Route 进行本地访问 | Pod 已启动 | 这两种方式 | 这两种方式 | Pod 已启动 |
| 访问服务终结点 | 已支持 | 已支持 | 已支持 | 已支持 |
| 使用负载均衡器公开服务 | 已支持 | 已支持 | 已支持 | 已支持 |
| 使用应用网关入口控制器公开服务 | 已支持 | 已支持 | 已支持 | 已支持 |
| 使用容器应用网关公开服务 | 已支持 | 已支持 | 已支持 | 不支持 |
| Windows 节点池 | 已支持 | 已支持 | 已支持 | 不支持 |
| 默认 Azure DNS 和专用区域 | 已支持 | 已支持 | 已支持 | 已支持 |
| 跨多个群集共享 VNet 子网 | 已支持 | 已支持 | 已支持 | 不支持 |
网络模型之间的支持范围
根据使用的 CNI，可以通过以下方式之一部署群集虚拟网络资源：
- 创建 AKS 群集时，Azure 平台可以自动创建和配置虚拟网络资源。 类似于 Azure CNI Overlay、Azure CNI Node 子网和 Kubenet。
- 创建 AKS 群集时，可以手动创建和配置虚拟网络资源并附加到这些资源。
尽管支持服务终结点或 UDR 等功能， 但 AKS 的支持策略 定义了可以做出哪些更改。 例如：
- 如果您手动为 AKS 群集创建虚拟网络资源，在配置自己的用户定义路由 (UDR) 或服务终结点时，将获得支持。
- 如果 Azure 平台自动为 AKS 群集创建虚拟网络资源，则无法手动更改这些 AKS 托管的资源来配置自己的 UDR 或服务终结点。
先决条件
规划 AKS 的网络配置时，需要牢记以下几个要求和注意事项：
- AKS 群集的虚拟网络必须允许出站 Internet 连接。
- AKS 群集不得将
169.254.0.0/16、172.30.0.0/16、172.31.0.0/16或192.0.2.0/24用于 Kubernetes 服务地址范围、Pod 地址范围或群集虚拟网络地址范围。 - 在 BYO VNet 方案中，AKS 群集使用的群集标识必须至少对虚拟网络中的子网具有 网络参与者 权限。 如果希望定义自定义角色而不是使用内置的网络参与者角色，则需要以下权限：
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/write-
Microsoft.Network/virtualNetworks/subnets/read（仅当定义自己的子网和CIDR 时才需要）
- 分配给 AKS 节点池的子网不能是委托子网。
- AKS 不会将网络安全组 (NSG) 应用于其子网，也不会修改与该子网相关的任何 NSG。 如果提供自己的子网并添加与该子网相关的 NSG，则必须确保 NSG 中的安全规则允许节点 CIDR 范围内的流量。 有关详细信息，请参阅网络安全组。