轉(zhuǎn)載自公眾號(hào)：云計(jì)算地理學(xué)101報(bào)告

ID：gh_f5828f903045

原文地址：

https://mp.weixin.qq.com/s?__biz=Mzg2MDY3NjA3NQ==&mid=2247483974&idx=1&sn=ef91cddc0314b654b9d4839727bfd641&chksm=ce2388c2f95401d4a7f7778f731be4e2e42b06dd7fb02f7dc14b0dc5fae15370b54200b077f1&token=1060090878&lang=zh_CN#rd

Cilium 是一個(gè)開源項(xiàng)目垃瞧，旨在透明地提供和保護(hù)使用 Kubernetes 以及其他容器編排平臺(tái)部署的應(yīng)用程序之間的網(wǎng)絡(luò)連接还最。Cilium 的基礎(chǔ)是 eBPF纽绍，它是一種新的 Linux 內(nèi)核技術(shù)梅鹦，能夠?qū)?qiáng)大的安全性晌畅、可見性和網(wǎng)絡(luò)控制邏輯動(dòng)態(tài)插入到 Linux 內(nèi)核中，實(shí)現(xiàn)了在不更改應(yīng)用程序代碼或容器配置的情況下應(yīng)用和更新 Cilium 安全策略抵恋。

Cilium Service Mesh 的第一個(gè)版本已經(jīng)可以在 Cilium 1.12 版本中使用碳默，它允許用戶通過配置選項(xiàng)選擇在沒有 Sidecar 的情況下運(yùn)行服務(wù)網(wǎng)格，同時(shí)支持各種控制平面逮京。它補(bǔ)充了現(xiàn)有的基于 Sidecar 的 Istio 集成方式卿堂，這樣做的目標(biāo)是為了降低服務(wù)網(wǎng)格層的復(fù)雜性和開銷。用戶可以在運(yùn)行服務(wù)網(wǎng)格時(shí)根據(jù)自己的需要懒棉，以最能滿足其平臺(tái)要求的方式來選擇是否帶有 Sidecar草描。

企業(yè)級(jí)服務(wù)網(wǎng)格

隨著越來越多的企業(yè)采用 Kubernetes，我們看到企業(yè)級(jí)服務(wù)網(wǎng)格的需求也變得越來越重要策严。這給最初由 Web 應(yīng)用程序團(tuán)隊(duì)衍生出來的服務(wù)網(wǎng)格概念帶來了許多新的企業(yè)網(wǎng)絡(luò)需求穗慕，這些新的需求使 Kubernetes 網(wǎng)絡(luò)/CNI 層和服務(wù)網(wǎng)格層更緊密地結(jié)合在一起，并產(chǎn)生了一個(gè)新的服務(wù)層級(jí)妻导，用于將兩者組合起來逛绵，同時(shí)提供以下功能：

1. 公共云和本地基礎(chǔ)設(shè)施集成：與 Kubernetes 類似怀各，服務(wù)網(wǎng)格主要專注于支持在公共云中部署的基礎(chǔ)設(shè)施。隨著企業(yè)開始考慮采用這一技術(shù)术浪，對(duì)本地的基礎(chǔ)設(shè)施以及將云和本地連接在一起的需求正在迅速增長瓢对。在多云和多集群的情況下，屏蔽底層基礎(chǔ)設(shè)施服務(wù)添吗，提供跨云連接的安全性和可觀察性沥曹。
2. 網(wǎng)絡(luò)層的控制：網(wǎng)絡(luò)層控制的關(guān)鍵不僅是與本地現(xiàn)有企業(yè)網(wǎng)絡(luò)組件集成，而且還必須滿足云中網(wǎng)絡(luò)分割碟联、加密和可見性的合規(guī)性要求妓美。這包括提供網(wǎng)絡(luò)策略、出口網(wǎng)關(guān)鲤孵、透明加密壶栋、BGP、SRv6 以及與傳統(tǒng)防火墻集成等功能普监。

3. 應(yīng)用程序協(xié)議級(jí)別的控制：需要了解 HTTP 和 gRPC 等應(yīng)用程序協(xié)議贵试，以通過實(shí)現(xiàn)流量管理、金絲雀發(fā)布凯正、跟蹤和 L7 授權(quán)等功能來滿足現(xiàn)代應(yīng)用程序開發(fā)原則的要求毙玻。這是通過實(shí)現(xiàn)像 Ingress 和 APIGateway 這樣的標(biāo)準(zhǔn)來實(shí)現(xiàn)的。

