完爆！用邊緣容器，竟能秒級實現團隊七八人一週的工做量

導語 | 雲端管控、邊緣計算、處於局域網內的微服務如何作Devops呢？騰訊優圖業務是結合了騰訊雲邊緣容器TKE@edge來作服務Devops， 並對服務作了自定義定製， 以支持相應的業務場景。本篇文章接下來將詳細展現實踐落地細節，但願可以給你們帶來靈感。

背景

所謂私有云， 其實就是在多個局域網玩服務，基本等同於開發運維全包。每一個局域網都要須要一個跳板機、局域網環境（每一個局域網環境不一）以及硬件、軟件等，而後還須要大量人肉運維部署升級服務（傳統作法譬如ansible， fabric， scp， 諸如拷貝、配置更新、版本維護都很麻煩， 因此棄用）， 並且不一樣局域網服務須要差別化配置， 配置管理也是問題。

筆者也思考過作一套局域網自動化部署的東西， 思路就是在局域網部署agent來和雲端打通， 而後各類傳數據發命令。就在這個時候忽然看到同事在寫TKE@edge的東西， 看了以後感受是我想要的東西， 因而就開幹了。

現狀

批量部署問題：爲了批量部署部署， 採用了scp、fabric部署工具， 每一個局域網採用不一樣配置， 要改配置的話就須要挨個登陸機器修改；
差別化配置問題：爲了解決配置問題， 採用配置中心， 將全部配置集中化管理， 可是每一個局域網的配置中心仍是不同， 儘管已經收斂到一個服務了， 仍是感受很累且容易出錯；
服務上下游調用：採用自研服務發現組件， 結合了consul的DNS服務功能， 上下游服務經過DNS尋址。 這個問題能夠很好地解決。

TKE@edge簡介

有沒有一種能在雲上控制服務部署升級的產品呢？據瞭解，TKE@edge就是其中一種，它能夠比較好地解決這個問題。

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

1）雲端運維；

2）在一個集羣中管理跨網絡和地域的邊緣節點；

3）簡化不一樣地域差別化配置管理問題。

接下來，咱們來分別看下K3s、TKE@edge的工做原理以及二者之間的差別。

K3s 工做原理圖

TKE@edge架構圖

引用自【TKE 邊緣容器系列】邊緣計算與邊緣容器簡介。

從上方架構圖能夠看出，TKE@edge增長tunnel來打通外網， 傳輸數據和命令， 就是我以前提到的須要設計的agent， 另外增長了邊緣節點自治組件hub-edge， 這個跟雲端管控一一對應的。

TKE@edge作了幾個亮點：

1. ServiceGroup：跨局域網服務的隔離， 局域網內服務互通， 可是不能跨局域網訪問， 另外能夠自動複製業務系統， 注意是一套業務系統，不是單個Pod， 好比增長一個局域網Zone， 能夠在不干預的狀況下，自動複製到新的局域網， 意外亮點；

2. 分佈式健康檢測： 爲了不弱網環境 和雲端管控存在網絡問題， 能夠採用自治的決定哪些Pod真正被驅逐。

3. 支持異構節點。

個人核心問題（Q）和解決方案(A)

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

tke@edge提供了類騰訊雲容器服務TKE控制檯， 能夠批量操做。

2. 服務不能跨局域網訪問

ServiceGroup， 經過對節點打上Zone的標籤， 同一個Zone的服務互通， 不一樣Zone的服務進行隔離， TKE@edge經過Deploymentgrid的資源來建立Deployment。

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

先用K8s的downward API講Pod的NodeName導入到POD環境變量， 經過node的zone信息， 結合client-go的API進行Label過濾， 這個須要上層服務發現組件支持， 爲啥不用K8s Ingress和Service方案， 很差意思， 不支持。

4. 服務流量的注入

經過nodePort暴露服務， 爲了不網卡爆掉須要利用多個宿主機nodePort承接流量， 採用consul來註冊服務， 相似騰訊雲CLB方案

5. 服務流量的導出

小問題

6. 服務分區域差別化配置，一套代碼， 雲端定製配置， 經過zone來關聯
將服務配置採用Configmap管理， 而且經過Volume機制將Configmap掛載到Pod的容器目錄， 那怎麼決定哪一個區域採用哪一個配置呢， 經過傳入NodeName的來進行選擇。這個問題解決好了以後， 新增商場(局域網)， 只須要在雲端配置好對應的配置， 就能夠自動擴容了， 碉堡了簡直。

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

成果展現

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

雲端部署

對於Deploymentgrid控制檯還沒開發好， 只能經過kubectl來建立資源

配置管理

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

成本和收益對比

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

如今呢： 秒級！！！並且能夠自動！！！真的是牛！！！搞完， 有預感感受本身要被裁了， 牛逼的程序員， 就是爲了革普通程序員的命。

總結展望

目前我以爲存在的問題是， tke@edge應該是基於k8s定製的， 資源佔用比較多，對於ai設備有些要求，好比要能跑docker， 還有硬件平臺和操做系統等一些要求；另外節點添加過程， 沒有爲節點批量打標籤的功能， 對於node標籤修改， 調度規則有待明確；對tke@edge單集羣能管理的節點極限、大規模Pod調度性能方面還沒有深刻研究。

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

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！