Cilium 1.11 發(fā)布，帶來內(nèi)核級服務(wù)網(wǎng)格、拓?fù)涓兄酚?...

作者：Cilium 母公司 Isovalent 團隊
譯者：范彬，狄衛(wèi)華，米開朗基楊

注：本文已取得作者本人的翻譯授權(quán)！

Cilium 項目已逐漸成為萬眾矚目之星，我們很自豪能夠成為該項目的核心人員。幾天前，我們發(fā)布了具有諸多新功能的 Cilium 1.11 版本，這是一個令人興奮的版本。諸多新功能中也包括了萬眾期待的 Cilium Service Mesh 的 Beta 版本。在本篇文章中，我們將深入探討其中的部分新功能。

Service Mesh 測試版本（Beta）

在探討 1.11 版本之前，讓我們先了解一下 Cilium 社區(qū)宣布的 Service Mesh 的新功能。

• 基于 eBPF 技術(shù)的 Service Mesh （Beta）版本： 定義了新的服務(wù)網(wǎng)格能力，這包括 L7 流量管理和負(fù)載均衡、TLS 終止、金絲雀發(fā)布、追蹤等諸多能力。
• 集成了 Kubernetes Ingress (Beta) 功能： 通過將 eBPF 和 Envoy 的強勢聯(lián)合，實現(xiàn)了對 Kubernetes Ingress 的支持。

Cilium 網(wǎng)站的一篇文章詳細介紹了Service Mesh Beta 版本^[1]，其中也包括了如何參與到該功能的開發(fā)。當(dāng)前，這些 Beta 功能是 Cilium 項目中的一部分，在單獨分支^[2]進行開發(fā)，可獨立進行測試、反饋和修改，我們期待在 2022 年初 Cilium 1.12 版本發(fā)布之前合入到 Cilium 主分支。

Cilium 1.11

Cilium 1.11 版本包括了 Kubernetes 額外功能，及單獨部署的負(fù)載均衡器。

• OpenTelemetry 支持：Hubble L3-L7 可觀測性數(shù)據(jù)支持 OpenTelemetry 跟蹤和度量（Metrics）格式的導(dǎo)出。 (更多詳情^[3])
• Kubernetes APIServer 策略匹配：新的策略實體用于簡單方便地創(chuàng)建進出 Kubernetes API Server 流量的策略模型。 (更多詳情^[4])
• 拓?fù)涓兄穆酚?/strong>：增強負(fù)載均衡能力，基于拓?fù)涓兄獙⒘髁柯酚傻阶罱亩它c，或保持在同一個地區(qū)（Region）內(nèi)。 (更多詳情^[5])
• BGP 宣告 Pod CIDR：使用 BGP 在網(wǎng)絡(luò)中宣告 Pod CIDR 的 IP 路由。（更多詳情^[6])
• 服務(wù)后端流量的優(yōu)雅終止：支持優(yōu)雅的連接終止，通過負(fù)載均衡向終止的 Pod 發(fā)送的流量可以正常處理后終止。(更多詳情^[7])
• 主機防火墻穩(wěn)定版：主機防火墻功能已升級為生產(chǎn)可用的穩(wěn)定版本。（更多詳情^[8]）
• 提高負(fù)載均衡器擴展性：Cilium 負(fù)載均衡支持超過 64K 的后端端點。(更多詳情^[9])
• 提高負(fù)載均衡器設(shè)備支持：負(fù)載均衡的加速 XDP 快速路徑現(xiàn)在支持 bond 設(shè)備（更多詳情^[10]) 同時，可更普遍地用于多設(shè)備設(shè)置。 (更多詳情^[11])。
• Kube-Proxy-replacement 支持 istio：Cilium 的 kube-proxy 替代模式與 Istio sidecar 部署模式兼容。 (更多詳情^[12])
• Egress 出口網(wǎng)關(guān)的優(yōu)化：Egress 網(wǎng)關(guān)能力增強，支持其他數(shù)據(jù)路徑模式。 (更多詳情^[13])
• 托管 IPv4/IPv6 鄰居發(fā)現(xiàn)：對 Linux 內(nèi)核和 Cilium 負(fù)載均衡器進行了擴展，刪除了其內(nèi)部 ARP 庫，將 IPv4 的下一跳發(fā)現(xiàn)以及現(xiàn)在的 IPv6 節(jié)點委托給內(nèi)核管理。 (更多詳情^[14])
• 基于路由的設(shè)備檢測：外部網(wǎng)絡(luò)設(shè)備基于路由的自動檢測，以提高 Cilium 多設(shè)備設(shè)置的用戶體驗。 (更多詳情^[15])
• Kubernetes Cgroup 增強：在 cgroup v2 模式下集成了 Cilium 的 kube-proxy-replacement 功能，同時，對 cgroup v1/v2 混合模式下的 Linux 內(nèi)核進行了增強。 (更多詳情^[16])
• Cilium Endpoint Slices：Cilium 基于 CRD 模式能夠更加高效地與 Kubernetes 的控制平面交互，并且不需要專有 ETCD 實例，節(jié)點也可擴展到 1000+。 (更多詳情^[17])
• 集成 Mirantis Kubernetes 引擎：支持 Mirantis Kubernetes 引擎。 (更多詳情^[18])

