**導語** | 雲端管控、邊緣計算、處於區域網內的微服務如何做Devops呢？騰訊優圖業務是結合了騰訊雲邊緣容器TKE@edge來做服務Devops， 並對服務做了自定義定製， 以支援相應的業務場景。本篇文章接下來將詳細展示實踐落地細節，希望能夠給大家帶來靈感。

## 背景

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

筆者也思考過做一套區域網自動化部署的東西， 思路就是在區域網部署agent來和雲端打通， 然後各種傳資料發命令。就在這個時候突然看到同事在寫TKE@edge的東西， 看了之後感覺是我想要的東西， 於是就開幹了。
![](https://main.qcloudimg.com/raw/21fe1130a8d20236f618655a447e827e.png)

## 現狀

**批次部署問題**：為了批次部署部署， 採用了scp、fabric部署工具， 每個區域網採用不同配置， 要改配置的話就需要挨個登入機器修改；
**差異化配置問題**：為了解決配置問題， 採用配置中心， 將所有配置集中化管理， 但是每個區域網的配置中心還是不一樣， 儘管已經收斂到一個服務了， 還是感覺很累且容易出錯；
**服務上下游呼叫**：採用自研服務發現元件， 結合了consul的DNS服務功能， 上下游服務透過DNS定址。 這個問題可以很好地解決。
![](https://main.qcloudimg.com/raw/82c47ab4f946be80f948d3ee80a05b55.png)

## TKE@edge簡介

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

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

1）雲端運維；

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

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

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

##### K3s 工作原理圖

![引用自K3S官網https://k3s.io/](https://main.qcloudimg.com/raw/9cf933e37678ba48daeaea0959611a28.png)

##### TKE@edge架構圖

![](https://main.qcloudimg.com/raw/316d37aab9884f2aba5196046f9e57f1.png)

> 引用自【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. 一些次要問題， 不在此列舉了**

## 成果展示

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

### 雲端部署

![](https://main.qcloudimg.com/raw/f3135cce41d2e7ecf7d47c2898f6ee53.png)

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

### 配置管理

![](https://main.qcloudimg.com/raw/b58710d73f8380f828ae0ce6b791ad9c.png)

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

### 成本和收益對比

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

**現在呢：** 秒級！！！而且可以自動！！！真的是牛！！！搞完， 有預感感覺自己要被裁了， 牛逼的程式設計師， 就是為了革普通程式設計師的命。

## 總結展望

目前我覺得存在的問題是， tke@edge應該是基於k8s定製的， 資源佔用比較多，對於ai裝置有些要求，比如要能跑docker， 還有硬體平臺和作業系統等一些要求；另外節點新增過程， 沒有為節點批次打標籤的功能， 對於node標籤修改， 排程規則有待明確；對tke@edge單叢集能管理的節點極限、大規模Pod排程效能方面尚未深入研究。

隨著5G的到來， 越來越多裝置邊緣化， 計算也邊緣化， 邊緣容器和排程會是一個大有前景的方向。

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

相關文章