為什么需要ServiceMesh

在成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)中從網(wǎng)站色彩、結(jié)構(gòu)布局、欄目設(shè)置、關(guān)鍵詞群組等細(xì)微處著手，突出企業(yè)的產(chǎn)品/服務(wù)/品牌，幫助企業(yè)鎖定精準(zhǔn)用戶，提高在線咨詢和轉(zhuǎn)化，使成都網(wǎng)站營(yíng)銷成為有效果、有回報(bào)的無(wú)錫營(yíng)銷推廣。創(chuàng)新互聯(lián)專業(yè)成都網(wǎng)站建設(shè)十載了，客戶滿意度97.8%，歡迎成都創(chuàng)新互聯(lián)客戶聯(lián)系。

UCloud App Engine on Kubernetes（后簡(jiǎn)稱“UAEK”）是UCloud內(nèi)部打造的一個(gè)基于Kubernetes的，具備高可用、跨機(jī)房容災(zāi)、自動(dòng)伸縮、立體監(jiān)控、日志搜集和簡(jiǎn)便運(yùn)維等特性計(jì)算資源交付平臺(tái)，旨在利用容器技術(shù)提高內(nèi)部研發(fā)運(yùn)維效率，讓開(kāi)發(fā)能將更多的精力投入在業(yè)務(wù)研發(fā)本身，同時(shí)，讓運(yùn)維能更從容應(yīng)對(duì)資源伸縮、灰度發(fā)布、版本更迭、監(jiān)控告警等日常工作。

考慮到Kubernetes本來(lái)就是為自動(dòng)部署、伸縮和容器化而生，再加上UCloud UAEK團(tuán)隊(duì)完成IPv6組網(wǎng)調(diào)研和設(shè)計(jì)實(shí)現(xiàn)后，一個(gè)成熟的容器管理平臺(tái)很快正式在北京二地域的多個(gè)可用區(qū)上線了。相比于過(guò)去申請(qǐng)管理虛擬機(jī)部署應(yīng)用服務(wù)，Kubernetes確實(shí)帶來(lái)了實(shí)實(shí)在在的便利，例如方便靈活的自動(dòng)伸縮以及×××的微服務(wù)架構(gòu)，只需簡(jiǎn)單配置即可實(shí)現(xiàn)跨可用區(qū)容災(zāi)等。

然而，微服務(wù)化又為系統(tǒng)架構(gòu)帶來(lái)許多新的問(wèn)題，例如服務(wù)發(fā)現(xiàn)、監(jiān)控、灰度控制、過(guò)載保護(hù)、請(qǐng)求調(diào)用追蹤等。大家已經(jīng)習(xí)慣自行運(yùn)維一組Zookeeper集群用以實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和客戶端負(fù)載均衡，使用UAEK后能否免去運(yùn)維Zookeeper的工作？為了監(jiān)控業(yè)務(wù)運(yùn)行狀態(tài)，大家都需要在代碼里加上旁路上報(bào)邏輯，使用UAEK是否能無(wú)侵入零耦合地實(shí)現(xiàn)監(jiān)控上報(bào)？

此外，過(guò)去很多系統(tǒng)模塊間調(diào)用缺少熔斷保護(hù)策略，波峰流量一打就癱，使用UAEK是否能幫助業(yè)務(wù)方免去大規(guī)模改造呢？過(guò)去排查問(wèn)題，尤其是調(diào)用耗時(shí)環(huán)節(jié)排查總是費(fèi)時(shí)費(fèi)力，使用UAEK能否為定位瓶頸提供方便的工具？

顯然，僅憑一個(gè)穩(wěn)定的Kubernetes平臺(tái)不足以解決這些問(wèn)題。因此，在UAEK立項(xiàng)之初，團(tuán)隊(duì)就把ServiceMesh作為一個(gè)必須實(shí)現(xiàn)的目標(biāo)，任何在UAEK上部署的TCP后臺(tái)服務(wù)，都能享受到ServiceMesh帶來(lái)的這些特性：

