云原生漫游指南3 從容器網(wǎng)絡(luò)建設(shè)說起

原標(biāo)題：云原生漫游指南3 從容器網(wǎng)絡(luò)建設(shè)說起

上一期《云原生漫游指南（2）丨從CI&CD到計(jì)算存儲(chǔ)分離》的最后，我們介紹了計(jì)算存儲(chǔ)分離如何提升容器的靈活性。解決了容器的構(gòu)建、運(yùn)行和編排，接下來我們需要進(jìn)行容器網(wǎng)絡(luò)的建設(shè)，容器之間可以按照用戶的預(yù)期進(jìn)行網(wǎng)絡(luò)打通或隔離是如何實(shí)現(xiàn)的呢？

本期《云原生漫游指南》就將從解決這個(gè)疑問開始，繼續(xù)介紹云原生路徑中的三個(gè)關(guān)鍵站點(diǎn)。

第六站

容器網(wǎng)絡(luò)建設(shè)

在大量的云原生轉(zhuǎn)型案例中我們發(fā)現(xiàn)，容器網(wǎng)絡(luò)的實(shí)現(xiàn)往往是搭建容器平臺(tái)中客戶面臨的最大挑戰(zhàn)之一，因此在建設(shè)云原生架構(gòu)之前，盡早對容器網(wǎng)絡(luò)進(jìn)行規(guī)劃至關(guān)重要。

容器網(wǎng)絡(luò)需要解決的核心問題在于：容器本身的網(wǎng)絡(luò)通信依賴于其所在的宿主機(jī)上的網(wǎng)絡(luò)設(shè)備，然而容器在調(diào)度過程中又可能隨時(shí)在不同宿主機(jī)之間“遷移”。因此需要一套方案來解決容器間的通信與路由問題，并且充分考慮容器的靈活性、擴(kuò)展性以及IaaS層不同網(wǎng)絡(luò)實(shí)現(xiàn)等因素。

CNI（Container Network Interface）是由Google和CoreOS主導(dǎo)制定的一個(gè)容器網(wǎng)絡(luò)標(biāo)準(zhǔn)，其核心目的就是只要提供一個(gè)標(biāo)準(zhǔn)的接口，就能為同樣滿足該協(xié)議的所有容器平臺(tái)提供網(wǎng)絡(luò)功能。這樣云供應(yīng)商就可以基于CNI開發(fā)自己的專屬接口，讓Kubernetes等平臺(tái)的使用者無需感知到底層網(wǎng)絡(luò)實(shí)現(xiàn)的差異，并實(shí)現(xiàn)為容器提供一個(gè)對應(yīng)的網(wǎng)絡(luò)空間、自動(dòng)為容器分配IP地址等能力。

目前主流的CNI實(shí)現(xiàn)方案可以分為隧道方案和路由方案兩類，核心差異就是在轉(zhuǎn)發(fā)容器間的通信時(shí)是否需要對數(shù)據(jù)包進(jìn)行再次包裝。

如Calico就是典型的路由方案，通過BGP路由協(xié)議在集群中所有的節(jié)點(diǎn)上記錄全網(wǎng)路由，讓容器間可以通過IP直接通信，流量經(jīng)過源容器所在的宿主機(jī)，到達(dá)數(shù)據(jù)中心路由，然后轉(zhuǎn)發(fā)到目的宿主機(jī)并分配到目的容器。路由方案不需要額外增加封包和解包的過程，因此轉(zhuǎn)發(fā)效率更高，但是由于有大量的路由信息需要記錄，因此對網(wǎng)絡(luò)設(shè)備的要求更高。

百度智能云CCE為用戶提供了兩種不同的網(wǎng)絡(luò)方案：VPC網(wǎng)絡(luò)模式和CNI插件模式。

其中VPC網(wǎng)絡(luò)模式直接利用云上私有網(wǎng)絡(luò)中的路由表進(jìn)行路由規(guī)則記錄，不會(huì)帶來任何額外的資源開銷，同時(shí)提供高性能的轉(zhuǎn)發(fā)能力，但是受限于VPC路由網(wǎng)關(guān)的并發(fā)瓶頸，所以對集群規(guī)模會(huì)有限制。而CNI插件模式則利用了最新的彈性網(wǎng)卡特性，通過多網(wǎng)卡來為容器直接提供IP地址，從而滿足容器網(wǎng)絡(luò)和節(jié)點(diǎn)網(wǎng)絡(luò)完全在同一網(wǎng)絡(luò)層面，提供更高的網(wǎng)絡(luò)性能。

第七站

服務(wù)通信框架

在容器間網(wǎng)絡(luò)打通之后，我們需要考慮部署在容器內(nèi)的服務(wù)如何互相通信。

在傳統(tǒng)的單體應(yīng)用開發(fā)中，由于系統(tǒng)間不同的服務(wù)都部署在一個(gè)空間中，因此服務(wù)之間通信通過本地函數(shù)調(diào)用即可，不需要考慮服務(wù)間的信息如何傳遞。而在云原生的架構(gòu)中，不同服務(wù)可能部署在不同的容器并分布到不同服務(wù)器中，因此我們就需要構(gòu)建起服務(wù)間的統(tǒng)一通信機(jī)制。

Restful架構(gòu)是一種常見的服務(wù)件遠(yuǎn)程調(diào)用方式，當(dāng)服務(wù)A需要被遠(yuǎn)程訪問時(shí)，可以暴露一個(gè)Restful接口，其它服務(wù)即可通過訪問這個(gè)Restful接口來調(diào)用服務(wù)A中的特定方法。

