關於遷移 Kubernetes CNI Plugin 的一些經驗談

Sat, 02 May 2026 00:00:00 +0000

Tip

TL;DR：如果你正在為你的 Kubernetes 尋找替代的 CNI Plugin 與對應的遷移計劃，Cilium 是一個很好的選擇。它支援從幾乎任何 CNI 進行 Live-Migration ，並提供 Network Policy 與完整的的可觀測性生態系。

對於正在運行的 Kubernetes 叢集（特別是在 Production 上）而言，遷移 CNI Plugin 並不是簡單的任務。一個簡易的策略是藍綠部署（Blue/Green deployment），即設定一個帶有目標 CNI 的新叢集，並將工作負載從舊叢集轉移到新叢集上。這種方法能確保停機時間最少（仍需要額外設定，例如 Load Balancer 以確保可用性），且能忽略不同 CNI 之間的差異。然而，如果必須進行「原地遷移」呢？雖然這種場景不常見且具挑戰性，但對於運行有 Stateful 或受託管的工作負載的叢集通常是必要的。例如，平台透過 Kubernetes 提供運算資源，但營運人員無法控制部署在其中的服務。如果營運人員希望在不讓使用者察覺或參與的情況下遷移 CNI，則仍需要原地遷移。

原地遷移可以分為兩種類型：替換與 Live-Migration 。替換意味著移除舊的 CNI 並安裝新的，這代表在移除與安裝之間會發生網路的連接中斷，且會令遷移結果不可預測；相較之下， Live-Migration 在遷移過程能夠中保持網路連接，以將對工作負載的影響降至最低。大多數 CNI Plugin 完全不或僅有限度地支援 Live-Migration ，例如 OVN-Kubernetes、Kube-Router 和 Flannel。雖然有些 CNI 支援 Live-Migration ，但僅在特定條件下運作，例如 Calico 支援從 Flannel 和 Canal 遷移，但不支援從其他 CNI Plugin 遷移。缺乏 Live-Migration 支援源於 CNI Plugin 的設計。 CNI Specification 定義了 Container Runtime 如何選擇 CNI Plugin 及其應支援的操作，但並未提供跨不同 CNI Plugin 運行時， Pod 之間能夠保持連通性的 Interface。有些使用者可能會考慮使用 Multus。該 Plugin 可以作為不同 CNI 之間的中介層運行，這使得支援任意 CNI Plugin 間的 Live-Migration 成為可能。然而，根據我的經驗，混合不同 CNI 的 Network Interface 及相關的 IP table 規則時，Multus 並不總是能正常運作（取決於目標 CNI Plugin ），這使得 Multus 並非一個可靠的解決方案。

Cilium on Hallblazzar: 開發者日誌

關於遷移 Kubernetes CNI Plugin 的一些經驗談