SideCar模式部署，零侵入，微服務(wù)治理代碼與業(yè)務(wù)代碼完全解耦；
與Kubernetes平臺(tái)融合的服務(wù)發(fā)現(xiàn)機(jī)制和負(fù)載均衡調(diào)度；
提供靈活，實(shí)時(shí)，無(wú)需重啟、能根據(jù)7層業(yè)務(wù)信息進(jìn)行流量灰度管理功能；
提供統(tǒng)一抽象數(shù)據(jù)上報(bào)API層，用于實(shí)現(xiàn)監(jiān)控和訪問(wèn)策略控制；
使用分布式請(qǐng)求鏈路追蹤系統(tǒng)，快速追溯Bug，定位系統(tǒng)性能瓶頸；
過(guò)載保護(hù)機(jī)制，能在請(qǐng)求量超過(guò)系統(tǒng)設(shè)計(jì)容量時(shí)自動(dòng)觸發(fā)熔斷；
能在服務(wù)上線前提供故障模擬注入演習(xí)劇本，提前進(jìn)行故障處理演練；
這樣，使用UAEK部署應(yīng)用服務(wù)后，即可從小范圍按賬號(hào)灰度上線開(kāi)始，通過(guò)陸續(xù)地監(jiān)控觀察，輕松掌握版本異?；赝?、擴(kuò)大灰度范圍、全量發(fā)布、過(guò)載保護(hù)、異常請(qǐng)求定位追蹤等信息。

為什么是Istio？

關(guān)于ServiceMesh的實(shí)現(xiàn)，我們重點(diǎn)考察了Istio。通過(guò)前期的調(diào)研和測(cè)試，我們發(fā)現(xiàn)Istio的幾個(gè)特性能很好滿足UAEK的需求：

完美支持Kubernetes平臺(tái)；
控制面和數(shù)據(jù)轉(zhuǎn)發(fā)面分離；
Sidecar部署，掌控所有服務(wù)間調(diào)用流量，無(wú)上限的控制力；
使用Envoy作為Sidecar實(shí)現(xiàn)，Envoy使用C++11開(kāi)發(fā)，基于事件驅(qū)動(dòng)和多線程機(jī)制運(yùn)行，性能好并發(fā)能力強(qiáng)，媲美NGINX；
對(duì)業(yè)務(wù)的代碼和配置文件零侵入；
配置簡(jiǎn)單，操作方便，API完善。

cdn.xitu.io/2018/8/23/16565d6f6dfeaed9?w=646&h=507&f=png&s=55105">

整個(gè)服務(wù)網(wǎng)格分成控制面板和數(shù)據(jù)面兩大部分。數(shù)據(jù)面指的就是注入到應(yīng)用Pod中的Envoy容器，它負(fù)責(zé)代理調(diào)度模塊間的所有流量?？刂泼娣譃镻ilot，Mixer和Citadel三大模塊，具體功能如下：

Pilot負(fù)責(zé)向Kubernetes API獲取并Watch整個(gè)集群的服務(wù)發(fā)現(xiàn)信息，并向Envoy下發(fā)集群服務(wù)發(fā)現(xiàn)信息和用戶定制的路由規(guī)則策略。
Mixer分為Policy和Telemetry兩個(gè)子模塊。Policy用于向Envoy提供準(zhǔn)入策略控制，黑白名單控制，QPS流速控制服務(wù)；Telemetry為Envoy提供了數(shù)據(jù)上報(bào)和日志搜集服務(wù)，以用于監(jiān)控告警和日志查詢。
Citadel為服務(wù)和用戶提供認(rèn)證和鑒權(quán)、管理憑據(jù)和 RBAC。
此外Istio為運(yùn)維人員提供了一個(gè)叫istioctl的命令行工具，類似kubernetes的kubectl。運(yùn)維編寫(xiě)好路由規(guī)則yaml文件后，使用istioctl即可向集群提交路由規(guī)則。

Istio整體工作的原理和流程細(xì)節(jié)非常復(fù)雜，所涉及到的技術(shù)棧有一定的深度和廣度。這里只概括一下大體過(guò)程：

