使用方式情節
既然您已建立決策準則的優缺點，最好進行一些案例。
部署
在有限的 IP 位址空間中容納數個功能的開發可能很困難。 Kubenet 的設計目的是要考慮位址空間，使其成為開發或實驗環境的絕佳選擇。
如果下列其中一個或多個條件不成立，請考慮在開發環境中使用 Azure CNI 網路：
- 實驗性或開發中的功能不需要虛擬節點搭配 Azure 容器執行個體提供的快速調整功能。
- 環境中因為 Pod 通訊的額外躍點造成些微延遲是可接受的。
- 在開發環境中，維護路由表和 UDR 的作業額外負荷是可接受的。
- 開發環境僅支援以 Linux 為基礎的節點集區。
使用 kubenet 時，Azure 平台會在您建立 AKS 叢集時，自動建立及設定虛擬網路資源。 您也可以手動建立及設定虛擬網路資源，並在建立時將其連結至這些資源。 不過，並不支援對 Azure 管理的網路資源加以變更。
Production
請記住，仍有數個因素會造成 kubenet 無法成為實際執行環境可接受的網路選項。 Kubenet 可以大放異彩為開發中的小型應用程式快速原型和測試方法。
相反地，Azure CNI 更適合用於實際執行環境，其可設定的網路選項包括：
- 降低延遲。
- 透過虛擬節點與 Azure 容器執行個體可以快速調整規模。
- 直接可定址 Pod 可簡化對叢集外部所執行服務的連線。
- 支援進階網路拓撲和相關功能。
如果就您的使用案例而言，會需要一個以上適用於開發環境的 Azure CNI 功能，也可以選擇使用。 舉例來說，如果需要 Windows Server 型的節點，則必須將 Azure CNI 用在開發和實際執行的叢集上。 請記住，這個選擇會引進更多網路拓撲規劃的需求，這需要專家來執行。