雲端擴展：Istio Ambient 與 Cilium 的比較

來自潛在 Istio 用戶的一個常見問題是「Istio 與 Cilium 相比如何？」雖然 Cilium 最初僅提供 L3/L4 功能，包括網路原則，但最近的版本已使用 Envoy 添加了服務網格功能，以及 WireGuard 加密。與 Istio 一樣，Cilium 也是一個 CNCF 畢業專案，並且在社群中已經存在多年。

儘管表面上提供了類似的功能集，但這兩個專案的架構卻截然不同，最值得注意的是 Cilium 使用 eBPF 和 WireGuard 在核心中處理和加密 L4 流量，而 Istio 的 ztunnel 組件則在用戶空間中處理 L4。這些差異導致人們對 Istio 與 Cilium 相比在大規模情況下的效能產生了相當多的猜測。

雖然已經對這兩個專案的租戶模型、安全協定和基本效能進行了許多比較，但尚未發布針對企業規模的完整評估。我們沒有強調理論上的效能，而是對 Istio 的 Ambient 模式和 Cilium 進行了徹底的測試，重點關注延遲、吞吐量和資源消耗等關鍵指標。我們使用實際的負載情境來加強壓力，模擬繁忙的 Kubernetes 環境。最後，我們將 AKS 叢集的大小增加到 1,000 個節點和 11,000 個核心，以了解這些專案在大規模情況下的效能表現。我們的結果顯示了每個專案可以改進的方面，但也表明 Istio 是明顯的贏家。

測試情境

為了將 Istio 和 Cilium 推向極限，我們建立了 500 種不同的服務，每種服務由 100 個 Pod 支援。每種服務都在一個單獨的命名空間中，其中還包含一個 Fortio 負載產生器客戶端。我們將客戶端限制在 100 個 32 核心機器的節點池中，以消除來自共置客戶端的雜訊，並將剩餘的 900 個 8 核心實例分配給我們的服務。

對於 Istio 測試，我們使用了 Istio 的 Ambient 模式，每個服務命名空間都有一個 航點代理 和預設的安裝參數。為了使我們的測試情境類似，我們必須在 Cilium 中開啟一些非預設功能，包括 WireGuard 加密、L7 代理和節點初始化。我們還在每個命名空間中建立了一個 Cilium 網路原則，其中包含基於 HTTP 路徑的規則。在這兩種情境中，我們都透過每秒隨機將一項服務擴展到 85 到 115 個實例，以及每分鐘重新標記一個命名空間來產生變動。若要查看我們使用的精確設定並重現我們的結果，請參閱我的筆記。

可擴展性評分卡

Istio 能夠以 20% 更低的尾端延遲提供多 56% 的查詢。Cilium 的 CPU 使用率降低了 30%，但我們的測量不包括 Cilium 用於處理加密的核心，這是在核心中完成的。

考慮到使用的資源，Istio 每個核心處理了 2178 個查詢，而 Cilium 則為 1815 個，提高了 20%。

• Cilium 減速： Cilium 雖然在預設安裝參數下擁有令人印象深刻的低延遲，但當 Istio 的基本功能（例如 L7 原則和加密）開啟時，速度會大幅降低。此外，即使網格中沒有流量流動，Cilium 的記憶體和 CPU 使用率仍然很高。這可能會影響叢集的整體穩定性和可靠性，尤其是在叢集擴大時。
• Istio，穩定的效能執行者：另一方面，Istio 的 Ambient 模式在穩定性和保持良好的吞吐量方面展現了其優勢，即使在增加了加密的額外負擔的情況下也是如此。雖然 Istio 在測試下確實消耗了比 Cilium 更多的記憶體和 CPU，但當沒有負載時，其 CPU 使用率會降至 Cilium 的一小部分。

幕後花絮：為什麼會有差異？

了解這些效能差異的關鍵在於每個工具的架構和設計。

• Cilium 的控制平面難題： Cilium 在每個節點上執行一個控制平面實例，隨著叢集的擴展，會導致 API 伺服器壓力以及配置開銷。這經常導致我們的 API 伺服器崩潰，隨後 Cilium 變得無法就緒，整個叢集變得無回應。
• Istio 的效率優勢： Istio 憑藉其集中的控制平面和基於身分的方法，簡化了配置，並減輕了 API 伺服器和節點的負擔，將關鍵資源導向處理和保護您的流量，而不是處理配置。Istio 進一步利用控制平面中未使用的資源，執行工作負載所需的多個 Envoy 實例，而 Cilium 則僅限於每個節點一個共用 Envoy 實例。

深入探討

雖然此專案的目的是比較 Istio 和 Cilium 的可擴展性，但一些限制使得直接比較變得困難。

第 4 層不總是第 4 層

雖然 Istio 和 Cilium 都提供 L4 原則強制執行，但它們的 API 和實作卻有很大的差異。Cilium 實作 Kubernetes NetworkPolicy，它使用標籤和命名空間來阻止或允許存取進出 IP 位址。Istio 提供 AuthorizationPolicy API，並根據用於簽署每個請求的 TLS 身分做出允許和拒絕的決定。大多數深度防禦策略需要同時使用 NetworkPolicy 和基於 TLS 的原則來實現全面的安全性。

並非所有加密都相同

雖然 Cilium 提供 IPsec 作為符合 FIPS 的加密，但大多數其他 Cilium 功能（例如 L7 原則和負載平衡）與 IPsec 不相容。當使用 WireGuard 加密時，Cilium 具有更好的功能相容性，但 WireGuard 不能在符合 FIPS 的環境中使用。另一方面，由於 Istio 嚴格遵守 TLS 協定標準，因此預設情況下始終使用符合 FIPS 的 mTLS。

隱藏成本

雖然 Istio 完全在使用者空間中運作，但 Cilium 的 L4 資料平面使用 eBPF 在 Linux 核心中執行。資源消耗的 Prometheus 指標僅測量使用者空間資源，這意味著此測試中未考慮 Cilium 使用的所有核心資源。

建議：選擇合適的工具

那麼，結論是什麼呢？嗯，這取決於您的特定需求和優先順序。對於純 L3/L4 用例且不需要加密的小型叢集，Cilium 提供經濟高效且效能良好的解決方案。然而，對於較大的叢集以及對穩定性、可擴展性和進階功能的關注，Istio 的 Ambient 模式以及替代的 NetworkPolicy 實作是最佳選擇。許多客戶選擇將 Cilium 的 L3/L4 功能與 Istio 的 L4/L7 和加密功能結合使用，以實現深度防禦策略。

請記住，雲原生網路的世界正在不斷發展。請密切關注 Istio 和 Cilium 的發展，因為它們會繼續改進並解決這些挑戰。

讓我們繼續對話

您是否使用過 Istio 的 Ambient 模式或 Cilium？您的經驗和見解是什麼？請在下面的評論中分享您的想法。讓我們互相學習，並一起駕馭令人興奮的 Kubernetes 世界！