作為 Isovalent廊散，我們創(chuàng)建了非常成功的 CNCF 項(xiàng)目 Cilium桑滩，它已成為云原生網(wǎng)絡(luò)和安全的事實(shí)標(biāo)準(zhǔn)。Cilium 正在為 Adobe允睹、Bell Canada运准、Capital One 和 IKEA 等主要企業(yè)的基礎(chǔ)設(shè)施以及 Google Cloud 和 AWS 這樣的 Kubernetes 托管平臺(tái)提供支持，并且也是眾多 Kubernetes 發(fā)行版中的默認(rèn) CNI缭受。隨著 Cilium Service Mesh 的引入胁澳，我們正在擴(kuò)展應(yīng)用協(xié)議級(jí)別的功能。

什么是服務(wù)網(wǎng)格米者？

隨著分布式應(yīng)用程序的引入韭畸，額外的可見性、連接性和安全性需求也出現(xiàn)了塘雳。應(yīng)用程序組件在不受信任的網(wǎng)絡(luò)上跨云和服務(wù)邊界進(jìn)行通信時(shí)陆盘，需要負(fù)載均衡來解析應(yīng)用程序協(xié)議，這個(gè)過程中彈性變得至關(guān)重要败明，同時(shí)安全性方面也必須改變?yōu)榘l(fā)送方和接收方可以相互驗(yàn)證身份的模型。在分布式應(yīng)用程序的早期太防，這些需求是通過將所需的邏輯直接嵌入到應(yīng)用程序中來解決的妻顶。服務(wù)網(wǎng)格將這些特性從應(yīng)用程序中提取出來酸员，并將它們作為基礎(chǔ)設(shè)施的一部分提供給所有應(yīng)用程序使用，因此不再需要更改每個(gè)應(yīng)用程序讳嘱。

現(xiàn)在看一下服務(wù)網(wǎng)格的特性幔嗦，可以總結(jié)如下：

1. 彈性連接：服務(wù)到服務(wù)的通信必須能夠跨越云、集群等邊界沥潭。通信必須具有彈性和容錯(cuò)性邀泉。
2. L7 流量管理：負(fù)載均衡、速率限制和彈性必須支持 L7（HTTP钝鸽、REST汇恤、gRPC、WebSocket 等）拔恰。
3. 基于身份的安全性：依靠網(wǎng)絡(luò)標(biāo)識(shí)符來實(shí)現(xiàn)安全性已經(jīng)不夠了因谎，發(fā)送和接收服務(wù)必須能夠基于身份而不是網(wǎng)絡(luò)標(biāo)識(shí)符來驗(yàn)證彼此。
4. 可觀察性和跟蹤：跟蹤（Tracing）和指標(biāo)（Metrics）形式的可觀察性對(duì)于理解颜懊、監(jiān)控應(yīng)用程序穩(wěn)定性财岔、性能和可用性至關(guān)重要。

5. 透明度：功能必須以透明的方式提供給應(yīng)用程序河爹，即無需更改應(yīng)用程序代碼匠璧。

為什么選擇 Cilium 服務(wù)網(wǎng)格？

從早期開始咸这，Cilium 就通過在網(wǎng)絡(luò)層和應(yīng)用程序協(xié)議層運(yùn)行來提供連接性夷恍、負(fù)載均衡、安全性和可觀察性炊苫，從而很好的與服務(wù)網(wǎng)格概念保持一致裁厅。對(duì)于所有網(wǎng)絡(luò)處理（包括 IP、TCP 和 UDP 等協(xié)議）侨艾，Cilium 使用 eBPF 作為高效的內(nèi)核數(shù)據(jù)路徑执虹。應(yīng)用層的 HTTP、Kafka唠梨、gRPC 和 DNS 等協(xié)議使用 Envoy 等代理進(jìn)行解析袋励。最后，對(duì)于超出 Cilium 功能的服務(wù)網(wǎng)格用例当叭，Cilium 提供了 Istio 集成茬故。它將所有 Istio 功能帶入 Cilium，同時(shí)允許 Cilium 通過 Istio 管理的 Sidecar 執(zhí)行 L7 策略蚁鳖。Cilium 也提供了一些自動(dòng)化功能磺芭，例如縮短 Sidecar 網(wǎng)絡(luò)注入路徑，防止暴露應(yīng)用程序和 Sidecar 之間的未加密數(shù)據(jù)等醉箕。

