完爆!用邊緣容器,竟能秒級實現團隊七八人一週的工作量
阿新 • • 發佈:2020-10-29
**導語** | 雲端管控、邊緣計算、處於區域網內的微服務如何做Devops呢?騰訊優圖業務是結合了騰訊雲邊緣容器TKE@edge來做服務Devops, 並對服務做了自定義定製, 以支援相應的業務場景。本篇文章接下來將詳細展示實踐落地細節,希望能夠給大家帶來靈感。
## 背景
所謂私有云, 其實就是在多個區域網玩服務,基本等同於開發運維全包。每個區域網都要需要一個跳板機、區域網環境(每個區域網環境不一)以及硬體、軟體等,然後還需要大量人肉運維部署升級服務(傳統做法譬如ansible, fabric, scp, 諸如拷貝、配置更新、版本維護都很麻煩, 所以棄用), 而且不同區域網服務需要差異化配置, 配置管理也是問題。
筆者也思考過做一套區域網自動化部署的東西, 思路就是在區域網部署agent來和雲端打通, 然後各種傳資料發命令。就在這個時候突然看到同事在寫TKE@edge的東西, 看了之後感覺是我想要的東西, 於是就開幹了。
![](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114836906-1542609410.png)
## 現狀
**批量部署問題**:為了批量部署部署, 採用了scp、fabric部署工具, 每個區域網採用不同配置, 要改配置的話就需要挨個登入機器修改;
**差異化配置問題**:為了解決配置問題, 採用配置中心, 將所有配置集中化管理, 但是每個區域網的配置中心還是不一樣, 儘管已經收斂到一個服務了, 還是感覺很累且容易出錯;
**服務上下游呼叫**:採用自研服務發現元件, 結合了consul的DNS服務功能, 上下游服務通過DNS定址。 這個問題可以很好地解決。
![](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114837261-2025108099.png)
## TKE@edge簡介
有沒有一種能在雲上控制服務部署升級的產品呢?據瞭解,TKE@edge就是其中一種,它可以比較好地解決這個問題。
另外,業界還有一個開源解決方案K3s,這個方案雖然通過裁剪讓資源有限的裝置也能執行 K8s,然而依然不能解決我最關心的幾個問題,如:
1)雲端運維;
2)在一個叢集中管理跨網路和地域的邊緣節點;
3)簡化不同地域差異化配置管理問題。
接下來,我們來分別看下K3s、TKE@edge的工作原理以及兩者之間的差異。
##### K3s 工作原理圖
![引用自K3S官網https://k3s.io/](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114837569-1558994402.png)
##### TKE@edge架構圖
![](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114838065-1633128643.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://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114839253-984825179.png)
> 對於Deploymentgrid控制檯還沒開發好, 只能通過kubectl來建立資源
### 配置管理
![](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114839745-2119177880.png)
這兩個棘手問題解決了, 就大功告成了。
### 成本和收益對比
**過去:**部署一套商場多個服務, 一個團隊7八個人 一週(多則兩週)的人力天, 上下游打通;
**現在呢:** 秒級!!!而且可以自動!!!真的是牛!!!搞完, 有預感感覺自己要被裁了, 牛逼的程式設計師, 就是為了革普通程式設計師的命。
## 總結展望
目前我覺得存在的問題是, tke@edge應該是基於k8s定製的, 資源佔用比較多,對於ai裝置有些要求,比如要能跑docker, 還有硬體平臺和作業系統等一些要求;另外節點新增過程, 沒有為節點批量打標籤的功能, 對於node標籤修改, 排程規則有待明確;對tke@edge單叢集能管理的節點極限、大規模Pod排程效能方面尚未深入研究。
隨著5G的到來, 越來越多裝置邊緣化, 計算也邊緣化, 邊緣容器和排程會是一個大有前景的方向。
>【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多幹貨!!
![](https://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114840481-1699773