運(yùn)維人員使用istioctl或者調(diào)用API向控制層創(chuàng)建修改路由規(guī)則策略。
Pilot向Kube APIServer獲取并watch集群服務(wù)發(fā)現(xiàn)信息。
部署應(yīng)用程序時(shí)，Istio會(huì)在pod的部署配置中注入Envoy容器，Envoy會(huì)通過(guò)iptables nat redirect劫持代理pod中的全部TCP流量。
Envoy會(huì)實(shí)時(shí)從Pilot更新集群的服務(wù)發(fā)現(xiàn)信息和路由規(guī)則策略，并根據(jù)這些信息智能調(diào)度集群內(nèi)的流量。
Envoy會(huì)在每次請(qǐng)求發(fā)送前向Mixer Policy發(fā)送Check請(qǐng)求檢查該請(qǐng)求是否收策略限制或者配額限制，每次請(qǐng)求接收后會(huì)向Mixer Telemetry上報(bào)本次請(qǐng)求的基本信息，如調(diào)用是否成功、返回狀態(tài)碼、耗時(shí)數(shù)據(jù)。
Citadel實(shí)現(xiàn)了雙向TLS客戶端證書(shū)生成與注入，服務(wù)端密鑰和證書(shū)的下發(fā)注入，以及K8S RBAC訪問(wèn)控制。
Istio在UAEK環(huán)境下的改造之路
經(jīng)過(guò)上述的調(diào)研和與一系列測(cè)試，UAEK團(tuán)隊(duì)充分認(rèn)可Istio的設(shè)計(jì)理念和潛在價(jià)值，希望通過(guò)利用Istio豐富強(qiáng)大的微服務(wù)治理功能吸引更多的內(nèi)部團(tuán)隊(duì)將服務(wù)遷移到UAEK環(huán)境中。

然而，事實(shí)上，在UAEK上接入Istio的過(guò)程并非一帆風(fēng)順。最早開(kāi)始調(diào)研Istio的時(shí)候，Istio還在0.6版本，功能并不完善，在UAEK環(huán)境中無(wú)法開(kāi)箱即用。

IPv6問(wèn)題的解決

我們首先碰到的問(wèn)題是，UAEK是一個(gè)純IPv6網(wǎng)絡(luò)環(huán)境，而Istio對(duì)IPv6流量的支持并不完備，部分組件甚至無(wú)法在IPv6環(huán)境下部署。

在介紹具體改造案例之前，先了解下Istio Sidecar是如何接管業(yè)務(wù)程序的流量。

如上圖所描述，Istio會(huì)向應(yīng)用Pod注入兩個(gè)容器：proxy-init容器和envoy容器。proxy-init容器通過(guò)初始化iptables設(shè)置，將所有的TCP層流量通過(guò)nat redirect重定向到Envoy監(jiān)聽(tīng)的15001端口。以入流量為例，Envoy的服務(wù)端口接收到被重定向到來(lái)的TCP連接后，通過(guò)getsocketopt(2)系統(tǒng)調(diào)用，使用SO_ORIGINAL_DST參數(shù)找到該TCP連接的真實(shí)目的地IP地址，并將該請(qǐng)求轉(zhuǎn)發(fā)到真實(shí)目的IP。

然而，我們發(fā)現(xiàn)在IPv6環(huán)境下，Envoy無(wú)法劫持Pod的流量。通過(guò)抓包觀察和追溯源碼發(fā)現(xiàn)，Pod啟動(dòng)的時(shí)候，首先會(huì)運(yùn)行一個(gè)iptables初始化腳本，完成pod內(nèi)的nat redirect配置，將容器內(nèi)的TCP出入流量都劫持到Envoy的監(jiān)聽(tīng)端口中，但這個(gè)初始化腳本沒(méi)有ip6tables的對(duì)應(yīng)操作并且discard了所有IPv6流量，因此我們修改了初始化腳本，實(shí)現(xiàn)了IPv6的流量劫持。

一波剛平，一波又起。完成IPv6流量劫持后， 我們發(fā)現(xiàn)所有訪問(wèn)業(yè)務(wù)服務(wù)端口的TCP流量都被Envoy重置，進(jìn)入Envoy容器中發(fā)現(xiàn)15001端口并沒(méi)有開(kāi)啟。追溯Envoy和Pilot源碼發(fā)現(xiàn)，Pilot給Envoy下發(fā)的listen地址為0:0:0:0:15001, 這是個(gè)IPv4地址，我們需要Envoy監(jiān)聽(tīng)地址的為[::0]:15000，于是繼續(xù)修改Pilot源碼。

經(jīng)過(guò)上述努力，應(yīng)用服務(wù)端程序Pod終于能成功Accept我們發(fā)起的TCP連接。但很快，我們的請(qǐng)求連接就被服務(wù)端關(guān)閉，客戶端剛連接上就立刻收到TCP FIN分節(jié)，請(qǐng)求依然失敗。通過(guò)觀察Envoy的運(yùn)行日志，發(fā)現(xiàn)Envoy接收了TCP請(qǐng)求后，無(wú)法找到對(duì)應(yīng)的4層流量過(guò)濾器(Filter)。

