做者張珊,騰訊雲容器前端開發工程師,平常負責騰訊雲邊緣容器 TKE@edge 相關控制檯前端開發,同時也開發前端工程化相關工具。前端
在邊緣計算場景中,每每會出現一個集羣管理多個邊緣站點(包括一個或者多個計算節點)的狀況。每一個站點均可覺得用戶提供一套完整業務功能。因爲受到網絡限制,有業務聯繫的服務之間不但願或者不能跨站點訪問。爲了每一個邊緣節點都能提供一套完成功能,一個邊緣站點都會去部署一組有業務邏輯聯繫的服務,若是使用原生 K8s 進行管理, 沒法直接控制 Deployment 的 Pod 建立的具體節點位置,須要經過統籌規劃節點的親和性來間接完成;當邊緣站點數量以及須要部署的服務數量過多時,管理和部署都將極爲複雜,乃至僅存在理論上的可能性。node
騰訊雲邊緣容器服務 (Tencent Kubernetes Engine for Edge,簡稱 TKE@edge)是騰訊雲容器服務推出的用於從中心雲管理邊緣雲資源的容器系統,它開拓性地提出 ServiceGroup 的解決方案。ServiceGroup 能夠便捷地在同集羣的不一樣機房或區域各自部署一組服務,而且使得各個服務間的請求在本機房或本地域內部便可完成,避免服務跨地域訪問。前端工程化
要理解 ServiceGroup,可能須要先了解如下幾個概念:api
能夠看到 ServiceGroup 方案的核心點是實現 DeploymentGrid 和 ServiceGrid 兩個 CRD:網絡
controller:DeploymentGrid controller
和 ServiceGrid controller,不斷將建立的 DeploymentGrid 和 ServiceGrid 資源調和到指望的 Deployment 和 Service,而且聯合 ServiceGrid,DeploymentGrid 上的gridUniqKey
字段和節點的標籤, 將 Deployment 部署在每一個 NodeUnit 內。那麼如何保證流量限制在節點組的範圍內呢?application-grid-wrapper 組件能夠幫助實現。該組件代理 kube-proxy 的請求,同時監聽 apiserver 的 node、service 和 endpoint 資源。根據 pod 信息中所屬 Node 是否與當前節點共屬相同的 NodeUnit 作不一樣的處理:app
若是 pod 所屬的 Node 與當前節點屬於相同的 NodeUnit,則將該資源信息轉發給下游的 kube-proxy,kube-proxy 會按照原先的流程建立對應的路由表;ide
這樣一來,雖然用戶查看 endpoint 的時候能看到整個集羣內該 service 所含的全部 endpoint,可是實際上節點的 service 的路由表項只含有相同 NodeUnit 內的節點的相關表項;這樣就保證了 NodeUnit 內的服務的互相訪問必定會限制在當前 NodeUnit 範圍內,從而避免跨節點組或者跨機房跨地域訪問的問題。wordpress
TKE@edge 團隊已經實現 ServiceGroup 功能而且將其產品化,具體操做以下:工具
假設已在騰訊雲控制檯建立邊緣集羣,而且該集羣下已有節點;若是不清楚如何建立,能夠參考 邊緣集羣文檔。學習
經過上述操做,咱們就劃分了兩個 NodeUnit,而且每一個 NodeUnit 都部署 wordpress 服務;在節點內經過 service-name 訪問也只會將請求發向本組的節點。
本文從問題產生、方案設計和實際演示介紹 ServiceGroup 相關原理, 以及如何使用 ServiceGroup 簡單快捷實現多地部署。