完爆!用邊緣容器,竟能秒級實現團隊七八人一周的工作量

導語 | 雲端管控、邊緣計算、處於局域網內的微服務如何做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 工作原理圖

引用自K3S官網//k3s.io/

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的到來, 越來越多設備邊緣化, 計算也邊緣化, 邊緣容器和調度會是一個大有前景的方向。

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