什么是 Cilium ？

Cilium 是一個開源軟件，為基于 Kubernetes 的 Linux 容器管理平臺上部署的服務(wù)，透明地提供服務(wù)間的網(wǎng)絡(luò)和 API 連接及安全。

Cilium 底層是基于 Linux 內(nèi)核的新技術(shù) eBPF，可以在 Linux 系統(tǒng)中動態(tài)注入強大的安全性、可見性和網(wǎng)絡(luò)控制邏輯。 Cilium 基于 eBPF 提供了多集群路由、替代 kube-proxy 實現(xiàn)負(fù)載均衡、透明加密以及網(wǎng)絡(luò)和服務(wù)安全等諸多功能。除了提供傳統(tǒng)的網(wǎng)絡(luò)安全之外，eBPF 的靈活性還支持應(yīng)用協(xié)議和 DNS 請求/響應(yīng)安全。同時，Cilium 與 Envoy 緊密集成，提供了基于 Go 的擴展框架。因為 eBPF 運行在 Linux 內(nèi)核中，所以應(yīng)用所有 Cilium 功能，無需對應(yīng)用程序代碼或容器配置進行任何更改。

請參閱 [Cilium 簡介] 部分，了解 Cilium 更詳細的介紹。

OpenTelemetry 支持

新版本增加了對 OpenTelemetry^[19] 的支持。

OpenTelemetry 是一個 CNCF 項目，定義了遙測協(xié)議和數(shù)據(jù)格式，涵蓋了分布式跟蹤、指標(biāo)和日志。該項目提供了 SDK 和運行在 Kubernetes 上的收集器。通常，應(yīng)用程序直接檢測暴露 OpenTelemetry 數(shù)據(jù)，這種檢測最常使用 OpenTelemetry SDK 在應(yīng)用程序內(nèi)實現(xiàn)。OpenTelemetry 收集器用于從集群中的各種應(yīng)用程序收集數(shù)據(jù)，并將其發(fā)送到一個或多個后端。CNCF 項目 Jaeger^[20] 是可用于存儲和呈現(xiàn)跟蹤數(shù)據(jù)的后端之一。

支持 OpenTelemetry 的 Hubble 適配器^[21]是一個附加組件，可以部署到運行 Cilium 的集群上（Cilium 版本最好是 1.11，當(dāng)然也應(yīng)該適用于舊版本）。該適配器是一個嵌入了 Hubble 接收器的 OpenTelemetry 收集器，我們推薦使用 OpenTelemetry Operator^[22] 進行部署（詳見用戶指南^[23]）。Hubble 適配器從 Hubble 讀取流量數(shù)據(jù)，并將其轉(zhuǎn)換為跟蹤和日志數(shù)據(jù)。

Hubble 適配器添加到支持 OpenTelemetry 的集群中，可對網(wǎng)絡(luò)事件和應(yīng)用級別遙測提供有價值的可觀測性。當(dāng)前版本通過 OpenTelemetry SDK 提供了 HTTP 流量和 spans 的關(guān)聯(lián)。

感知拓?fù)涞呢?fù)載均衡

Kubernetes 集群在跨多數(shù)據(jù)中心或可用區(qū)部署是很常見的。這不僅帶來了高可用性好處，而且也帶來了一些操作上的復(fù)雜性。

目前為止，Kubernetes 還沒有一個內(nèi)置的結(jié)構(gòu)，可以基于拓?fù)浼墑e描述 Kubernetes service 端點的位置。這意味著，Kubernetes 節(jié)點基于服務(wù)負(fù)載均衡決策選擇的 service 端點，可能與請求服務(wù)的客戶在不同的可用區(qū)。 這種場景下會帶來諸多副作用，可能是云服務(wù)費用增加，通常由于流量跨越多個可用區(qū)，云提供商會額外收取費用，或請求延遲增加。更廣泛地說，我們需要根據(jù)拓?fù)浣Y(jié)構(gòu)定義 service 端點的位置， 例如，服務(wù)流量應(yīng)該在同一節(jié)點（node）、同一機架（rack）、同一故障分區(qū)（zone）、同一故障地區(qū)（region）、同云提供商的端點之間進行負(fù)載均衡。

Kubernetes v1.21 引入了一個稱為拓?fù)涓兄酚?/span>^[24]的功能來解決這個限制。通過將 service.kubernetes.io/topology-aware-hints 注解被設(shè)置為 auto ，在 service 的 EndpointSlice 對象中設(shè)置端點提示，提示端點運行的分區(qū)。分區(qū)名從節(jié)點的 topology.kubernetes.io/zone 標(biāo)簽獲取。 如果兩個節(jié)點的分區(qū)標(biāo)簽值相同，則被認(rèn)為處于同一拓?fù)浼墑e。

