**導語** | 雲端管控、邊緣計算、處於區域網內的微服務如何做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://img2020.cnblogs.com/other/2041406/202010/2041406-20201029114840481-1699773