當(dāng) Cilium 社區(qū)開始討論和辯論提供 Cilium 原生服務(wù)網(wǎng)格的話題時(shí)钾腺，我們進(jìn)行了各種最終用戶調(diào)查并聽取了客戶的意見徙垫。我們收到的反饋是一致且明確的：

1. Kubernetes-native：我們的團(tuán)隊(duì)已經(jīng)知道如何使用 Kubernetes。我們希望在不學(xué)習(xí)很多新概念的情況下使用服務(wù)網(wǎng)格功能放棒，并提供 Kubernetes 原生用戶體驗(yàn)姻报，就像 Cilium Cluster Mesh 使用 Kubernetes 服務(wù)和 NetworkPolicy 來操作多集群連接以及安全策略一樣。

2. 降低復(fù)雜性和開銷：Sidecar 的復(fù)雜性和開銷對(duì)用戶的影響是非常嚴(yán)重的间螟。為我們提供一個(gè)簡單的數(shù)據(jù)路徑模型吴旋，在支持任意網(wǎng)絡(luò)協(xié)議的同時(shí)避免開銷。Kelsey Hightower 將此稱為“服務(wù)混亂”厢破。

選擇 Sidecar 或 Sidecar-free

在 Cilium Service Mesh 的第一個(gè)版本中荣瑟，用戶現(xiàn)在可以選擇運(yùn)行帶有或不帶有 Sidecar 的服務(wù)網(wǎng)格。何時(shí)使用哪種模型能夠達(dá)到最佳效果取決于各種因素溉奕，包括開銷褂傀、資源管理、故障域和安全考慮加勤。事實(shí)上仙辟，這種權(quán)衡與虛擬機(jī)和容器非常相似。VM 提供更嚴(yán)格的隔離鳄梅，容器更輕量叠国，能夠共享資源并提供可用資源的公平分配。正因?yàn)槿绱舜魇萜魍ǔ?huì)增加部署密度粟焊，同時(shí)還要權(quán)衡額外的安全性和資源管理挑戰(zhàn)。使用 Cilium Service Mesh孙蒙，你可以在你的平臺(tái)上同時(shí)使用這兩種方式项棠，甚至可以混合使用。

Sidecar 的性能影響

除了避免需要在 Sidecar 模型中運(yùn)行的大量代理之外挎峦，無 Sidecar 模型的一個(gè)顯著優(yōu)勢(shì)是我們可以避免在任何連接之間運(yùn)行兩個(gè)代理香追。這可以通過在網(wǎng)絡(luò)/節(jié)點(diǎn)級(jí)別使用 Cilium 進(jìn)行加密和身份驗(yàn)證或使用即將推出的新 mTLS 模型來實(shí)現(xiàn)，該模型將身份驗(yàn)證與傳輸分開（更多細(xì)節(jié)可參閱：使用 Cilium 服務(wù)網(wǎng)格的下一代相互身份驗(yàn)證[1]）

網(wǎng)絡(luò)路徑中的代理數(shù)量和 Envoy 過濾器的類型對(duì)性能有顯著影響坦胶。上面的基準(zhǔn)測試說明了運(yùn)行 Cilium Envoy 過濾器（棕色）的單個(gè) Envoy 代理與運(yùn)行 Istio Envoy 過濾器（藍(lán)色）的雙向 Envoy 模型相比的 HTTP 處理延遲成本透典。黃色是沒有代理且沒有執(zhí)行 HTTP 處理的基線延遲。

使用 eBPF-Native

除了刪除 Sidecar 的選項(xiàng)外顿苇，Cilium Service Mesh 還可以直接在 eBPF 中執(zhí)行各種服務(wù)網(wǎng)格功能峭咒，從而進(jìn)一步減少開銷。一般情況下纪岁，盡可能在 eBPF 中以較低的成本執(zhí)行處理凑队。如果 eBPF 無法處理請(qǐng)求，例如當(dāng)需要拼接連接幔翰、限制請(qǐng)求的速率或執(zhí)行 TLS 終止時(shí)顽决，則處理會(huì)退回到運(yùn)行在 Sidecar 或 Sidecar-free 模型中的 Envoy短条。這提供了兩全其美的方式——在一般情況下進(jìn)行 eBPF 處理以提高性能和減少延遲导匣，并始終能夠根據(jù)需要回退到 Envoy才菠。

