導語 | 雲端管控、邊緣計算、處於區域網內的微服務如何做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的到來， 越來越多裝置邊緣化， 計算也邊緣化， 邊緣容器和排程會是一個大有前景的方向。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
