完爆！用騰訊云邊緣容器，竟能秒級(jí)實(shí)現(xiàn)團(tuán)隊(duì)七八人一周的工作量

導(dǎo)語|云端管控、邊緣計(jì)算、處于局域網(wǎng)內(nèi)的微服務(wù)如何做Devops呢？騰訊優(yōu)圖業(yè)務(wù)是結(jié)合了騰訊云邊緣容器TKE edge來做服務(wù)Devops，并對(duì)服務(wù)做了自定義定制，以支持相應(yīng)的業(yè)務(wù)場(chǎng)景。本篇文章接下來將詳細(xì)展示實(shí)踐落地細(xì)節(jié)，希望能夠給大家?guī)盱`感。

背景

所謂私有云，其實(shí)就是在多個(gè)局域網(wǎng)玩服務(wù)，基本等同于開發(fā)運(yùn)維全包。每個(gè)局域網(wǎng)都要需要一個(gè)跳板機(jī)、局域網(wǎng)環(huán)境（每個(gè)局域網(wǎng)環(huán)境不一）以及硬件、軟件等，然后還需要大量人肉運(yùn)維部署升級(jí)服務(wù)（傳統(tǒng)做法譬如ansible，fabric，scp，諸如拷貝、配置更新、版本維護(hù)都很麻煩，所以棄用），而且不同局域網(wǎng)服務(wù)需要差異化配置，配置管理也是問題。

筆者也思考過做一套局域網(wǎng)自動(dòng)化部署的東西，思路就是在局域網(wǎng)部署agent來和云端打通，然后各種傳數(shù)據(jù)發(fā)命令。就在這個(gè)時(shí)候突然看到同事在寫TKE edge的東西，看了之后感覺是我想要的東西，于是就開干了。

現(xiàn)狀

批量部署問題：為了批量部署部署，采用了scp、fabric部署工具，每個(gè)局域網(wǎng)采用不同配置，要改配置的話就需要挨個(gè)登錄機(jī)器修改；

差異化配置問題：為了解決配置問題，采用配置中心，將所有配置集中化管理，但是每個(gè)局域網(wǎng)的配置中心還是不一樣，盡管已經(jīng)收斂到一個(gè)服務(wù)了，還是感覺很累且容易出錯(cuò)；

服務(wù)上下游調(diào)用：采用自研服務(wù)發(fā)現(xiàn)組件，結(jié)合了consul的DNS服務(wù)功能，上下游服務(wù)通過DNS尋址。這個(gè)問題可以很好地解決。

TKE edge簡(jiǎn)介

有沒有一種能在云上控制服務(wù)部署升級(jí)的產(chǎn)品呢？據(jù)了解，TKE edge就是其中一種，它可以比較好地解決這個(gè)問題。

另外，業(yè)界還有一個(gè)開源解決方案K3s，這個(gè)方案雖然通過裁剪讓資源有限的設(shè)備也能運(yùn)行K8s，然而依然不能解決我最關(guān)心的幾個(gè)問題，如：

1）云端運(yùn)維；

2）在一個(gè)集群中管理跨網(wǎng)絡(luò)和地域的邊緣節(jié)點(diǎn)；

3）簡(jiǎn)化不同地域差異化配置管理問題。

接下來，我們來分別看下K3s、TKE edge的工作原理以及兩者之間的差異。

K3s工作原理圖

引用自K3s官網(wǎng)https://k3s.io/

TKE edge架構(gòu)圖

引用自【從0到1學(xué)習(xí)邊緣容器系列】之邊緣計(jì)算與邊緣容器的起源。

從上方架構(gòu)圖可以看出，TKE edge增加tunnel來打通外網(wǎng)，傳輸數(shù)據(jù)和命令，就是我之前提到的需要設(shè)計(jì)的agent，另外增加了邊緣節(jié)點(diǎn)自治組件hub-edge，這個(gè)跟云端管控一一對(duì)應(yīng)的。

TKE edge做了幾個(gè)亮點(diǎn)：

1.ServiceGroup：跨局域網(wǎng)服務(wù)的隔離，局域網(wǎng)內(nèi)服務(wù)互通，但是不能跨局域網(wǎng)訪問，另外可以自動(dòng)復(fù)制業(yè)務(wù)系統(tǒng)，注意是一套業(yè)務(wù)系統(tǒng)，不是單個(gè)Pod，比如增加一個(gè)局域網(wǎng)Zone，可以在不干預(yù)的情況下，自動(dòng)復(fù)制到新的局域網(wǎng)，意外亮點(diǎn)；

2.分布式健康檢測(cè)：為了避免弱網(wǎng)環(huán)境和云端管控存在網(wǎng)絡(luò)問題，可以采用自治的決定哪些Pod真正被驅(qū)逐。

3.支持異構(gòu)節(jié)點(diǎn)。

我的核心問題和解決方案

1.服務(wù)能在云端控制部署升級(jí)

TKE edge提供了類騰訊云容器服務(wù)TKE控制臺(tái)，可以批量操作。

2.服務(wù)不能跨局域網(wǎng)訪問

ServiceGroup，通過對(duì)節(jié)點(diǎn)打上Zone的標(biāo)簽，同一個(gè)Zone的服務(wù)互通，不同Zone的服務(wù)進(jìn)行隔離，TKE edge通過Deploymentgrid的資源來創(chuàng)建Deployment。

3.服務(wù)在K8s要做一致性hash這種復(fù)雜化LB策略

先用K8s的downward API講Pod的nodeName導(dǎo)入到Pod環(huán)境變量，通過Node的Zone信息，結(jié)合client-go的API進(jìn)行Label過濾，這個(gè)需要上層服務(wù)發(fā)現(xiàn)組件支持，為啥不用K8s Ingress和Service方案，不好意思，不支持。

4.服務(wù)流量的注入

通過nodePort暴露服務(wù)，為了避免網(wǎng)卡爆掉需要利用多個(gè)宿主機(jī)nodePort承接流量，采用consul來注冊(cè)服務(wù)，類似騰訊云CLB方案。

5.服務(wù)流量的導(dǎo)出

小問題

6.服務(wù)分區(qū)域差異化配置，一套代碼，云端定制配置，通過zone來關(guān)聯(lián)

將服務(wù)配置采用Configmap管理，并且通過Volume機(jī)制將Configmap掛載到pod的容器目錄，那怎么決定哪個(gè)區(qū)域采用哪個(gè)配置呢，通過傳入nodeName的來進(jìn)行選擇。這個(gè)問題解決好了之后，新增商場(chǎng)(局域網(wǎng))，只需要在云端配置好對(duì)應(yīng)的配置，就可以自動(dòng)擴(kuò)容了，碉堡了簡(jiǎn)直。

7.一些次要問題，不在此列舉了。

成果展示

筆者在西安商場(chǎng)和河北商場(chǎng)做了部署，并且對(duì)西安場(chǎng)切了部分流量。

云端部署

對(duì)于Deploymentgrid控制臺(tái)還沒開發(fā)好，只能通過kubectl來創(chuàng)建資源。

配置管理

這兩個(gè)棘手問題解決了，就大功告成了。

成本和收益對(duì)比

過去：部署一套商場(chǎng)多個(gè)服務(wù)，一個(gè)團(tuán)隊(duì)七八個(gè)人一周（多則兩周）的人力天，上下游打通；

現(xiàn)在呢：秒級(jí)?。?！而且可以自動(dòng)！??！真的是牛?。?！搞完，有預(yù)感感覺自己要被裁了，牛逼的程序員，就是為了革普通程序員的命。

總結(jié)展望

目前我覺得存在的問題是，TKE edge應(yīng)該是基于K8s定制的，資源占用比較多，對(duì)于AI設(shè)備有些要求，比如要能跑Docker，還有硬件平臺(tái)和操作系統(tǒng)等一些要求；另外節(jié)點(diǎn)添加過程，沒有為節(jié)點(diǎn)批量打標(biāo)簽的功能，對(duì)于Node標(biāo)簽修改，調(diào)度規(guī)則有待明確；對(duì)TKE edge單集群能管理的節(jié)點(diǎn)極限、大規(guī)模Pod調(diào)度性能方面尚未深入研究。

隨著5G的到來，越來越多設(shè)備邊緣化，計(jì)算也邊緣化，邊緣容器和調(diào)度會(huì)是一個(gè)大有前景的方向。