一個(gè)特別強(qiáng)大的用例是支持跟蹤 HTTP/2 的可見性和指標(biāo)用例，例如贡定，使用 Prometheus 和 Grafana 構(gòu)建黃金信號(hào)儀表板赋访。能夠顯著降低延遲和計(jì)算方面的成本：

您可以在上面看到測量 P95 延遲的 HTTP 請(qǐng)求/響應(yīng)基準(zhǔn)。它比較了運(yùn)行基于 eBPF 的 HTTP/2 解析器（棕色）缓待、Sidecar 方法（藍(lán)色）和未啟用可見性的基線（黃色）時(shí)對(duì)延遲的影響蚓耽。基于 eBPF 的 HTTP/2 解析器在 Isovalent Cilium Enterprise 中可用旋炒。Sidecar 代理的選擇并不重要（本例中使用了 Envoy）步悠，但我們測試的其他代理的結(jié)果幾乎相同，因?yàn)橹饕杀驹从诖淼淖⑷胍约敖K止連接和遍歷上下游之間的數(shù)據(jù)瘫镇。

在 eBPF 中可以做什么鼎兽？什么時(shí)候需要代理？

下表列出了最常見的服務(wù)網(wǎng)格特性铣除，以及它們是否需要通過在 Sidecar 或 Sidecar-free 模式下運(yùn)行的代理進(jìn)行路由：

擴(kuò)展控制平面

Kubernetes 一直非常擅長在不同的復(fù)雜程度提供不同的抽象谚咬，而 Cilium Service Mesh 也允許用戶這樣做，這能夠解決用戶的第二大需求尚粘，即降低采用服務(wù)網(wǎng)格時(shí)的復(fù)雜度和學(xué)習(xí)曲線择卦。除了現(xiàn)有的 Istio 集成之外，我們正在擴(kuò)展支持的服務(wù)網(wǎng)格控制平面的數(shù)量郎嫁，以將新的無 Sidecar 數(shù)據(jù)路徑選項(xiàng)引入現(xiàn)有的服務(wù)網(wǎng)格標(biāo)準(zhǔn)秉继。

服務(wù)網(wǎng)格控制平面支持情況如下：

1. Istio（已支持）

Istio 是已經(jīng)支持的服務(wù)網(wǎng)格控制平面，它目前需要使用基于 Sidecar 的模式運(yùn)行泽铛。如果有興趣尚辑，我們正在考慮將無 Sidecar 的數(shù)據(jù)路徑引入 Istio。如果您認(rèn)為這很有趣厚宰，請(qǐng)與我們聯(lián)系腌巾。

1. Prometheus / OpenTelemetry（已支持）

L7 可觀測性一直是 Cilium 的一個(gè)特點(diǎn)。使用標(biāo)準(zhǔn) Prometheus 和 OpenTelemetry 以指標(biāo)和跟蹤數(shù)據(jù)的形式提供可見性铲觉。

1. Kubernetes Ingress（新增支持）

Cilium Service Mesh 的第一個(gè)版本包括一個(gè)完全兼容的 Kubernetes Ingress 控制器澈蝙，使應(yīng)用程序團(tuán)隊(duì)能夠通過標(biāo)準(zhǔn)化的 Kubernetes 流量入口使用 L7 負(fù)載均衡和流量管理功能。Kubernetes Ingress 負(fù)載均衡可以應(yīng)用于集群入口撵幽、集群內(nèi)部和跨集群的流量灯荧。（請(qǐng)參閱 Kubernetes Ingress 入門[2]）

1. Envoy 配置 CRD（新增支持）

一個(gè)新的令人興奮的 Envoy 配置 CRD 可用，使整個(gè) Envoy 代理功能可以在網(wǎng)絡(luò)中的任何地方使用盐杂。這使用戶能夠直接編寫 Envoy 配置逗载，并將其應(yīng)用到網(wǎng)絡(luò)中的任何地方哆窿，以啟用甚至沒有被 Istio 等服務(wù)網(wǎng)格覆蓋的高級(jí)用例。

1. Gateway API（正在進(jìn)行中）

我們正在努力支持 Kubernetes Gateway API 標(biāo)準(zhǔn)作為下一個(gè)受支持的控制平面厉斟。它在 Kubernetes Ingress 之上帶來了額外的功能挚躯，并且對(duì)于許多應(yīng)用程序和平臺(tái)團(tuán)隊(duì)來說可能是一個(gè)可行的選擇，因?yàn)樗诠δ芎蛷?fù)雜性之間取得了很好的平衡擦秽。