深入跟進(jìn)源碼發(fā)現(xiàn)，Envoy需要通過(guò)getsocketopt(2)系統(tǒng)調(diào)用獲取被劫持的訪問(wèn)請(qǐng)求的真實(shí)目的地址， 但在IPv6環(huán)境下Envoy相關(guān)的實(shí)現(xiàn)存在bug，如下代碼所示。由于缺少判定socket fd的類型， getsocketopt(2)傳入的參數(shù)是IPv4環(huán)境下的參數(shù)，因此Envoy無(wú)法找到請(qǐng)求的真實(shí)目的地址，遂報(bào)錯(cuò)并立刻關(guān)閉了客戶端連接。

發(fā)現(xiàn)問(wèn)題后，UAEK團(tuán)隊(duì)立刻修改Envoy源碼，完善了getsocketopt(2) 的SO_ORIGINAL_DST選項(xiàng)的IPv6兼容性，然后將這一修改提交到Envoy開(kāi)源社區(qū)，隨后被社區(qū)合并到當(dāng)前的Master分支中，并在Istio1.0的Envoy鏡像中得到更新使用。

到此為止，Istio SideCar終于能在UAEK IPv6環(huán)境下正常調(diào)度服務(wù)間的訪問(wèn)流量了。

此外，我們還發(fā)現(xiàn)Pilot、Mixer等模塊在處理IPv6格式地址時(shí)出現(xiàn)數(shù)組越界、程序崩潰的情況，并逐一修復(fù)之。

性能評(píng)估

Istio1.0發(fā)布之前，性能問(wèn)題一直是業(yè)界詬病的焦點(diǎn)。我們首先考察了增加了Envoy后，流量多了一層復(fù)制，并且請(qǐng)求發(fā)起前需要向Mixer Policy進(jìn)行一次Check請(qǐng)求，這些因素是否會(huì)對(duì)業(yè)務(wù)產(chǎn)生不可接收的延遲。經(jīng)過(guò)大量測(cè)試，我們發(fā)現(xiàn)在UAEK環(huán)境下會(huì)比不使用Istio時(shí)增加5ms左右的延遲，對(duì)內(nèi)部大部分服務(wù)來(lái)說(shuō)，這完全可以接受。

隨后，我們重點(diǎn)考察了整個(gè)Istio Mesh的架構(gòu)，分析下來(lái)結(jié)論是，Mixer Policy和Mixer Telemetry很容易成為整個(gè)集群的性能短板。由于Envoy發(fā)起每個(gè)請(qǐng)求前都需要對(duì)Policy服務(wù)進(jìn)行Check請(qǐng)求，一方面增加了業(yè)務(wù)請(qǐng)求本身的延遲，一方面也給作為單點(diǎn)的Policy增大了負(fù)載壓力。我們以Http1.1請(qǐng)求作為樣本測(cè)試，發(fā)現(xiàn)當(dāng)整個(gè)網(wǎng)格QPS達(dá)到2000-3000的時(shí)候，Policy就會(huì)出現(xiàn)嚴(yán)重的負(fù)載瓶頸，導(dǎo)致所有的Check請(qǐng)求耗時(shí)顯著增大，由正常情況下的2-3ms增大到100-150ms，嚴(yán)重加劇了所有業(yè)務(wù)請(qǐng)求的耗時(shí)延遲，這個(gè)結(jié)果顯然是不可接受的。

更嚴(yán)重的是，在Istio 0.8以及之前的版本，Policy是一個(gè)有狀態(tài)的服務(wù)。一些功能，如全局的QPS Ratelimit配額控制，需要Policy單個(gè)進(jìn)程記錄整個(gè)Mesh的實(shí)時(shí)數(shù)據(jù)，這意味著Policy服務(wù)無(wú)法通過(guò)橫向擴(kuò)容實(shí)例來(lái)解決性能瓶頸。經(jīng)過(guò)取舍權(quán)衡，我們目前關(guān)閉了Policy服務(wù)并裁剪了一些功能，比如QPS全局配額限制。

前面提到過(guò)，Mixer Telemetry主要負(fù)責(zé)向Envoy收集每次請(qǐng)求的調(diào)用情況。0.8版本的Mixer Telemetry也存在嚴(yán)重的性能問(wèn)題。壓測(cè)中發(fā)現(xiàn)，當(dāng)集群QPS達(dá)到2000以上時(shí)，Telemetry實(shí)例的內(nèi)存使用率會(huì)一路狂漲。

