决策条件
为用例选择最佳网络插件取决于你的条件。 每个选项都有优缺点，做出选择时，应权衡利弊。
高级决策条件
IPv4 耗尽
Kubenet 在设计时考虑到了节省 IP 地址空间。 Azure CNI 为 Pod 提供完整的网络连接，但需要更多的 IP 地址空间和规划。 IPv4 耗尽指地址数量达到上限并停止缩放或升级操作中的节点。 在耗尽期间，应用程序需要过多的资源，只能艰难满足需求。
Kubenet 可让节点接收定义的 IP 地址，而无需提前为群集中可能运行的所有潜在 Pod 节点预留大量的 IP 地址。 借助 Kubenet，可以不用太担心 IPv4 耗尽，只需处理小型 IP 地址范围，即可支持大型群集和满足应用程序需求。
以下基本计算方法对网络模型的地址空间做了比较：
- kubenet：一个简单的 /24 IP 地址范围最多可以支持群集中的 251 个节点（每个 Azure 虚拟网络子网预留前三个 IP 地址用于管理操作）。 此节点计数最多可以支持 27,610 个 Pod（使用 kubenet 的每个节点的最大 Pod 数默认为 110 个）。
- 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 网络策略）的复杂网络拓扑。
这些额外功能包括：
- 每个节点池的子网
- IP 的动态分配
- 节点与 Pod 的子网分配
Kubenet 与 Azure CNI 的行为差异
除了高级条件外，功能方面还有许多行为差异和偏差：
| 功能 | Kubenet | Azure CNI | Azure CNI 覆盖 | 由 Cilium 提供支持的 Azure CNI |
|---|---|---|---|---|
| 在现有或新的虚拟网络中部署群集 | 支持 - 手动应用 UDR | 支持 | 受支持 | 支持 |
| Pod-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 |