云原生架構(gòu): 服務(wù)網(wǎng)格、混沌工程、用戶態(tài)網(wǎng)絡(luò)

一、云原生是什么

云原生技術(shù)有利于在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建可彈性擴(kuò)展的應(yīng)用運(yùn)行環(huán)境。

這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。?

結(jié)合可靠的自動(dòng)化手段，工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測(cè)的重大變更。

• 服務(wù)網(wǎng)格( Service mesh )：處理服務(wù)間通信的基礎(chǔ)設(shè)施層，負(fù)責(zé)實(shí)現(xiàn)請(qǐng)求的可靠傳遞，通常為輕量級(jí)網(wǎng)絡(luò)代理，與應(yīng)用部署在一起，但是對(duì)應(yīng)用透明。
• 混沌工程( Chaos Mesh )：運(yùn)作在容器內(nèi)對(duì)生產(chǎn)中的軟件進(jìn)行故障注入，模擬各種故障情況可視化識(shí)別項(xiàng)目缺陷
• 容器網(wǎng)絡(luò)( Container Network ): 容器間通信的基礎(chǔ)設(shè)施層，負(fù)責(zé)網(wǎng)絡(luò)路由、網(wǎng)絡(luò)策略、負(fù)載均衡等
  

將依次講述微服務(wù)架構(gòu)的迭代與Envoy數(shù)據(jù)面板豐富的功能、利用混沌工程故障注入加強(qiáng)健壯性、基于eBPF+XDP實(shí)現(xiàn)用戶態(tài)容器網(wǎng)絡(luò)用于網(wǎng)絡(luò)加速。

二、服務(wù)網(wǎng)格

微服務(wù)的架構(gòu)迭代

• 不同語(yǔ)言間的存在巨大差異
• 不同的語(yǔ)言社區(qū)的微服務(wù)實(shí)現(xiàn)各不相同
  

ServiceMesh具有如下優(yōu)點(diǎn)：

• 屏蔽分布式系統(tǒng)通信的復(fù)雜性(負(fù)載均衡、服務(wù)發(fā)現(xiàn)、認(rèn)證授權(quán)、監(jiān)控追蹤、流量控制等等)，服務(wù)只用關(guān)注業(yè)務(wù)邏輯

• 真正的與語(yǔ)言無(wú)關(guān)，服務(wù)可以用任何語(yǔ)言編寫(xiě)，只需和Service Mesh通信即可

• 對(duì)應(yīng)用透明，Service Mesh組件可以單獨(dú)升級(jí)
  

Service Mesh面臨的挑戰(zhàn)：

• Service Mesh組件以代理模式計(jì)算并轉(zhuǎn)發(fā)請(qǐng)求，一定程度上會(huì)降低通信系統(tǒng)性能，并增加系統(tǒng)資源開(kāi)銷

• ServiceMesh組件接管了網(wǎng)絡(luò)流量，因此服務(wù)的整體穩(wěn)定性依賴于Service Mesh
  

下文我們將講述利用現(xiàn)代內(nèi)核新技術(shù)eBPF+XDP加速Service Mesh 數(shù)據(jù)代理面板。

Envoy：數(shù)據(jù)代理面板

網(wǎng)絡(luò)對(duì)應(yīng)用程序來(lái)說(shuō)應(yīng)該是透明的。當(dāng)網(wǎng)絡(luò)和應(yīng)用程序出現(xiàn)問(wèn)題時(shí)，應(yīng)該很容易確定問(wèn)題的根源。

• envoy 可以與任何應(yīng)用程序語(yǔ)言配合使用，面向服務(wù)架構(gòu)使用多個(gè)應(yīng)用程序框架和語(yǔ)言的趨勢(shì)越來(lái)越普遍。
• envoy 可以透明地在整個(gè)基礎(chǔ)架構(gòu)上快速部署和升級(jí)。

高級(jí)負(fù)載均衡算法

• Weight Round robin：每個(gè)健康的上游主機(jī)按循環(huán)順序選擇， 如果將權(quán)重分配給本地的端點(diǎn)，則使用加權(quán)round robin調(diào)度
• Weighted least request：使用O(1) 算法選擇兩個(gè)隨機(jī)健康主機(jī)，并選擇主動(dòng)請(qǐng)求較少的主機(jī)
• Google Maglev Hasing：與環(huán)形散列算法相比，Maglev 具有快得多的查表編譯時(shí)間以及主機(jī)選擇時(shí)間
• Random: ?選擇一個(gè)隨機(jī)的健康主機(jī)。如果沒(méi)有配置健康檢查策略，則隨機(jī)負(fù)載均衡器通常比 round robin 更好
  

基于終端的服務(wù)發(fā)現(xiàn)

• Envoy 對(duì)每個(gè)上游主機(jī)都有明確的了解（與通過(guò) DNS 解析的負(fù)載均衡進(jìn)行路由相比而言），并可以做出更智能的負(fù)載均衡決策。
• 在每個(gè)主機(jī)的發(fā)現(xiàn) API 響應(yīng)中攜帶的額外屬性通知 Envoy 負(fù)載均衡權(quán)重、金絲雀狀態(tài)、區(qū)域等。這些附加屬性在負(fù)載均衡、統(tǒng)計(jì)信息收集等過(guò)程中會(huì)被 Envoy 網(wǎng)格全局使用。
  

斷路器

