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

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

背景

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

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

現(xiàn)狀

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

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

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

TKE edge簡介

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

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

1）云端運維；

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

3）簡化不同地域差異化配置管理問題。

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

K3s工作原理圖

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

TKE edge架構圖

引用自【從0到1學習邊緣容器系列】之邊緣計算與邊緣容器的起源。

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

TKE edge做了幾個亮點：

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

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

3.支持異構節(jié)點。

我的核心問題和解決方案

1.服務能在云端控制部署升級

TKE edge提供了類騰訊云容器服務TKE控制臺，可以批量操作。

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

ServiceGroup，通過對節(jié)點打上Zone的標簽，同一個Zone的服務互通，不同Zone的服務進行隔離，TKE edge通過Deploymentgrid的資源來創(chuàng)建Deployment。

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

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

4.服務流量的注入

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

5.服務流量的導出

小問題

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

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

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

成果展示

筆者在西安商場和河北商場做了部署，并且對西安場切了部分流量。

云端部署

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

配置管理

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

成本和收益對比

過去：部署一套商場多個服務，一個團隊七八個人一周（多則兩周）的人力天，上下游打通；

現(xiàn)在呢：秒級?。。《铱梢宰詣樱。?！真的是牛！??！搞完，有預感感覺自己要被裁了，牛逼的程序員，就是為了革普通程序員的命。

總結展望

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

隨著5G的到來，越來越多設備邊緣化，計算也邊緣化，邊緣容器和調度會是一個大有前景的方向。