經(jīng)過(guò)分析定位，發(fā)現(xiàn)Telemetry內(nèi)存上漲的原因是數(shù)據(jù)通過(guò)各種后端Adapter消費(fèi)的速率無(wú)法跟上Envoy上報(bào)的速率， 導(dǎo)致未被Adapter處理的數(shù)據(jù)快速積壓在內(nèi)存中。我們隨即去除了Istio自帶的并不實(shí)用的stdio日志搜集功能，這一問(wèn)題隨即得到極大緩解。幸運(yùn)的是，隨著Istio1.0的發(fā)布，Telemetry的內(nèi)存數(shù)據(jù)積壓?jiǎn)栴}得到解決，在相同的測(cè)試條件下，單個(gè)Telemetry實(shí)例至少能勝任3.5W QPS情況下的數(shù)據(jù)搜集上報(bào)。

問(wèn)題、希望與未來(lái)

歷經(jīng)重重問(wèn)題，一路走來(lái)，一個(gè)生產(chǎn)環(huán)境可用的ServiceMesh終于在UAEK環(huán)境上線了。在這一過(guò)程中，也有部門(mén)內(nèi)其他團(tuán)隊(duì)受UAEK團(tuán)隊(duì)影響，開(kāi)始學(xué)習(xí)Istio的理念并嘗試在項(xiàng)目中使用Istio。然而，目前的現(xiàn)狀離我們的初心依然存在差距。

Istio依然在高速迭代中，無(wú)論是Istio本身還是Envoy Proxy，每天都在演進(jìn)更新。每一次版本更新，帶來(lái)的都是更為強(qiáng)大的功能，更為簡(jiǎn)練的API定義，同時(shí)也帶來(lái)了更復(fù)雜的部署架構(gòu)。從0.7.1到0.8，全新的路由規(guī)則v1alpha3與之前的API完全不兼容，新的virtualservice與原先的routerule截然不同，給每位使用者構(gòu)成了不少麻煩。

如何完全避免升級(jí)Istio給現(xiàn)網(wǎng)帶來(lái)負(fù)影響，官方依然沒(méi)有給出完美平滑的升級(jí)方案。此外，從0.8到1.0雖然各個(gè)組件的性能表現(xiàn)有顯著提升，但從業(yè)內(nèi)反饋來(lái)看，并沒(méi)令所有人滿意，Mixer的Check緩存機(jī)制究竟能多大程度緩解Policy的性能壓力依然需要觀察。

值得一提的是，我們發(fā)現(xiàn)的不少bug同時(shí)也在被社區(qū)其他開(kāi)發(fā)者發(fā)現(xiàn)并逐一解決。令我們開(kāi)心的是，UAEK團(tuán)隊(duì)不是信息孤島，我們能感受到Istio官方社區(qū)正在努力高速迭代，始終在致力于解決廣大開(kāi)發(fā)者關(guān)心的種種問(wèn)題，我們提交的issue能在數(shù)小時(shí)內(nèi)被響應(yīng)，這些，都讓我們堅(jiān)信，Istio是一個(gè)有潛力的項(xiàng)目，會(huì)向Kubernetes一樣走向成功。

從UAEK接入用戶的經(jīng)驗(yàn)來(lái)看，用戶需要正確地使用好Istio離不開(kāi)前期深入的Istio文檔學(xué)習(xí)。UAEK后續(xù)需致力于要簡(jiǎn)化這一過(guò)程，讓用戶能傻瓜化、界面化、隨心所欲地定制自己的路由規(guī)則成為我們下一個(gè)愿景。

UAEK團(tuán)隊(duì)始終致力于改革UCloud內(nèi)部研發(fā)流程，讓研發(fā)提升效率，讓運(yùn)維不再苦惱，讓所有人開(kāi)心工作。除了繼續(xù)完善ServiceMesh功能，下半年UAEK還會(huì)開(kāi)放更多的地域和可用區(qū)，提供功能更豐富的控制臺(tái)，發(fā)布自動(dòng)化的代碼管理打包持續(xù)集成(CI/CD)特性等等，敬請(qǐng)期待！

作者介紹

陳綏，UCloud資深研發(fā)工程師，先后負(fù)責(zé)監(jiān)控系統(tǒng)、Serverless產(chǎn)品、PaaS平臺(tái)ServiceMesh等開(kāi)發(fā)，有豐富的分布式系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。

當(dāng)前文章：Istio在UAEK中的實(shí)踐改造之路
轉(zhuǎn)載來(lái)于：http://aaarwkj.com/article14/jpoide.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、品牌網(wǎng)站設(shè)計(jì)、做網(wǎng)站、網(wǎng)站收錄、動(dòng)態(tài)網(wǎng)站、營(yíng)銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)