决策条件

为用例选择最佳网络插件取决于你的条件。每个选项都有自己的优点、缺点和利弊，在做出选择时要考虑。

高级决策条件

Kubenet 设计时考虑到了 IP 地址空间的保护。 Azure CNI 为 Pod 提供完整的网络连接，但需要更多的 IP 地址空间和规划。 IPv4 耗尽指的是当地址数量达到上限时，阻止节点进行扩展或升级操作。在资源耗尽时，您的应用程序需要过多的资源，难以跟上需求。

Kubenet 允许节点接收定义的 IP 地址，而无需为群集中运行的所有潜在 Pod 提前保留大量 IP 地址。使用 kubenet，可以不太担心 IPv4 耗尽，并处理小型 IP 地址范围，以满足大型群集支持和应用程序需求。

以下基本计算比较网络模型中的地址空间：

kubenet：一个简单的 /24 IP 地址范围最多可以支持集群中的 251 个节点（每个 Azure 虚拟网络子网保留前三个 IP 地址用于管理操作）。此节点计数最多可以支持 27,610 个 pod（默认情况下，每个具有 kubenet 的节点最多支持 110 个 pod）。
Azure CNI：相同的基本 /24 子网范围只能支持群集中最多 8 个节点。此节点计数最多只能支持 240 个 Pod（使用 Azure CNI 的每个节点的最大 Pod 数默认为 30 个）。

Kubenet 每个群集最多有 400 个节点，而 Azure CNI 取决于插件的配置方式。

在 Kubenet 中，必须手动管理和维护用户定义的路由（UDR）。若要从群集外部访问 Pod，必须使用负载均衡器。使用 Azure CNI，pod 可获得完整虚拟网络连接，并可直接通过其专用 IP 地址从已连接网络中访问。

在 kubenet 中，多个群集不能使用相同的节点子网。使用 Azure CNI 时，可以使用此配置。

与 Azure CNI 相比，Kubenet 需要额外的跃点，这可能会造成轻微延迟。应使用 Azure CNI 在群集上部署延迟敏感的工作负荷。

Azure CNI 支持使用 Azure CNI 网络（例如虚拟节点或 Azure 网络策略）的复杂网络拓扑。

这些额外功能包括：

除了高级标准之外，功能支持方面还存在许多行为差异和不一致之处。

能力	Kubenet	Azure CNI	Azure CNI 覆盖	由 Cilium 提供支持的 Azure CNI
在现有或新的虚拟网络中部署群集	支持 - 手动应用的 UDR	已支持	已支持	已支持
Pod 间连接	已支持	已支持	已支持	已支持
Pod-VM 连接；同一虚拟网络中的 VM	由 Pod 启动时工作	双向工作	由 Pod 启动时工作	由 Pod 启动时工作
Pod-VM 连接；对等互连虚拟网络中的 VM	由 Pod 启动时工作	双向工作	由 Pod 启动时工作	由 Pod 启动时工作
使用 VPN 或 Express Route 进行本地访问	由 Pod 启动时工作	双向工作	由 Pod 启动时工作	由 Pod 启动时工作
访问受服务终结点保护的资源	已支持	已支持	已支持
对由专用终结点公开的资源的访问权限	已支持	已支持
使用负载均衡器服务、应用网关或入口控制器公开 Kubernetes 服务	已支持	已支持	已支持	使用覆盖模式时的相同限制
默认的 Azure DNS 和专用区域	已支持	已支持	已支持
支持 Windows 节点池	不支持	已支持	已支持	仅适用于 Linux
虚拟节点	不支持	已支持	不支持
共享一个子网的多个群集	不支持	已支持	已支持
支持的网络策略	Calico	Calico 和 Azure 网络策略	Calico、Azure 网络策略、Cilium	Ciliuim