該提示會被 Cilium 的 kube-proxy 替代來處理，并會根據(jù) EndpointSlice 控制器設(shè)置的提示來過濾路由的端點，讓負(fù)載均衡器優(yōu)先選擇同一分區(qū)的端點。

該 Kubernetes 功能目前處于 Alpha 階段，因此需要使用--feature-gate 啟用。更多信息請參考官方文檔^[25]。

Kubernetes APIServer 策略匹配

托管 Kubernetes 環(huán)境，如 GKE、EKS 和 AKS 上，kube-apiserver 的 IP 地址是不透明的。在以前的 Cilium 版本中，沒有提供正規(guī)的方式來編寫 Cilium 網(wǎng)絡(luò)策略，定義對 kube-apiserver 的訪問控制。這涉及一些實現(xiàn)細節(jié)，如：Cilium 安全身份分配，kube-apiserver 是部署在集群內(nèi)，還是部署在集群外。

為了解決這個問題，Cilium 1.11 增加了新功能，為用戶提供一種方法，允許使用專用策略對象定義進出 apiserver 流量的訪問控制。該功能的底層是實體選擇器，能夠解析預(yù)留的 kube-apiserver 標(biāo)簽含義， 并可自動應(yīng)用在與 kube-apiserver 關(guān)聯(lián)的 IP 地址上。

安全團隊將對這個新功能特別感興趣，因為它提供了一個簡單的方法來定義對 pod 的 Cilium 網(wǎng)絡(luò)策略，允許或禁止訪問 kube-apiserver。下面 CiliumNetworkPolicy 策略片段定義了 kube-system 命名空間內(nèi)的所有 Cilium 端點允許訪問 kube-apiserver， 除此之外的所有 Cilium 端點禁止訪問 kube-apiserver。

apiVersion:?cilium.io/v2
kind:?CiliumNetworkPolicy
metadata:
??name:?allow-to-apiserver
??namespace:?kube-system
spec:
??endpointSelector:?{}
??egress:
??-?toEntities:
????-?kube-apiserver

BGP 宣告 Pod CIDR

隨著私有 Kubernetes 環(huán)境的日益關(guān)注，我們希望與現(xiàn)存的數(shù)據(jù)中心網(wǎng)絡(luò)基礎(chǔ)設(shè)施很好地集成，它們通常是基于 BGP 協(xié)議進行路由分發(fā)的。 在上一個版本中，Cilium agent 已經(jīng)開始集成了 BGP 協(xié)議, 可以通過 BGP 向 BGP 路由器發(fā)布負(fù)載均衡器的 service 的 VIP^[26]。

現(xiàn)在，Cilium 1.11 版本還引入了通過 BGP 宣告 Kubernetes Pod 子網(wǎng)的能力。Cilium 可與任何下游互聯(lián)的 BGP 基礎(chǔ)設(shè)施創(chuàng)建一個 BGP 對等體，并通告分配的 Pod IP 地址的子網(wǎng)。這樣下游基礎(chǔ)設(shè)施就可以按照合適方式來分發(fā)這些路由，以使數(shù)據(jù)中心能夠通過各種私有/公共下一跳路由到 Pod 子網(wǎng)。

要開始使用此功能，運行 Cilium 的 Kubernetes 節(jié)點需要讀取 BGP 的 ConfigMap 設(shè)置：

apiVersion:?v1
kind:?ConfigMap
metadata:
??name:?bgp-config
??namespace:?kube-system
data:
??config.yaml:?|
????peers:
??????-?peer-address:?192.168.1.11
????????peer-asn:?64512
????????my-asn:?64512

同時，Cilium 應(yīng)該使用以下參數(shù)進行安裝 ：

$?cilium?install?\
????--config="bgp-announce-pod-cidr=true"

Cilium 安裝完后，它將會向 BGP 路由器發(fā)布 Pod CIDR 范圍，即 192.168.1.11。

下面是最近的 Cilium eCHO episode^[27] 完整演示視頻。

• https://www.youtube.com/watch?v=nsfbFUO8eu4

如果想了解更多，如：如何為 Kubernetes service 配置 LoadBalancer IP 宣告，如何通過 BGP 發(fā)布節(jié)點的 Pod CIDR 范圍，請參見 docs.cilium.io^[28]。

托管 IPv4/IPv6 鄰居發(fā)現(xiàn)

當(dāng) Cilium 啟用 eBPF 替代 kube-proxy 時，Cilium 會執(zhí)行集群節(jié)點的鄰居發(fā)現(xiàn)，以收集網(wǎng)絡(luò)中直接鄰居或下一跳的 L2 地址。這是服務(wù)負(fù)載平衡所必需的，eXpress Data Path^[29] (XDP) 快速路徑支持每秒數(shù)百萬數(shù)據(jù)包的可靠高流量速率。在這種模式下，在技術(shù)上按需動態(tài)解析是不可能的，因為它需要等待相鄰的后端被解析。