API其實(shí)也就是一個(gè)一個(gè)的URL，因此不同服務(wù)之間只需要利用HTTP協(xié)議，從發(fā)送端發(fā)送到接收端傳輸json對象，而互相不需要關(guān)心具體的開發(fā)語言和實(shí)現(xiàn)方式。

Restful是一種輕量級(jí)、高度標(biāo)準(zhǔn)化和跨語言的服務(wù)間通信方式，非常適用于系統(tǒng)間或者對外的服務(wù)暴露。它的缺點(diǎn)在于所有的通信都基于http協(xié)議，因此每次遠(yuǎn)程訪問都需要在代碼中建立http連接，客戶端必須知道服務(wù)端的地址，對開發(fā)者不夠友好。同時(shí)http請求支持的動(dòng)詞是非常有限的，在面對復(fù)雜業(yè)務(wù)時(shí)會(huì)導(dǎo)致接口的語義不夠明確，因此Restful并不適用于系統(tǒng)內(nèi)部的服務(wù)間調(diào)用。

相比之下RPC（Romote Procedure Call）是更適合于復(fù)雜系統(tǒng)內(nèi)部的服務(wù)間通信方式，

RPC作為一種面向過程的服調(diào)用方式，在服務(wù)件遠(yuǎn)程調(diào)用時(shí)，能夠像本地調(diào)用一樣方便，讓調(diào)用者感知不到遠(yuǎn)程調(diào)用的實(shí)現(xiàn)邏輯。為了實(shí)現(xiàn)這一點(diǎn)，除了服務(wù)提供方需要暴露可供遠(yuǎn)程訪問的接口外，服務(wù)調(diào)用方還需要一個(gè)Client Stub （客戶端存根）存放服務(wù)端的地址消息，再將客戶端的請求參數(shù)打包成網(wǎng)絡(luò)消息。RPC原理的具體實(shí)現(xiàn)框架有很多，如Google開源的gRPC框架、百度開源的bRPC框架等。

由于Restful和RPC各自有不同的適用場景，因此一個(gè)企業(yè)級(jí)的系統(tǒng)中往往是兩種遠(yuǎn)程調(diào)用方式并存的。百度云原生微服務(wù)應(yīng)用平臺(tái)CNAP也充分考慮到了這種場景，同時(shí)支持對Restful和RPC接口的數(shù)據(jù)采集，從而在追蹤請求鏈路和查看服務(wù)拓?fù)鋾r(shí)能夠整合兩種類型的請求，為用戶呈現(xiàn)出一個(gè)完整的服務(wù)間通信網(wǎng)絡(luò)。

第八站

可觀察性建設(shè)

當(dāng)應(yīng)用以容器化的方式運(yùn)行在Kubernetes集群上，并且可以正常進(jìn)行網(wǎng)絡(luò)通信后。下一步需要考慮的問題，就是如何保障應(yīng)用按照預(yù)期的狀態(tài)可靠運(yùn)行。

這時(shí)候我們就需要引入“可觀察性”的概念，和可用性、可擴(kuò)展性一樣，可觀察性是一個(gè)非常重要的非業(yè)務(wù)需求，它要求開發(fā)運(yùn)維人員能夠主動(dòng)規(guī)劃系統(tǒng)運(yùn)行過程中的關(guān)鍵指標(biāo)、隨時(shí)對這些指標(biāo)進(jìn)行監(jiān)控、并且匯總這些指標(biāo)以用于分析和預(yù)測。

可觀察性又可以拆分成很多層面：

• 對資源使用的觀察，可以幫助優(yōu)化平臺(tái)的資源配置；
• 對應(yīng)用運(yùn)行狀態(tài)的觀察，可以及時(shí)發(fā)現(xiàn)系統(tǒng)中微小的故障并盡早恢復(fù)；
• 對應(yīng)用日志的觀察，可以分析應(yīng)用運(yùn)行的過程和內(nèi)部邏輯是否符合預(yù)期；
• 對服務(wù)間交互和調(diào)用的觀察，可以幫助發(fā)現(xiàn)整個(gè)系統(tǒng)的性能瓶頸從而提出優(yōu)化方案；
• 可觀察性的建設(shè)主要基于三類基本要素：日志（logging）、指標(biāo)（metrics）、追蹤（tracing），這些要素分別從不同角度記錄系統(tǒng)的運(yùn)行，同時(shí)也需要不同的工具來進(jìn)行采集。

在面對不同的場景和不同角色的需求時(shí)，往往需要對這些要素進(jìn)行靈活使用和組合，比如一個(gè)開發(fā)人員可能需要從logging中分析細(xì)節(jié)，而運(yùn)維人員則更關(guān)注tracing與metrics之間的聯(lián)系。所以一個(gè)優(yōu)秀的云原生架構(gòu)中，不僅要提供對豐富的各類元素進(jìn)行觀察的能力，也需要支持高度自定義的匯聚、分析和報(bào)警的策略。

在云原生開源社區(qū)中，opentracing和jaeger是tracing領(lǐng)域的典型工具代表、fluentd、kibana等專注于logging，而prometheus則是metric方向最熱門的技術(shù)棧。

百度智能云為了降低用戶對這些不同工具的整合成本，在云容器引擎（CCE）和云原生微服務(wù)應(yīng)用平臺(tái)（CNAP）中提供了基于這些開源工具的一站式方案，在最小化性能損耗的情況下提供豐富的觀察要素采集，同時(shí)在統(tǒng)一的界面完成自定義的數(shù)據(jù)匯總、分析和報(bào)警配置。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。