Cilium簡介

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

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

解決了容器網(wǎng)絡(luò)云面臨的三大挑戰(zhàn)：連接、可觀測性、安全。

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

擴展云原生連接

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

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

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

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

Cilium 不是 iptables，而是在 eBPF maps 中跟蹤 pod endpoints。這些是存儲在內(nèi)核中的數(shù)據(jù)結(jié)構(gòu)，Cilium 的 eBPF 程序可以訪問這些數(shù)據(jù)結(jié)構(gòu)，以便就每個網(wǎng)絡(luò)數(shù)據(jù)包的發(fā)送位置做出高效的決策。

基于Cilium身份的網(wǎng)絡(luò)策略

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

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

透明加密

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

與傳統(tǒng)基礎(chǔ)架構(gòu)集成

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

Cluster meshes

我們已經(jīng)討論過將 Cilium 與外部遺留工作負載集成，但是多個 Kubernetes 集群呢？是否需要將從一個群集到另一個群集的連接視為另一個外部服務(wù)？您可以將多個支持 Cilium 的 Kubernetes 集群組合在一起，并以非?？岬姆绞嚼?Cilium 的身份模型來幫助多集群服務(wù)配置。Cilium 將這種多集群支持稱為 ClusterMesh。

使用 Cilium ClusterMesh，您可以使用 Kubernetes annotations 指定全局服務(wù)，并且 Cilium 將對與存在于多個集群中的全局服務(wù)關(guān)聯(lián)的服務(wù)端點的訪問進行負載平衡 - 如果需要，可以使用加密流量?？梢詫⑦@些全局服務(wù)的服務(wù)相關(guān)性指定為首選在本地發(fā)送請求（如果終結(jié)點運行正常），并在需要時故障轉(zhuǎn)移到其他群集中的遠程服務(wù)終結(jié)點。

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

網(wǎng)絡(luò)可觀測性

到目前為止，我一直專注于網(wǎng)絡(luò)連接和安全性，但 Cilium 也可以幫助實現(xiàn)大規(guī)模的網(wǎng)絡(luò)可觀測性。

Kubernetes集群內(nèi)部的網(wǎng)絡(luò)可觀測性變得非常復(fù)雜。由于 Pod 不斷來來去去，并且在擴展和縮減時跨不同工作負載重新分配內(nèi)部 IP 地址，因此很難觀察數(shù)據(jù)包流。嘗試按群集內(nèi)的 IP 地址跟蹤數(shù)據(jù)包是徒勞的。即使在節(jié)點上運行 eBPF 驅(qū)動的 tcpdump 也是不夠的，因為 IP 地址和端口很難與工作負載匹配，尤其是當(dāng) Kubernetes 本身可能通過快速重新調(diào)試 pod 來嘗試解決您正在診斷的問題時。當(dāng)其中一個微服務(wù)或我們的網(wǎng)絡(luò)策略出現(xiàn)問題時，我們?nèi)绾潍@得可觀測性？

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

Hubble UI 更進一步，提供了服務(wù)依賴關(guān)系圖的圖形描述以及網(wǎng)絡(luò)流詳細信息。

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

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

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

• 流程執(zhí)行事件。
• 系統(tǒng)調(diào)用活動。
• I/O 活動，包括網(wǎng)絡(luò)和文件訪問。

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

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

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

無邊車服務(wù)網(wǎng)格

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

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

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

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

不僅僅是 Kubernetes

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