在 Cilium 1.10 及更早版本中，cilium agent 本身包含一個 ARP 解析庫，其控制器觸發(fā)發(fā)現(xiàn)和定期刷新新增集群節(jié)點。手動解析的鄰居條目被推送到內(nèi)核并刷新為 PERMANENT 條目，eBPF 負(fù)載均衡器檢索這些條目，將流量定向到后端。cilium agent 的 ARP 解析庫缺乏對 IPv6 鄰居解析支持，并且，PERMANENT 鄰居條目還有許多問題：舉個例子，條目可能變得陳舊，內(nèi)核拒絕學(xué)習(xí)地址更新，因為它們本質(zhì)上是靜態(tài)的，在某些情況下導(dǎo)致數(shù)據(jù)包在節(jié)點間被丟棄。此外，將鄰居解析緊密耦合到 cilium agent 也有一個缺點，在 agent 啟停周期時，不會發(fā)生地址更新的學(xué)習(xí)。

在 Cilium 1.11 中，鄰居發(fā)現(xiàn)功能已被完全重新設(shè)計，Cilium 內(nèi)部的 ARP 解析庫已從 agent 中完全移除?，F(xiàn)在 agent 依賴于 Linux 內(nèi)核來發(fā)現(xiàn)下一跳或同一 L2 域中的主機。Cilium 現(xiàn)在可同時支持 IPv4 和 IPv6 鄰居發(fā)現(xiàn)。對于 v5.16 或更新的內(nèi)核，我們已經(jīng)將今年 Linux Plumbers 會議期間共同組織的 BPF & Networking Summit^[30] 上，提出的“管理”鄰居條目工作提交到上游（part1^[31], part2^[32], part3^[33]）。在這種情況下，agent 將新增集群節(jié)點的 L3 地址下推，并觸發(fā)內(nèi)核定期自動解析它們對應(yīng)的 L2 地址。

這些鄰居條目作為“外部學(xué)習(xí)”和“管理”鄰居屬性，基于 netlink 被推送到內(nèi)核中。雖然舊屬性確保在壓力下這些鄰居條目不會被內(nèi)核的垃圾收集器處理，但是 "管理" 鄰居屬性會，在可行的情況下,內(nèi)核需要自動將這些鄰居屬性保持在 REACHABLE 狀態(tài)。這意思是，如果節(jié)點的上層堆棧沒有主動向后端節(jié)點發(fā)送或接收流量，內(nèi)核可以重新學(xué)習(xí)，將鄰居屬性保持在 REACHABLE 狀態(tài)，然后通過內(nèi)部內(nèi)核工作隊列定期觸發(fā)顯式鄰居解析。對于沒有 "管理" 鄰居屬性功能的舊內(nèi)核，如果需要，agent controller 將定期督促內(nèi)核觸發(fā)新的解決方案。因此，Cilium 不再有 PERMANENT 鄰居條目，并且在升級時，agent 將自動將舊條目遷移到動態(tài)鄰居條目中，以使內(nèi)核能夠在其中學(xué)習(xí)地址更新。

此外，在多路徑路由的情況下，agent 的負(fù)載均衡現(xiàn)在還會在路由查找中查看失敗的下一跳。這意味著，不是替代所有的路由，而是通過查看相鄰子系統(tǒng)信息來避免失敗的路徑。總的來說，對于 Cilium agent 來說，這項工作顯著促進了鄰居管理，并且在網(wǎng)絡(luò)中的節(jié)點或下一跳的鄰居地址發(fā)生變化時，數(shù)據(jù)路徑更易變化。

XDP 對多設(shè)備負(fù)載均衡器的支持

在此版本前，基于 XDP 的負(fù)載均衡器加速只能在單個網(wǎng)絡(luò)設(shè)備上啟用，以便負(fù)載均衡器以發(fā)夾方式（hair-pinning）運行，即數(shù)據(jù)包轉(zhuǎn)發(fā)離開的設(shè)備與數(shù)據(jù)包到達的設(shè)備相同。這個最初的限制是在基于 XDP 層的 kube-proxy 替代^[34]加速中加入的，原因是在 XDP（XDP_REDIRECT）下對多設(shè)備轉(zhuǎn)發(fā)的驅(qū)動支持有限，而同設(shè)備轉(zhuǎn)發(fā)（XDP_TX）是 Linux 內(nèi)核中每個驅(qū)動的 XDP 都支持的。

這意味著多網(wǎng)絡(luò)設(shè)備的環(huán)境下，我們需要使用 tc eBPF 機制，所以必須使用 Cilium 的常規(guī) kube-proxy 替代。這種環(huán)境的一個典型例子是有兩個網(wǎng)絡(luò)設(shè)備的主機，其中一個是公網(wǎng)，接受來自外部對 Kubernetes service 的請求，而另一個是私有網(wǎng)絡(luò)，用于 Kubernetes 節(jié)點之間的集群內(nèi)通信。

