Cilium簡介

Cilium 是一種開源的云原生網絡解決方案，基于革命性的內核技術 eBPF ，為工作負載提供高性能、安全、可觀測的網絡連接。eBPF 技術通過提供附加自定義程序到內核中的事件為應用程序提供超能力，Cilium 項目利用 eBPF 的能力開發了多個程序，通過這些程序可以有效地管理容器集群。

目前Clilium項目包含三個項目：Cilium、Hubble、Tetragon。

解決了容器網絡云面臨的三大挑戰：連接、可觀測性、安全。

Cilium最初由Isovalent創建，并于2015年開源，非常受歡迎。有14000+ GitHub star，500+貢獻者，以及14000+用戶注冊了Cilium社區Slack。更重要的是，Cilium 被媒體、金融和搜索等各種垂直行業的組織廣泛部署在生產環境中，AWS、微軟、Google三大云提供商現在都在其 Kubernetes 服務產品中支持 Cilium。Cilium 于2021年10月加入CNCF孵化，并于2022年10月畢業。畢業狀態是任何 CNCF 項目的一個重要里程碑，表明該項目擁有可持續的貢獻者社區，被廣泛采用，并且正在成為任何云規模堆棧的預期部分。

擴展云原生連接

Kubernetes 的最大優勢在于其動態特性，這使其能夠按需擴展服務，并在出現問題時將 Pod 和服務協調到所需的狀態。例如，如果一個節點出現故障，Kubernetes 將自動重啟集群中另一個節點上的 pod，以彌補其損失。但是，這種動態性給傳統網絡帶來了麻煩，因為IP地址在整個集群中被重新分配和重用。對于人工操作員，存在可觀測性問題，因為您無法再對與特定工作負載匹配的 IP 地址做出假設。在底層網絡堆棧中，某些組件不是為不斷重用 IP 地址而設計的，從而導致大規模性能問題。

Cilium 在 Linux 內核的不同點注入 eBPF 程序，提供適合云原生時代的連接層，該層使用 Kubernetes identities 而不是 IP 地址，并允許繞過部分網絡堆棧以獲得更好的性能。

在 Kubernetes 中，Pod 通常運行自己的網絡命名空間，這意味著數據包必須經歷網絡堆棧兩次——一次在 Pod 命名空間中，一次在主機中。Cilium 允許繞過主機堆棧的重要部分，從而顯著提高性能。就像閃電俠一樣，它快如閃電。

從上圖可以看出，Cilium 可以繞過網絡堆棧中的 iptables。這是一個在設計時沒有考慮到 Kubernetes 行為的組件，并且由于 Kubernetes 的動態性質，iptables 的性能通常會大規模下降。在節點、Pod 和服務較多的大型集群中，通常有大量的 iptables 過濾器和轉發規則，需要隨著 Pod 的來來去去進行更新。更糟糕的是，對于iptables，更改一個規則意味著整個表被重寫。隨著部署的增長，每次創建或銷毀 Pod 時，規則需要越來越長的時間來收斂，從而導致大規模正確操作的嚴重延遲。

Cilium 不是 iptables，而是在 eBPF maps 中跟蹤 pod endpoints。這些是存儲在內核中的數據結構，Cilium 的 eBPF 程序可以訪問這些數據結構，以便就每個網絡數據包的發送位置做出高效的決策。

基于Cilium身份的網絡策略

傳統的 Kubernetes 網絡策略基于 iptables filters，這些 filters 也存在相同的規模問題。Cilium 采用了不同的方法，使用 Kubernetes 標簽為 Pod 分配安全身份（類似于 Kubernetes 使用標簽識別分配給每個服務的 Pod 的方式）。網絡策略以 eBPF maps 表示，并允許在網絡流量進入或離開 Cilium 管理的節點時從這些映射進行超快速查找，以決定是否允許或拒絕數據包。這些eBPF程序非常小，速度超快。

使用 Cilium，您可以編寫應用程序感知的 L7 策略！例如，您可以編寫一個策略來限制 Pod 之間的訪問，以僅允許特定 API 端點上的特定 HTTP REST 方法。您還可以根據完全限定的域名或 IP 地址篩選流量，以便在流量需要在群集外部通信時進行通信。

透明加密

