你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Kubernetes 服务 (AKS) CNI 网络概述
Kubernetes 使用容器网络接口 (CNI) 插件来管理 Kubernetes 群集中的网络。 CNI 负责为 Pod 分配 IP 地址、在 Pod 之间进行网络路由、协助开展 Kubernetes 服务路由等。
AKS 提供了多个 CNI 插件，你可以根据自己的网络需求在群集中加以使用。
AKS 中的网络模型
要为 AKS 群集选择哪种 CNI 插件很大程度上取决于哪种网络模型最符合你的需求。 每个模型都有自己的优点和缺点，在规划 AKS 群集时应考虑这些因素。
AKS 使用两个主要网络模型：叠加网络和扁平网络。
两种网络模型都支持多个 CNI 插件选项。 这两种模型之间的主要区别在于如何分配 Pod IP 地址以及流量如何离开群集。
叠加网络
叠加网络是 Kubernetes 中使用的最常见网络模型。 在叠加网络中，Pod 获得的是来自专用 CIDR 的 IP 地址，该 CIDR 在逻辑上独立于部署 AKS 节点的 Azure VNet 子网。 与扁平网络模型相比，这样的分配更易于设置，并且通常具有更好的可扩展性。
在叠加网络中，Pod 可以直接相互通信。 系统会通过源网络地址转换方法 (SNAT)，将离开群集的流量的源网络地址转换为节点的 IP 地址，同时会通过某些服务（如负载均衡器）路由进入 Pod IP 的流量。 这意味着 Pod IP 地址会“隐藏”在节点的 IP 地址后面。 此方法可减少群集所需的 VNet IP 地址数。
Azure Kubernetes 服务为叠加网络提供以下 CNI 插件：
- Azure CNI Overlay，对于大多数场景，均推荐此 CNI 插件。
- kubenet，旧版叠加模型 CNI。
扁平网络
与叠加网络不同，AKS 中的扁平网络模型将 IP 地址从与 AKS 节点相同的 Azure VNet 中的子网分配给 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 覆盖 | Overlay | - 最适合 VNET IP 保护 - API 服务器支持的最大节点数 + 每个节点 250 个 Pod - 更简单的配置 - 无法直接从外部访问 Pod IP |
| Azure CNI Pod 子网 | 平面 | - 可直接从外部访问 Pod - 适用于高效 VNet IP 使用或大型群集缩放支持的模式（预览） |
| Kubenet（旧版） | Overlay | - 优先保护 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 节点子网和 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/writeMicrosoft.Network/virtualNetworks/subnets/read（仅当定义自己的子网和 CIDR 时才需要）
- 分配给 AKS 节点池的子网不能是委托子网。
- AKS 不会将网络安全组 (NSG) 应用于其子网，也不会修改与该子网相关的任何 NSG。 如果提供自己的子网并添加与该子网相关的 NSG，则必须确保 NSG 中的安全规则允许节点 CIDR 范围内的流量。 有关详细信息，请参阅网络安全组。