由于在現(xiàn)代 LTS Linux 內(nèi)核上，絕大多數(shù) 40G 和 100G 以上的上游網(wǎng)卡驅(qū)動都支持開箱即用的 XDP_REDIRECT，這種限制終于可以解除，因此，這個版本在 Cilium 的 kube-proxy 替代，及 Cilium 的獨立負(fù)載均衡器上，實現(xiàn)了 XDP 層的多網(wǎng)絡(luò)設(shè)備的負(fù)載均衡，這使得在更復(fù)雜的環(huán)境中也能保持?jǐn)?shù)據(jù)包處理性能。

XDP 透明支持 bond 設(shè)備

在很多企業(yè)內(nèi)部或云環(huán)境中，節(jié)點通常使用 bond 設(shè)備，設(shè)置外部流量的雙端口網(wǎng)卡。隨著最近 Cilium 版本的優(yōu)化，如在 XDP 層的 kube-proxy 替代^[35] 或獨立負(fù)載均衡器^[36]，我們從用戶那里經(jīng)常收到的一個問題是 XDP 加速是否可以與 bond 網(wǎng)絡(luò)設(shè)備結(jié)合使用。雖然 Linux 內(nèi)核絕大多數(shù) 10/40/100Gbit/s 網(wǎng)絡(luò)驅(qū)動程序支持 XDP，但它缺乏在 bond（和 802.3ad）模式下透明操作 XDP 的能力。

其中的一個選擇是在用戶空間實現(xiàn) 802.3ad，并在 XDP 程序?qū)崿F(xiàn) bond 負(fù)載均衡，但這對 bond 設(shè)備管理是一個相當(dāng)頗為繁瑣努力，例如：對 netlink 鏈路事件的觀測，另外還需要為編排器的本地和 bond 分別提供單獨的程序。相反，本地內(nèi)核實現(xiàn)解決了這些問題，提供了更多的靈活性，并且能夠處理 eBPF 程序，而不需要改變或重新編譯它們。內(nèi)核負(fù)責(zé)管理 bond 設(shè)備組，可以自動傳播 eBPF 程序。對于 v5.15 或更新的內(nèi)核，我們已經(jīng)在上游（part1^[37], part2^[38]）實現(xiàn)了 XDP 對 bond 設(shè)備的支持。

當(dāng) XDP 程序連接到 bond 設(shè)備時，XDP_TX 的語義等同于 tc eBPF 程序附加到 bond 設(shè)備，這意味著從 bond 設(shè)備傳輸數(shù)據(jù)包使用 bond 配置的傳輸方法來選擇從屬設(shè)備。故障轉(zhuǎn)移和鏈路聚合模式均可以在 XDP 操作下使用。對于通過 XDP_TX 將數(shù)據(jù)包從 bond 設(shè)備上回傳，我們實現(xiàn)了輪循、主動備份、802.3ad 以及哈希設(shè)備選擇。這種情況對于像 Cilium 這樣的發(fā)夾式負(fù)載均衡器來說特別有意義。

基于路由的設(shè)備檢測

1.11 版本顯著的提升了設(shè)備的自動檢測，可用于 使用 eBPF 替代 kube-proxy^[39]、帶寬管理器^[40]和主機防火墻^[41]。

在早期版本中，Cilium 自動檢測的設(shè)備需要有默認(rèn)路由的設(shè)備，和有 Kubernetes NodeIP 的設(shè)備。展望未來，現(xiàn)在設(shè)備檢測是根據(jù)主機命名空間的所有路由表的條目來進行的。也就是說，所有非橋接的、非 bond 的和有全局單播路由的非虛擬的設(shè)備，現(xiàn)在都能被檢測到。

通過這項改進，Cilium 現(xiàn)在應(yīng)該能夠在更復(fù)雜的網(wǎng)絡(luò)設(shè)置中自動檢測正確的設(shè)備，而無需使用 devices 選項手動指定設(shè)備。使用后一個選項時，無法對設(shè)備名稱進行一致性的命名規(guī)范，例如：無法使用共同前綴正則表達式對設(shè)備命名。

服務(wù)后端流量的優(yōu)雅終止

Kubernetes 可以出于多種原因終止 Pod，如滾動更新、縮容或用戶發(fā)起的刪除。在這種情況下，重要的是要優(yōu)雅地終止與 Pod 的活躍連接，讓應(yīng)用程序有時間完成請求以最大程度地減少中斷。異常連接終止會導(dǎo)致數(shù)據(jù)丟失，或延遲應(yīng)用程序的恢復(fù)。

Cilium agent 通過 "EndpointSlice" API 監(jiān)聽 service 端點更新。當(dāng)一個 service 端點被終止時，Kubernetes 為該端點設(shè)置 terminating 狀態(tài)。然后，Cilium agent 刪除該端點的數(shù)據(jù)路徑狀態(tài)，這樣端點就不會被選擇用于新的請求，但該端點正在服務(wù)的當(dāng)前連接，可以在用戶定義的寬限期內(nèi)被終止。

