确定插件选项

5 分钟

AKS 群集需要网络插件，以便促进 Pod 之间的通信、Pod 与节点之间的通信，以及在某些情况下，节点与 Pod 之间的通信。 AKS 上提供了两种网络模型：kubenet 和 Azure CNI。 Azure CNI 还有其他演变，包括 Azure CNI 覆盖层、用于动态 IP 分配的 Azure CNI 和由 Cilium 提供支持的 Azure CNI。其中每个模型都有自己的一组功能和限制。

kubenet

默认情况下，AKS 群集使用 kubenet。使用 kubenet 时，会在部署群集时自动创建 Azure 虚拟网络、子网和路由表，但可以提供现有的网络资源。使用 kubenet：

节点从 Azure 虚拟网络子网接收 IP 地址。
Pod 从逻辑上与节点池子网不同的地址空间接收 IP 地址。
然后配置网络地址转换（NAT），以便 Pod 可以访问 Azure 虚拟网络上的资源。
流量的源 IP 地址将转换为节点的主 IP 地址。

Pod 无法跨节点直接相互通信。相反，用户定义的路由（UDR）和 IP 转发用于跨节点的 Pod 之间的连接。默认情况下，UDR 和 IP 转发配置由 AKS 服务创建和维护，但必须选择自带路由表进行自定义路由管理。

如果自定义子网不包含路由表，AKS 会为你创建一个路由表，并在群集生命周期内向其添加规则。如果在创建群集时自定义子网包含路由表，AKS 将在群集操作期间确认现有路由表，并相应地为云提供程序操作添加/更新规则。

包含 AKS 群集的 kubenet 网络模型示意图。使用 kubenet 通过虚拟网络的节点子网路由/NAT 流量，会显示两个节点。

Azure CNI

Azure CNI 插件是一个更复杂的网络选项，具有更高的可配置性和更受支持的功能。使用 Azure CNI，需要预先存在的子网和虚拟网络，才能利用与 Azure CNI 网络一起使用的群集，这需要进行额外的规划。虚拟网络及其子网的大小必须容纳计划运行的 Pod 数和群集的节点数。使用 Azure CNI：

节点从 Azure 虚拟网络子网接收 IP 地址空间。
每个 Pod 在节点池的子网中接收 IP 地址，并且可以直接与其他 Pod 和服务通信。
群集的最大大小可为指定的 IP 地址范围上限。但是，IP 地址范围必须提前规划，并且所有 IP 地址都由 AKS 节点根据可支持的最大 Pod 数使用。

使用 Azure CNI 时，需要预先存在的子网和虚拟网络才能利用 Azure CNI 网络插件。可以在 AKS 群集创建期间创建此子网和虚拟网络。

Azure CNI 网络模型示意图。显示 Pod 通过网桥进行通信。每个 Pod 都有一个从虚拟网络的节点子网分配的唯一 IP。

Azure CNI 覆盖

Azure CNI Overlay 表示 Azure CNI 的一种演变，解决了与将虚拟网络 IP 分配到 Pod 相关的可伸缩性和规划挑战。 Azure CNI 覆盖层将专用 CIDR IP 分配给 Pod。专用 IP 独立于虚拟网络，可以跨多个群集重复使用。 Azure CNI 覆盖可以扩展到 Kubenet 群集中强制实施的 400 个节点限制之外。对于大多数群集，建议使用 Azure CNI 覆盖选项。

由 Cilium 提供支持的 Azure CNI

由 Cilium 提供支持的 Azure CNI 使用 Cilium 提供高性能网络、可观测性和网络策略强制实施。它原生与 Azure CNI 覆盖层集成，可以实现可缩放的 IP 地址管理 (IPAM)。

此外，Cilium 默认强制实施网络策略，而无需单独的网络策略引擎。由 Cilium 提供支持的 Azure CNI 可以使用 ePBF 程序和更高效的 API 对象结构来扩展 Azure 网络策略管理器的 250 个节点/20-K Pod 的限制。

Azure CNI 由 Cilium 提供支持，对于需要实施网络策略的群集，建议使用此选项。

使用自定义插件

对于计划使用自定义网络配置的客户，没有网络插件要求。可以从 CNI 提供商（如 Cilium 或 Flannel）中进行选择。但最好求助于自己的文档，因为 Microsoft 并未将其涵盖在内。