• 集群最大連接數(shù)：Envoy將為上游集群中的所有主機(jī)建立的最大連接數(shù)。
• 集群最大掛起請(qǐng)求數(shù)：在等待就緒連接池連接時(shí)將排隊(duì)的最大請(qǐng)求數(shù)。
• 集群最大請(qǐng)求數(shù)：在任何給定時(shí)間內(nèi)，集群中所有主機(jī)可以處理的最大請(qǐng)求數(shù)。
• 集群最大活動(dòng)重試次數(shù)：在任何給定時(shí)間內(nèi)，集群中所有主機(jī)可以執(zhí)行的最大重試次數(shù)。
  

斷路可以根據(jù)每個(gè)上游集群和優(yōu)先級(jí)進(jìn)行配置和跟蹤。這使得分布式系統(tǒng)的不同組件可以獨(dú)立調(diào)整并具有不同的限制。

三、混沌工程

為什么需要Chaos Mesh

Chaos Mesh能做些什么？

• pod-kill：模擬 Kubernetes Pod 被 kill。
• pod-failure：模擬 Kubernetes Pod 持續(xù)不可用，可以用來(lái)模擬節(jié)點(diǎn)宕機(jī)不可用場(chǎng)景。
• network-delay：模擬網(wǎng)絡(luò)延遲。
• network-loss：模擬網(wǎng)絡(luò)丟包。
• network-duplication: 模擬網(wǎng)絡(luò)包重復(fù)。
• network-corrupt: 模擬網(wǎng)絡(luò)包損壞。
• network-partition：模擬網(wǎng)絡(luò)分區(qū)。
• I/O delay : 模擬文件系統(tǒng) I/O 延遲。
• I/O errno：模擬文件系統(tǒng) I/O 錯(cuò)誤 。
  

Chaos Mesh如何實(shí)現(xiàn)的

• Controller-manager：目前 controller-manager 可以分為兩部分，一部分 controllers 用于調(diào)度和管理 CRD 對(duì)象實(shí)例，另一部分為 admission-webhooks 動(dòng)態(tài)的給 Pod 注入 sidecar 容器。
• Chaos-daemon：Chaos-daemon 以 daemonset 的方式運(yùn)行，并具有 Privileged 權(quán)限，Chaos-daemon 可以操作具體 Node 節(jié)點(diǎn)上網(wǎng)絡(luò)設(shè)備以及 Cgroup 等。
• Sidecar contianer：是一類特殊的容器，由 admission-webhooks 動(dòng)態(tài)的注入到目標(biāo) Pod 中，目前在 Chaos Mesh 中實(shí)現(xiàn)了 chaosfs sidecar 容器，chaosfs 容器內(nèi)會(huì)運(yùn)行 fuse-daemon，用來(lái)劫持應(yīng)用容器的 I/O 操作。
  

1. 用戶通過(guò) YAML 文件或是 Kubernetes 客戶端往 Kubernetes API Server 創(chuàng)建或更新 Chaos 對(duì)象。
2. Chaos-mesh 通過(guò) watch API Server 中的 Chaos 對(duì)象創(chuàng)建更新或刪除事件，維護(hù)具體 Chaos 實(shí)驗(yàn)的運(yùn)行以及生命周期，在這個(gè)過(guò)程中 controller-manager、chaos-daemon 以及 sidecar 容器協(xié)同工作，共同提供錯(cuò)誤注入的能力。
3. Admission-webhooks 是用來(lái)接收準(zhǔn)入請(qǐng)求的 HTTP 回調(diào)服務(wù)，當(dāng)收到 Pod 創(chuàng)建請(qǐng)求，會(huì)動(dòng)態(tài)修改待創(chuàng)建的 Pod 對(duì)象，例如注入 sidecar 容器到 Pod 中。第3步也可以發(fā)生在第2 步之前，在應(yīng)用創(chuàng)建的時(shí)候運(yùn)行。

四、用戶態(tài)容器網(wǎng)絡(luò)

什么是 CNI？

• Container Network Interface，容器網(wǎng)絡(luò)的 API 接口
• Kubelet 通過(guò)這個(gè)標(biāo)準(zhǔn)的 API 調(diào)用不同的網(wǎng)絡(luò)插件配實(shí)現(xiàn)置網(wǎng)絡(luò)
• CNI 插件：一系列實(shí)現(xiàn)了 CNI API 接口的網(wǎng)絡(luò)插件
  

• OVS CNI：基于Open vSwitch
• SR-IOV CNI +DPDK: SR-IOV技術(shù)是一種基于硬件的虛擬化解決方案， 允許在虛擬機(jī)之間高效共享PCIe設(shè)備，可以獲得能夠與本機(jī)性能媲美的 I/O性能。
• Cilium CNI: ?使用最新Linux內(nèi)核技術(shù)創(chuàng)新，基于eBPF+XDP的新技術(shù)
  

Cilium基于eBPF實(shí)現(xiàn)

什么是eBPF和XDP？

eBPF

• 過(guò)濾(Filter): 根據(jù)外界輸入的規(guī)則過(guò)濾報(bào)文；
• 復(fù)制(Copy)：將符合條件的報(bào)文由內(nèi)核空間復(fù)制到用戶空間
  

XDP

用戶態(tài)加速Envoy Proxy

利用BPF在sidecar代理和Istio控制平面之間提供高效的數(shù)據(jù)路徑，通過(guò)使用socket感知BPF程序在Linux socket級(jí)別執(zhí)行流量重定向，Cilium可以加速流量重定向到sidecar代理。這允許繞過(guò)很費(fèi)事的TCP/IP堆棧遍歷而且對(duì)應(yīng)用程序或sidecar代碼沒(méi)有侵入性。

附錄：

推薦閱讀

• 不懂這些知識(shí)點(diǎn)，你還好意思說(shuō)懂 Docker？