同時，Kubernetes 告知容器運行時向服務(wù)的 Pod 容器發(fā)送 SIGTERM 信號，并等待終止寬限期的到來。然后，容器應(yīng)用程序可以啟動活躍連接的優(yōu)雅終止，例如，關(guān)閉 TCP 套接字。一旦寬限期結(jié)束，Kubernetes 最終通過 SIGKILL 信號對仍在 Pod 容器中運行的進程觸發(fā)強制關(guān)閉。這時，agent 也會收到端點的刪除事件，然后完全刪除端點的數(shù)據(jù)路徑狀態(tài)。但是，如果應(yīng)用 Pod 在寬限期結(jié)束前退出，Kubernetes 將立即發(fā)送刪除事件，而不管寬限期設(shè)置。

更多細節(jié)請關(guān)注 docs.cilium.io^[42] 中的指南。

Egress 出口網(wǎng)關(guān)的優(yōu)化

簡單的場景中，Kubernetes 應(yīng)用只與其他 Kubernetes 應(yīng)用進行通信，因此流量可通過網(wǎng)絡(luò)策略等機制進行控制。但現(xiàn)實世界情況并非總是如此，例如：私有部署的一些應(yīng)用程序沒有被容器化，Kubernetes 應(yīng)用程序需要與集群外的服務(wù)進行通信。這些傳統(tǒng)服務(wù)通常配置的是靜態(tài) IP，并受到防火墻規(guī)則的保護。那么在此種情況下，應(yīng)該如何對流量控制和審計呢？

Egress 出口 IP 網(wǎng)關(guān)功能在 Cilium 1.10^[43] 中被引入，通過 Kubernetes 節(jié)點充當(dāng)網(wǎng)關(guān)用于集群出口流量來解決這類問題。用戶使用策略來指定哪些流量應(yīng)該被轉(zhuǎn)發(fā)到網(wǎng)關(guān)節(jié)點，以及如何轉(zhuǎn)發(fā)流量。這種情況下，網(wǎng)關(guān)節(jié)點將使用靜態(tài)出口 IP 對流量進行偽裝，因此可以在傳統(tǒng)防火墻建立規(guī)則。

apiVersion:?cilium.io/v2alpha1
kind:?CiliumEgressNATPolicy
metadata:
??name:?egress-sample
spec:
??egress:
????-?podSelector:
??????matchLabels:
????????app:?test-app
??destinationCIDRs:
????-?1.2.3.0/24
??egressSourceIP:?20.0.0.1

在上面的示例策略中，帶有 app: test-app 標(biāo)簽的 Pod 和目標(biāo) CIDR 為 1.2.3.0/24 的流量，需要通過 20.0.0.1 網(wǎng)關(guān)節(jié)點的出口 IP（SNAT）與集群外部通信。

在 Cilium 1.11 開發(fā)周期中，我們投入了大量精力來穩(wěn)定出口網(wǎng)關(guān)功能，使其可投入生產(chǎn)?，F(xiàn)在， 出口網(wǎng)關(guān)現(xiàn)在可以工作在直接路由^[44]，區(qū)分內(nèi)部流量^[45]（即 Kubernetes 重疊地址的 CIDR 的出口策略）及在不同策略中使用相同出口 IP^[46]下。一些問題，如回復(fù)被錯誤描述為出口流量^[47]和其他^[48]等已經(jīng)修復(fù)，同時測試也得到了改進，以便及早發(fā)現(xiàn)潛在的問題。

Kubernetes Cgroup 增強

Cilium 使用 eBPF 替代 kube-proxy ^[49] 作為獨立負(fù)載均衡器^[50]的優(yōu)勢之一是能夠?qū)?eBPF 程序附加到 socket hooks 上，例如 connect(2)、bind(2)、sendmsg(2) 以及其他各種相關(guān)的系統(tǒng)調(diào)用，以便透明地將本地的應(yīng)用程序連接到后端服務(wù)。但是這些程序只能被附加到 cgroup v2。雖然 Kubernetes 正在努力遷移到 cgroup v2，但目前絕大多數(shù)用戶的環(huán)境都是 cgroup v1 和 v2 混合使用。

Linux 在內(nèi)核的 socket 對象中標(biāo)記了 socket 與 cgroup 的關(guān)系，并且由于 6 年前的一個設(shè)定，cgroup v1 和 v2 的 socket 標(biāo)簽是互斥的。這就意味著，如果一個 socket 是以 cgroup v2 成員身份創(chuàng)建的，但后來通過具有 cgroup v1 成員身份的 net_prio 或 net_cls 控制器進行了標(biāo)記，那么 cgroup v2 就不會執(zhí)行附加在 Pod 子路徑上的程序，而是回退執(zhí)行附加到 cgroup v2 層次結(jié)構(gòu) (hierarchy) 根部的 eBPF 程序。這樣就會導(dǎo)致一個很嚴(yán)重的后果，如果連 cgroup v2 根部都沒有附加程序，那么整個 cgroup v2 層次結(jié)構(gòu) (hierarchy) 都會被繞過。

