決策準則
是否為使用案例選擇了最佳網路外掛程式會依您的準則而定。 每個選項各有其優缺點，以及在進行選取時要考量的取捨因素。
高階決策準則
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 每個節點預設最多 110 個 Pod)。
- Azure CNI：相同的基本 /24 子網路範圍只能支援叢集中最多 8 個節點。 此節點計數最多僅支援 240 個 Pod (Azure CNI 每個節點預設最多 30 個 Pod)。
叢集大小
Kubenet 每個叢集的節點上限為 400 個，而 Azure CNI 則會依外掛程式的設定方式而不同。
連線性
在 Kubenet 中，您必須手動管理和維護使用者定義的路由 (UDR)。 若要從叢集外部連線到 Pod，就必須使用負載平衡器。 透過 Azure CNI，Pod 會獲得完整的虛擬網路連線能力，而且可以直接從已連線的網路透過 Pod 的私人 IP 位址來與 Pod 連線。
多重叢集支援
在 kubenet 中，多個叢集無法使用相同的節點子網路。 透過 Azure CNI，便可以實現此設定。
Latency
相較於 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 |