策略實施并不是 Cilium 提供的網絡安全的唯一方面。零信任網絡已迅速成為最佳實踐，透明加密可能是確保所有網絡流量都加密的最簡單方法。您可以輕彈開關，讓 Cilium 創建流量通過的 IPsec 或 WireGuard 連接。通過 eBPF 的魔力，這發生在內核級別，因此您的應用程序不需要任何更改即可加密其流量。

與傳統基礎架構集成

借助 Cilium，您可以輕松地將容器化客戶端和服務與舊式基礎架構連接起來。來自 Kubernetes Pod 的網絡流量最終看起來像是從偽隨機 IP 地址到在數據中心服務器機架中的虛擬機上運行的傳統服務。您的傳統防火墻基礎設施非常希望處理靜態 IP 地址，以便它可以區分朋友和敵人。Cilium 具有出口網關概念，可通過具有固定 IP 地址的特定出口節點路由用于傳統服務的流量。另一方面，Cilium 還支持邊界網關協議 （BGP），以便更輕松地將 Kubernetes 服務的路由宣布到集群外部的網絡基礎設施。Cilium 在與您的外部服務集成時為您提供來來往往。

Cluster meshes

我們已經討論過將 Cilium 與外部遺留工作負載集成，但是多個 Kubernetes 集群呢？是否需要將從一個群集到另一個群集的連接視為另一個外部服務？您可以將多個支持 Cilium 的 Kubernetes 集群組合在一起，并以非常酷的方式利用 Cilium 的身份模型來幫助多集群服務配置。Cilium 將這種多集群支持稱為 ClusterMesh。

使用 Cilium ClusterMesh，您可以使用 Kubernetes annotations 指定全局服務，并且 Cilium 將對與存在于多個集群中的全局服務關聯的服務端點的訪問進行負載平衡 - 如果需要，可以使用加密流量。可以將這些全局服務的服務相關性指定為首選在本地發送請求（如果終結點運行正常），并在需要時故障轉移到其他群集中的遠程服務終結點。

簡化跨集群故障轉移只是一個好處：有各種實際的多集群用例，在 Cilium ClusterMesh 中更容易實現。設置 ClusterMesh 只是讓啟用 Cilium 的集群相互感知的問題，而 cilium cli 工具使這個過程非常簡單。事實上，我能夠使用 Cilium 項目的快速入門指南，在短短幾分鐘內在 Azure AKS 中啟動跨越美國東部和西部區域的全局服務故障轉移 Cilium ClusterMesh，在第一次嘗試之前，我對 Azure AKS 一無所知。

網絡可觀測性

到目前為止，我一直專注于網絡連接和安全性，但 Cilium 也可以幫助實現大規模的網絡可觀測性。

Kubernetes集群內部的網絡可觀測性變得非常復雜。由于 Pod 不斷來來去去，并且在擴展和縮減時跨不同工作負載重新分配內部 IP 地址，因此很難觀察數據包流。嘗試按群集內的 IP 地址跟蹤數據包是徒勞的。即使在節點上運行 eBPF 驅動的 tcpdump 也是不夠的，因為 IP 地址和端口很難與工作負載匹配，尤其是當 Kubernetes 本身可能通過快速重新調試 pod 來嘗試解決您正在診斷的問題時。當其中一個微服務或我們的網絡策略出現問題時，我們如何獲得可觀測性？

是時候向您介紹Cilium的超級朋友 Hubble 了。Hubble 過濾了動態IP尋址的噪聲，將網絡流與其Kubernetes身份呈現在一起，因此您可以清楚地看到Pod和服務如何相互通信以及與外部世界進行通信。Hubble建立在Cilium的基礎上，創建了一個一流的容器網絡可觀測性平臺，不僅能夠向你顯示網絡第3層和第4層的流的詳細信息，還可以在第7層向你顯示協議流的細節，如HTTP和gRPC。

Hubble UI 更進一步，提供了服務依賴關系圖的圖形描述以及網絡流詳細信息。

Cilium 和 Hubble 共同揭示了各種各樣的指標、跟蹤和日志，這些指標、跟蹤和日志對于觀察您的網絡和診斷問題非常寶貴。您可以將這些數據提取到Grafana中以便于可視化，輕松回答有關您的網絡的各種問題。例如，如果您想知道特定服務或所有集群的 4xx HTTP 響應速率，或者如果您想知道性能最差的服務之間的請求/響應延遲，Hubble 指標可以滿足您的需求。

運行時安全性：可觀測性和強制實施

