導語 | 云端管控、邊緣計算、處于局域網內的微服務如何做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的到來， 越來越多設備邊緣化， 計算也邊緣化， 邊緣容器和調度會是一個大有前景的方向，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/196009.html
標籤：其他