現(xiàn)如今，cgroup v1 和 v2 不能并行運行的假設(shè)不再成立，具體可參考今年早些時候的 Linux Plumbers 會議演講^[51]。只有在極少數(shù)情況下，當(dāng)被標(biāo)記為 cgroup v2 成員身份的 eBPF 程序附加到 cgroup v2 層次結(jié)構(gòu)的子系統(tǒng)時，Kubernetes 集群中的 cgroup v1 網(wǎng)絡(luò)控制器才會繞過該 eBPF 程序。為了在數(shù)據(jù)包處理路徑上的盡量前面（early）的位置解決這個問題，Cilium 團隊最近對 Linux 內(nèi)核進行了修復(fù)，實現(xiàn)了在所有場景下允許兩種 cgroup 版本 (part1^[52], part2^[53]) 之間相互安全操作。這個修復(fù)不僅使 Cilium 的 cgroup 操作完全健壯可靠，而且也造福了 Kubernetes 中所有其他 eBPF cgroup 用戶。

此外，Kubernetes 和 Docker 等容器運行時最近開始陸續(xù)宣布支持 cgroup v2。在 cgroup v2 模式下，Docker 默認(rèn)會切換到私有 cgroup 命名空間^[54]，即每個容器（包括 Cilium）都在自己的私有 cgroup 命名空間中運行。Cilium 通過確保 eBPF 程序附加到正確的 cgroup 層次結(jié)構(gòu)的 socket hooks 上，使 Cilium 基于套接字的負(fù)載均衡在 cgroup v2 環(huán)境中能正常工作。

增強負(fù)載均衡器的可擴展性

主要外部貢獻者：Weilong Cui (Google)

最近的測試表明，對于運行著 Cilium 且 Kubernetes Endpoints 超過 6.4 萬的大型 Kubernetes 環(huán)境，Service 負(fù)載均衡器會受到限制。有兩個限制因素：

• Cilium 使用 eBPF 替代 kube-proxy 的獨立負(fù)載均衡器的本地后端 ID 分配器仍被限制在 16 位 ID 空間內(nèi)。
• Cilium 用于 IPv4 和 IPv6 的 eBPF datapath 后端映射所使用的密鑰類型被限制在 16 位 ID 空間內(nèi)。

為了使 Kubernetes 集群能夠擴展到超過 6.4 萬 Endpoints，Cilium 的 ID 分配器以及相關(guān)的 datapath 結(jié)構(gòu)已被轉(zhuǎn)換為使用 32 位 ID 空間。

Cilium Endpoint Slices

主要外部貢獻者：Weilong Cui (Google), Gobinath Krishnamoorthy (Google)

在 1.11 版本中，Cilium 增加了對新操作模式的支持，該模式通過更有效的 Pod 信息廣播方式大大提高了 Cilium 的擴展能力。

之前，Cilium 通過 watch CiliumEndpoint (CEP) 對象來廣播 Pod 的 IP 地址和安全身份信息，這種做法在可擴展性方面會帶來一定的挑戰(zhàn)。每個 CEP 對象的創(chuàng)建/更新/刪除都會觸發(fā) watch 事件的組播，其規(guī)模與集群中 Cilium-agent 的數(shù)量呈線性關(guān)系，而每個 Cilium-agent 都可以觸發(fā)這樣的扇出動作。如果集群中有 N 個節(jié)點，總 watch 事件和流量可能會以 N^2 的速率二次擴展。

Cilium 1.11 引入了一個新的 CRD CiliumEndpointSlice (CES)，來自同一命名空間下的 CEPs 切片會被 Operator 組合成 CES 對象。在這種模式下，Cilium-agents 不再 watch CEP，而是 watch CES，大大減少了需要經(jīng)由 kube-apiserver 廣播的 watch 事件和流量，進而減輕 kube-apiserver 的壓力，增強 Cilium 的可擴展性。

由于 CEP 大大減輕了 kube-apiserver 的壓力，Cilium 現(xiàn)在已經(jīng)不再依賴專用的 ETCD 實例（KVStore 模式）。對于 Pod 數(shù)量劇烈變化的集群，我們?nèi)匀唤ㄗh使用 KVStore，以便將 kube-apiserver 中的處理工作卸載到 ETCD 實例中。

這種模式權(quán)衡了“更快地傳播 Endpoint 信息”和“擴展性更強的控制平面”這兩個方面，并力求雨露均沾。注意，與 CEP 模式相比，在規(guī)模較大時，如果 Pod 數(shù)量劇烈變化（例如大規(guī)模擴縮容），可能會產(chǎn)生較高的 Endpoint 信息傳播延遲，從而影響到遠程節(jié)點。

