前言
在建置 Kubernetes 叢集時，CNI（Container Network Interface）插件的選擇一直是讓人頭痛的問題。市面上主流的三大 CNI 插件——Cilium、Calico 和 Flannel，各有各的優勢與適用情境。這篇文章是我自己在研究和實務中整理出來的筆記，希望能幫大家在選型時少走一些彎路。
三大 CNI 插件技術特點一覽
先來看看這三者在技術面的差異。我把關鍵特性整理成表格，方便快速對照：
| 特性 | Cilium | Calico | Flannel |
|---|---|---|---|
| 資料面技術 | eBPF 加速 | iptables（亦支援 eBPF） | VXLAN / host-gw / IPIP 隧道 |
| 轉發效率 | 高（核心層級加速，直通流量） | 高（原生路由模式） | 中等（隧道技術有額外開銷） |
| 可擴展性 | 優秀（支援 L7 進階策略） | 優秀（原生路由 + 網路策略） | 有限（主要處理 L3 層級） |
| 延遲表現 | 低（無需隧道或額外規則） | 低（非隧道或 eBPF 模式下） | 偏高（隧道封裝增加延遲） |
| 吞吐量 | 高（eBPF 高效能轉送） | 中至高（視模式而定） | 偏低（隧道封裝損耗明顯） |
效能指標實測比較
除了規格面的對比，實際的效能數據更有參考價值。以下是根據多項 benchmark 測試匯整的資源消耗指標：
| 效能指標 | Cilium | Calico | Flannel |
|---|---|---|---|
| 吞吐量 | 高（eBPF 直接核心轉送） | 中至高（依資料面模式） | 偏低（封裝損耗較大） |
| 延遲 | 低（直接路由模式最佳） | 偏低（非隧道模式表現佳） | 偏高（隧道增加延遲） |
| CPU 使用率 | 偏高（eBPF + 可觀測性功能） | 中等（iptables/eBPF 開銷） | 低（架構簡單） |
| 記憶體消耗 | 偏高（功能較豐富） | 中等 | 低 |
Benchmark 實測數據
以下是根據典型測試環境所收集的具體量化指標，數值分別為吞吐量（Mbps）與延遲（ms）：
| 測試場景 | Cilium | Calico | Flannel |
|---|---|---|---|
| 吞吐量（單節點） | 約 9,000 Mbps | 約 8,500 Mbps | 約 6,000 Mbps |
| 吞吐量（跨節點） | 約 8,000 Mbps | 約 7,500 Mbps | 約 5,000 Mbps |
| 延遲（單節點） | 約 0.2 ms | 約 0.3 ms | 約 1.0 ms |
| 延遲（跨節點） | 約 0.4 ms | 約 0.5 ms | 約 2.0 ms |
從以上數據可以看出，Cilium 在吞吐量和延遲方面都有明顯的領先優勢，但代價是較高的 CPU 與記憶體消耗。這也是選型時需要權衡的重點。
根據 2024 年的 40Gbit/s 網路環境 benchmark（資料來源：ITNEXT - Benchmark results of Kubernetes network plugins (CNI) over 40Gbit/s network 2024），Cilium 單位頻寬消耗的 CPU 和記憶體確實比 Flannel 來得高。不過換個角度想，這些額外的資源投入換來的是更強大的可觀測性與安全策略能力。
各 CNI 的網路效能深入分析
Cilium
- 吞吐量：透過 eBPF 直接在 Linux 核心中處理封包，大幅減少上下文切換。搭配直連路由模式（
--tunnel=disabled）可進一步降低封裝開銷。 - 延遲：支援 Sidecar-less 服務網格架構，有效降低服務間的通訊延遲。
- 資源消耗：由於內建 Hubble 可觀測性和 L7 策略等進階功能，在 CPU 和記憶體方面的開銷高於其他兩者。
Calico
- 吞吐量：非隧道模式下透過 BGP 原生路由，效能接近裸機水準；搭配 eBPF 模式還能再進一步提升。
- 延遲：一般情況下表現良好，但當網路策略較複雜時，可能會有些微的延遲增加。
- 資源消耗：適中，對大多數正式環境來說是個平衡的選擇。
Flannel
- 吞吐量：採用 VXLAN、IPIP 等隧道封裝方式，效能上不如前兩者。
- 延遲：封裝與解封裝的額外操作會導致延遲增加。
- 資源消耗：架構最簡單、資源使用最少，非常適合資源有限的小型叢集。
不同業務場景該怎麼選？
講了這麼多技術細節，最後來談談實際情境下的選型建議。我自己的心得是：沒有最好的 CNI，只有最適合的 CNI。
選 Cilium 的情境：高效能與安全並重
- 微服務架構：eBPF 支援 L7 封包過濾、服務可觀測性以及無 Sidecar 服務網格，非常適合複雜的微服務環境。
- 邊緣運算：需要低延遲和高吞吐量時，直連路由模式（
--tunnel=disabled）發揮最佳效果。 - 多雲 / 混合雲：支援透明加密與靈活的網路策略配置。
- 需注意：部署複雜度偏高，且對 Linux 核心版本有要求（建議 5.3 以上）。
選 Calico 的情境：大規模企業叢集
- 大規模 K8s 叢集：基於 BGP 的路由能夠高效擴展，適合公有雲與企業級環境。
- 安全策略需求：提供豐富的網路安全策略，搭配 eBPF 可兼顧效能與靈活性。
- 混合部署：非 Kubernetes 工作負載也能套用一致的網路策略。
- 需注意：預設 iptables 模式在高負載下效能不如 Cilium；策略複雜時維運成本較高。
選 Flannel 的情境：輕量化部署
- 小型叢集：架構簡單、資源用量低，快速搭建不費力。
- 測試 / 開發環境：效能要求不高的場景，能迅速啟用。
- 邊緣節點（非高效能）：對網路效能要求較低的輕量級邊緣部署。
- 需注意：缺乏進階網路功能，不支援複雜的網路策略與可觀測性。
選型建議總結
| 場景類型 | 推薦插件 | 理由 |
|---|---|---|
| 高效能微服務架構 | Cilium | eBPF 技術帶來低延遲與複雜策略支援 |
| 大規模企業叢集 | Calico | 穩定且靈活，適合多樣化的大規模部署 |
| 資源受限環境 | Flannel | 簡單好用，資源消耗最低 |
| 邊緣運算 | Cilium 或 Flannel | 高效能選 Cilium，輕量化選 Flannel |
| 混合雲 / 多雲 | Cilium 或 Calico | Cilium 支援透明加密；Calico 提供靈活策略 |
結語
以我自己的經驗來說，如果你的環境已經在用較新的 Linux 核心（5.3+），而且對可觀測性和安全策略有一定需求，Cilium 是目前最值得投資的選擇。但如果你的叢集規模不大、只是想快速跑起來，Flannel 依然是最省事的方案。Calico 則介於兩者之間，特別適合需要精細網路策略但又不想承擔 Cilium 複雜度的團隊。
最後提醒一下，CNI 的選擇不是一成不變的。隨著 Calico 也開始支援 eBPF 模式（3.28 版以後），三者之間的效能差距其實在逐漸縮小。選型時除了看 benchmark 數據，也要考慮團隊的維運能力和現有基礎設施的相容性。
參考資料
- Cilium 官方效能 Benchmark 文件
- Benchmark results of Kubernetes network plugins (CNI) over 40Gbit/s network - 2024
- Cilium vs Calico vs Flannel - Civo
- Calico vs. Cilium: 9 Key Differences - Tigera
發佈留言