1. SPIFFE（規(guī)劃中）

對(duì) SPIFFE 的支持已經(jīng)在規(guī)劃中码荔，可以提供服務(wù)證書和基于代理的 mTLS。

適用于任何網(wǎng)絡(luò)協(xié)議的 mTLS

通過將身份驗(yàn)證握手與負(fù)載傳輸分開感挥，我們可以使用 TLS 1.3 作為握手協(xié)議缩搅，同時(shí)依賴 IPsec 或 WireGuard 作為性能更好、更透明的負(fù)載通道：

這兩種模型實(shí)現(xiàn)了許多出色的特性：

1. 不再需要終止連接：基于 Sidecar 的方法需要將每個(gè) TCP 連接轉(zhuǎn)換為 3 個(gè)階段以注入 TLS触幼。無 Sidecar 方法不需要終止或操作連接硼瓣。
2. 無需注入 Sidecar：服務(wù)的身份驗(yàn)證可以由單個(gè)節(jié)點(diǎn)代理執(zhí)行，無需運(yùn)行額外的代理置谦。在使用 Cilium 的情況下堂鲤，這個(gè)代理默認(rèn)存在并且能夠獲取所有需要的上下文。這簡化了管理霉祸、改善了資源占用并提高了可擴(kuò)展性筑累。
3. 支持非 TCP 和多播：在受益于 TLS 1.3 的強(qiáng)大特性（例如低延遲握手）的同時(shí)，能夠支持 UDP丝蹭、ICMP 和任何其他 IP 可承載的協(xié)議慢宗。
4. 支持現(xiàn)有的身份和證書管理：任何基于 mTLS 的身份驗(yàn)證控制平面或身份管理系統(tǒng)都可以插入并用于為服務(wù)提供證書。這包括 SPIFFE奔穿、Vault镜沽、SMI、Istio 等贱田。

5. 握手緩存和定期身份驗(yàn)證：握手可以一次完成并進(jìn)行緩存缅茉，在經(jīng)過身份驗(yàn)證的服務(wù)之間進(jìn)行訪問時(shí)不會(huì)引入額外的延遲。另外男摧，可以定期進(jìn)行身份驗(yàn)證蔬墩，以定期重新對(duì)服務(wù)進(jìn)行身份驗(yàn)證。

結(jié)論

我們對(duì) Cilium Service Mesh 的初始版本發(fā)布感到興奮耗拓，它在 Cilium 現(xiàn)有功能的基礎(chǔ)之上拇颅，還為用戶提供了更多的選擇：

1. 控制平面：選擇不同的控制平面以實(shí)現(xiàn)復(fù)雜性和豐富性的平衡。從 Ingress 和 Gateway API 等簡單的選項(xiàng)乔询，到 Istio 豐富選項(xiàng)樟插，再到通過 Envoy CRD 發(fā)揮 Envoy 的全部功能。

2. Sidecar vs Sidecar-free：可以選擇帶或不帶 Sidecar 的模式。具有 VM 風(fēng)格資源隔離的 Sidecar 模式會(huì)增加成本和開銷黄锤，具有容器風(fēng)格的不帶 Sidecar 模式需要管理共享資源的使用搪缨。

參考資料

[1] Next-Generation Mutual Authentication with Cilium Service Mesh: https://isovalent.com/blog/post/2022-05-03-servicemesh-security/

[2] Getting Started with Kubernetes Ingress: https://docs.cilium.io/en/latest/gettingstarted/servicemesh/ingress/

[3] Cilium 1.12 – Ingress, Multi-Cluster, Service Mesh, External Workloads, and much more: https://isovalent.com/blog/post/cilium-release-112/

[4] A Guided Tour of Cilium Service Mesh – Liz Rice – KubeCon 2022: https://www.youtube.com/watch?v=e10kDBEsZw4&ab_channel=CNCF%5BCloudNativeComputingFoundation%5D

[5] Cilium Service Mesh – Getting Started Guides: https://docs.cilium.io/en/latest/gettingstarted/#service-mesh

[6] How eBPF will solve Service Mesh – Goodbye Sidecars: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh/

[7] eCHO Episode 32 – Hands-On with Cilium Service Mesh: https://www.youtube.com/watch?v=s-tgbD7wN3U&ab_channel=eBPF%26CiliumCommunity