GKE 最早采用了 CES，我們在 GKE 上進行了一系列“最壞情況”規(guī)模測試，發(fā)現(xiàn) Cilium 在 CES 模式下的擴展性要比 CEP 模式強很多。從 1000 節(jié)點規(guī)模的負(fù)載測試來看，啟用 CES 后，watch 事件的峰值從 CEP 的 18k/s 降低到 CES 的 8k/s，watch 流量峰值從 CEP 的 36.6Mbps 降低到 CES 的 18.1Mbps。在控制器節(jié)點資源使用方面，它將 CPU 的峰值使用量從 28 核/秒減少到 10.5 核/秒。

詳情請參考 Cilium 官方文檔^[55]。

Kube-Proxy-Replacement 支持 Istio

許多用戶在 Kubernetes 中使用 eBPF 自帶的負(fù)載均衡器來替代 kube-proxy^[56]，享受基于 eBPF 的 datapath 帶來的高效處理方式^[57]，避免了 kube-proxy 隨著集群規(guī)模線性增長的 iptables 規(guī)則鏈條。

eBPF 對 Kubernetes Service 負(fù)載均衡的處理在架構(gòu)上分為兩個部分^[58]：

• 處理進入集群的外部服務(wù)流量（南北方向）
• 處理來自集群內(nèi)部的服務(wù)流量（東西方向）

在 eBPF 的加持下，Cilium 在南北方向已經(jīng)實現(xiàn)了盡可能靠近驅(qū)動層（例如通過 XDP）完成對每個數(shù)據(jù)包的處理；東西流量的處理則盡可能靠近 eBPF 應(yīng)用層，處理方式是將應(yīng)用程序的請求（例如 TCP connect(2)）從 Service 虛擬 IP 直接“連接”到后端 IP 之一，以避免每個數(shù)據(jù)包的 NAT 轉(zhuǎn)換成本。

Cilium 的這種處理方式適用于大多數(shù)場景，但還是有一些例外，比如常見的服務(wù)網(wǎng)格解決方案（Istio 等）。Istio 依賴 iptables 在 Pod 的網(wǎng)絡(luò)命名空間中插入額外的重定向規(guī)則，以便應(yīng)用流量在離開 Pod 進入主機命名空間之前首先到達代理 Sidecar（例如 Envoy），然后通過 SO_ORIGINAL_DST 從其內(nèi)部 socket 直接查詢^[59] Netfilter 連接跟蹤器，以收集原始服務(wù)目的地址。

所以在 Istio 等服務(wù)網(wǎng)格場景下，Cilium 改進了對 Pod 之間（東西方向）流量的處理方式，改成基于 eBPF 的 DNAT 完成對每個數(shù)據(jù)包的處理，而主機命名空間內(nèi)的應(yīng)用仍然可以使用基于 socket 的負(fù)載均衡器，以避免每個數(shù)據(jù)包的 NAT 轉(zhuǎn)換成本。

要想開啟這個特性，只需在新版 Cilium agent 的 Helm Chart 中設(shè)置 bpf-lb-sock-hostns-only: true 即可。詳細步驟請參考 Cilium 官方文檔^[60]。

特性增強與棄用

以下特性得到了進一步增強：

• 主機防火墻 (Host Firewall) 從測試版 (beta) 轉(zhuǎn)為穩(wěn)定版 (stable)。主機防火墻通過允許 CiliumClusterwideNetworkPolicies^[61] 選擇集群節(jié)點來保護主機網(wǎng)絡(luò)命名空間。自從引入主機防火墻功能以來，我們已經(jīng)大大增加了測試覆蓋率，并修復(fù)了部分錯誤。我們還收到了部分社區(qū)用戶的反饋，他們對這個功能很滿意，并準(zhǔn)備用于生產(chǎn)環(huán)境。

以下特性已經(jīng)被棄用：

• Consul 之前可以作為 Cilium 的 KVStore 后端，現(xiàn)已被棄用，推薦使用更經(jīng)得起考驗的 Etcd 和 Kubernetes 作為 KVStore 后端。之前 Cilium 的開發(fā)者主要使用 Consul 進行本地端到端測試，但在最近的開發(fā)周期中，已經(jīng)可以直接使用 Kubernetes 作為后端來測試了，Consul 可以退休了。
• IPVLAN 之前用來作為 veth 的替代方案，用于提供跨節(jié)點 Pod 網(wǎng)絡(luò)通信。在 Cilium 社區(qū)的推動下，大大改進了 Linux 內(nèi)核的性能，目前 veth 已經(jīng)和 IPVLAN 性能相當(dāng)。具體可參考這篇文章：eBPF 主機路由^[62]。
• 策略追蹤 (Policy Tracing) 在早期 Cilium 版本中被很多 Cilium 用戶使用，可以通過 Pod 中的命令行工具 cilium policy trace 來執(zhí)行。然而隨著時間的推移，它沒有跟上 Cilium 策略引擎的功能進展。Cilium 現(xiàn)在提供了更好的工具來追蹤 Cilium 的策略，例如網(wǎng)絡(luò)策略編輯器^[63]和 Policy Verdicts^[64]。

引用鏈接