但容器安全性不僅與網絡策略有關，容器運行時也受益于安全策略。Tetragon專注于使用eBPF進行運行時安全可觀察性和實施。Tetragon 檢測并可以報告一系列安全重要事件，例如：

• 流程執行事件。
• 系統調用活動。
• I/O 活動，包括網絡和文件訪問。

Tetragon并不是第一個出現的eBPF驅動的安全工具，但它為容器安全帶來了許多新功能。如果其他項目在表面上掛接到系統調用，則它們受到檢查時間到使用時間漏洞的影響，在該漏洞中，系統調用的參數可能在到達內核之前被覆蓋。Cilium 工程師利用他們對內核內部的了解，在不受此問題影響的點上掛鉤到事件中。

Tetragon的跟蹤策略允許您配置要觀察的內核事件，并定義匹配條件并采取行動。更重要的是，Tetragon提供基于Kubernetes身份的上下文信息。例如，如果要檢測對特定文件或目錄的訪問，則可以配置一個 TracingPolicy，該策略將發出日志，準確告訴您哪個進程（運行哪個可執行文件）、哪個 pod 訪問了該文件。您甚至可以將策略配置為在文件訪問完成之前終止違規進程。這非常強大，并為容器安全增加了一種全新的方法，以幫助您限制容器暴露的攻擊面。像沙贊一樣，Tetragon被賦予所羅門的智慧，擁有豐富的知識和對如何采取行動的判斷技巧。

Tetragon可以獨立使用，獨立于Cilium的網絡功能。但是想象一下，你可以用一個Tetragon&Cilium超級英雄的團隊來做什么，結合網絡和運行時安全超能力，這樣你就可以，例如，看到啟動可疑網絡連接的完整進程祖先。

無邊車服務網格

您已經看到 Cilium 不僅實現了 Kubernetes 服務之間的連接，而且還提供了可觀測性和安全性功能，并且能夠在第 7 層采取行動。這不是與服務網格非常相似嗎？是的！現在，Cilium 項目可以提供服務網格功能，而無需將邊車注入每個 pod，從而提高服務網格效率。進步有多大？讓我們看一下對同一節點上容器之間的 HTTP 延遲處理的影響。使用 HTTP 代理總是會有成本的，但是，當您使用sidecar模式時，您可能會支付兩倍的代價，因為微服務相互通信并且流量同時通過ingress和egress sidecar HTTP 代理。減少網絡路徑中的代理數量并選擇 HTTP filter 的類型會對性能產生重大影響。

下面是一個基準比較，來自一篇深入探討 Cilium 服務網格如何工作的博客文章，它說明了運行 Cilium Envoy filter（棕色）的單個節點范圍的 Envoy 代理與運行 Istio Envoy filter（藍色）的雙邊車 Envoy 模型的 HTTP 處理的典型延遲成本。黃色是沒有代理且未執行 HTTP 處理的基線延遲。

Cilium Service Mesh 通過使用 Envoy 網絡代理來實現這種延遲改進，該代理作為 agent 的一部分在每個節點上運行，而不是作為 sidecar 附加到每個 Pod。但這種改進也不全面的，是因為Cilium在將網絡流量重定向到節點范圍的Envoy代理之前盡可能多地使用eBPF。這是一個令人印象深刻的一兩拳組合，值得野貓，利用時機和技術而不是蠻力來獲得您想要的結果。

這不是一種新方法——Envoy 已經在 Cilium 中用于實施第 7 層感知網絡策略多年。為了實現其無 sidecar 服務網格，Cilium 擴展了對完全兼容的 Kubernetes 入口和網關 API 實現的支持，以及一個較低級別的 CRD，該 CRD 在 Cilium 中公開了 Envoy 的全部功能。如果您現在正在使用基于sidecar 的服務網格，并且開始感到與在每個 Pod 中部署服務網格sidecar相關的資源成本緊張，那么現在是將 Cilium Service Mesh 視為資源效率更高的替代品的好時機。

不僅僅是 Kubernetes

雖然一直在 Kubernetes 集群的背景下談論 Cilium，但 Cilium 不僅限于 Kubernetes。Cilium 為連接性、可觀測性和安全性帶來的好處也可以在 Kubernetes 之外的工作負載中實現。例如，Cilium 可以用作獨立的負載均衡器，并在實際生產環境中顯示出令人印象深刻的優勢。