如何利用云原生快速實作多地部署-有解無憂

作者張珊，騰訊云容器前端開發工程師，日常負責騰訊云邊緣容器 TKE@edge 相關控制臺前端開發，同時也開發前端工程化相關工具騰訊云服務網格 TCM 產品特性的研究和開發，

問題背景

在邊緣計算場景中，往往會出現一個集群管理多個邊緣站點（包括一個或者多個計算節點）的情況，每個站點都可以為用戶提供一套完整業務功能，由于受到網路限制，有業務聯系的服務之間不希望或者不能跨站點訪問，為了每個邊緣節點都能提供一套完成功能，一個邊緣站點都會去部署一組有業務邏輯聯系的服務，如果使用原生 K8s 進行管理，無法直接控制 Deployment 的 Pod 創建的具體節點位置，需要通過統籌規劃節點的親和性來間接完成;當邊緣站點數量以及需要部署的服務數量過多時，管理和部署都將極為復雜，乃至僅存在理論上的可能性，

解決方案

騰訊云邊緣容器 TKE@edge 開拓性地提出 ServiceGroup 的解決方案，ServiceGroup 可以便捷地在同集群的不同機房或區域各自部署一組服務，并且使得各個服務間的請求在本機房或本地域內部即可完成，避免服務跨地域訪問，

要理解 ServiceGroup，可能需要先了解以下幾個概念：

NodeUnit: 位于同一個邊緣站點的節點集合，其中節點有相同的某個 label，比如 zone:zone1，能夠把服務之間的呼叫限制在同一個 NodeUnit 內；
NodeGroup: 包含多個 NodeUnit，每個 NodeUnit 中的節點 label 包含某個相同的 key，可以部署 DeploymentGrid 中宣告的服務；
DeploymentGrid: TKE@edge 自行實作的 CRD (CustomResourceDefinition)，指定每個 NodeUnit 中部署的服務組；
ServiceGrid: TKE@edge 自行實作的 CRD，可以限制通過 service-name 訪問只會將請求發向同一個 NodeUnit 的節點，具體關聯見下圖：

可以看到 ServiceGroup 方案的核心點是實作 DeploymentGrid 和 ServiceGrid 兩個 CRD：

首先定義了資源欄位，基本欄位和 Deployment 和 Service 一致，并額外添加了 gridUniqKey 欄位；
其次實作相應的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 做不同的處理：

如果 pod 所屬的 Node 與當前節點屬于相同的 NodeUnit，則將該資源資訊轉發給下游的 kube-proxy，kube-proxy 會按照原先的流程創建對應的路由表；
如果 pod 所屬的 Node 與當前節點不屬于相同的 NodeUnit，則 application-grid-wrapper 會攔截該資訊，同時不轉發給 kube-proxy;

這樣一來，雖然用戶查看 endpoint 的時候能看到整個集群內該 service 所含的所有 endpoint，但是實際上節點的 service 的路由表項只含有相同 NodeUnit 內的節點的相關表項；這樣就保證了 NodeUnit 內的服務的互相訪問一定會限制在當前 NodeUnit 范圍內，從而避免跨節點組或者跨機房跨地域訪問的問題，