【從0到1學習邊緣容器系列2】之邊緣應用管理-有解無憂

邊緣容器作為當前熱門的研究方向，騰訊云容器團隊在孜孜不倦做技術研究的同時，也希望能貧訓到更多的云原生技術開發者們，為此推出【從0到1學習邊緣容器系列】，上次我們推出了第一篇《邊緣計算與邊緣容器的起源》，這次我們和大家來聊聊邊緣場景下的容器應用部署和管理，

大家對使用Kubernetes管理應用已經比較熟悉，但是邊緣場景下的應用部署和管理是否存在不同的需求呢？本文將和大家一起探討邊緣場景下常見的容器應用管理方案，

1. 邊緣簡單服務場景

在筆者接觸過的邊緣需求中部分用戶業務場景比較簡單，如：撥測服務，這種場景的特點是用戶希望在每個節點部署相同的服務，并且每個節點起一個 pod 即可，這種場景一般推薦用戶直接使用 daemonset 部署，關于 daemonset 的特點和使用方式讀者可以閱讀 kubernetes 官方檔案，

2.邊緣單站點部署微服務場景

第二種場景是部署邊緣 SAAS 服務，由于涉及客戶商業機密，此處暫不舉例，用戶會在一個邊緣機房內部署一整套微服務，包括賬號服務、接入服務、業務服務、存盤及訊息佇列，服務之間借助kubernetes的dns做服務注冊和發現，這種情況下客戶可以直接使用 deployment和service，其中最主要的困難不在于服務管理而是邊緣自治能力，

關于deployment和service的使用方式讀者可以閱讀kubernetes 官方檔案，關于TKE@edge 邊緣自治能力我們將會在后續推出相關文章介紹，

3.邊緣多站點部署微服務場景

場景特點

邊緣計算場景中，往往會在同一個集群中管理多個邊緣站點，每個邊緣站點內有一個或多個計算節點，
希望在每個站點中都運行一組有業務邏輯聯系的服務，每個站點內的服務是一套完整的微服務，可以為用戶提供服務
由于受到網路限制，有業務聯系的服務之間不希望或者不能跨站點訪問

常規方案

1.將服務限制在一個節點內

該方案的特點：

服務以daemonset方式部署，以便每個邊緣節點上均有所有服務的 pod，如上圖所示，集群內有A、B兩個服務，以daemonset部署后每個邊緣節點上均有一個 Pod-A和Pod-B

服務通過localhost訪問，以便將呼叫鏈鎖定在同一個節點內，如上圖所示，Pod-A和Pod-B之間以localhost訪問

該方案的缺點：

每個服務在同一個節點內只能有一個 Pod，這是由于daemonset作業機制所限，對于需要在同一節點上運行多個 Pod的服務來說這個限制極為不便，

Pod需要使用 hostnetWork模式，以便Pod之間可以通過localhost+port訪問，這意味著需要用戶很好地管理服務對資源使用，避免出現資源競爭，如埠競爭，

2.服務在不同站點叫不同的名字

該方案的特點：

相同服務在不同站點叫不同的名字，以便將服務間的訪問鎖定在同一個站點內，如上圖所示，集群內有A、B兩個服務，在site-1中分別命名為 svr-A-1、Svc-B-1，在site-2中分別命名為 svr-A-2、Svc-B-2，

該方案的缺點：

服務在不同站點名字不同，因而服務之間不能簡單地通過服務名A和B來呼叫，而是在 site-1中用 Svc-A-1、Svc-B-1，在site-2中用 Svc-A-2、Svc-B-2，對于借助 k8s dns 實作微服務的業務極為不友好，

場景痛點

1.k8s本身并不直接針對下述場景提供方案，

首先是眾多地域部署問題：通常，一個邊緣集群會管理許多個邊緣站點（每個邊緣站點內有一個或多個計算資源），中心云場景往往是一些大地域的中心機房，邊緣地域相對中心云場景地域更多，也許一個小城市就有一個邊緣機房，地域數量可能會非常多；在原生k8s中，pod的創建很難指定，除非使用節點親和性針對每個地域進行部署，但是如果地域數量有十幾個甚至幾十個，以需要每個地域部署多個服務的deployment為例，需要各個deployment的名稱和selector各不相同，幾十個地域，意味著需要上百個對應的不同name，selector，pod labels以及親和性的部署yaml，單單是撰寫這些yaml作業量就非常巨大；
services服務需要與地域關聯，比如音視頻服務中的轉碼和合成服務，要在所屬地域內完成接入的音視頻服務，用戶希望服務之間的相互呼叫能限制在本地域內，而不是跨地域訪問，這同樣需要用戶同樣準備上百個不同selector和name的本地域deployment專屬的service的部署yaml；
一個更復雜的問題是，如果用戶程式中服務之間的相互訪問使用了service名，那么當前環境下，由于service的名稱各個地域都不相同，對于用戶而言，原來的應用甚至都無法作業，需要針對每個地域單獨適配，復雜度太高，

2.另外，使用方為了讓容器化的業務在調度方案上與之前運行在 vm或者物理機上的業務保持一致，他們很自然就想到為每個 pod 分配一個公網IP，然而公網IP數量明顯是不夠用的，

綜上所述，原生k8s雖然可以變相滿足需求1），但是實際方案非常復雜，對于需求2）則沒有好的解決案，

為解決上述痛點，TKE@edge 開創性地提出和實作了 serviceGroup 特性，兩個yaml檔案即可輕松實作即使上百地域的服務部署，且無需應用適配或改造，

seviceGroup功能介紹

serviceGroup可以便捷地在共屬同一個集群的不同機房或區域中各自部署一組服務，并且使得各個服務間的請求在本機房或本地域內部即可完成，避免服務跨地域訪問，

原生 k8s 無法控制deployment的pod創建的具體節點位置，需要通過統籌規劃節點的親和性來間接完成，當邊緣站點數量以及需要部署的服務數量過多時，管理和部署方面的極為復雜，乃至僅存在理論上的可能性；與此同時，為了將服務間的相互呼叫限制在一定范圍，業務方需要為各個deployment分別創建專屬的service，管理方面的作業量巨大且極容易出錯并引起線上業務例外，

serviceGroup就是為這種場景設計的，客戶只需要使用ServiceGroup提供的DeploymentGrid和ServiceGrid兩種tkeedge自研的kubernetes 資源，即可方便地將服務分別部署到這些節點組中，并進行服務流量管控，另外，還能保證各區域服務數量及容災，

serviceGroup關鍵概念

1.整體架構

NodeUnit

NodeUnit通常是位于同一邊緣站點內的一個或多個計算資源實體，需要保證同一NodeUnit中的節點內網是通的
ServiceGroup組中的服務運行在一個NodeUnit之內
tkeedge 允許用戶設定服務在一個 NodeUnit中運行的pod數量
tkeedge 能夠把服務之間的呼叫限制在本 NodeUnit 內

NodeGroup

NodeGroup 包含一個或者多個 NodeUnit
保證在集合中每個 NodeUnit上均部署ServiceGroup中的服務
集群中增加 NodeUnit 時自動將 ServiceGroup 中的服務部署到新增 NodeUnit

ServiceGroup

ServiceGroup 包含一個或者多個業務服務
適用場景：1）業務需要打包部署；2）或者，需要在每一個 NodeUnit 中均運行起來并且保證pod數量；3）或者，需要將服務之間的呼叫控制在同一個 NodeUnit 中，不能將流量轉發到其他 NodeUnit，
注意：ServiceGroup是一種抽象資源，一個集群中可以創建多個ServiceGroup

2.涉及的資源型別

DepolymentGrid

DeploymentGrid的格式與Deployment類似，欄位就是原先deployment的template欄位，比較特殊的是gridUniqKey欄位，該欄位指明了節點分組的label的key值；

apiVersion: tkeedge.io/v1 
kind: DeploymentGrid
metadata:  
  name:  
  namespace: 
 spec:  
  gridUniqKey: <NodeLabel Key>  
  <deployment-template>

ServiceGrid

ServiceGrid的格式與Service類似，欄位就是原先service的template欄位，比較特殊的是gridUniqKey欄位，該欄位指明了節點分組的label的key值；

apiVersion: tkeedge.io/v1 
kind: ServiceGrid 
metadata:  
  name:  
  namespace: 
spec:  
  gridUniqKey: <NodeLabel Key>  
  <service-template>

3.使用示例

以在邊緣部署nginx為例，我們希望在多個節點組內分別部署nginx服務，需要做如下事情：

1）確定ServiceGroup唯一標識

這一步是邏輯規劃，不需要做任何實際操作，我們將目前要創建的serviceGroup邏輯標記使用的 UniqKey為：zone，

2）將邊緣節點分組

這一步需要使用TKE@edge控制臺或者kubectl 對邊緣節點打 label，tke@edge控制臺操作入口如下圖：

3）界面在集群的節點串列頁，點擊 ”編輯標簽“即可對節點打 label

借鑒 ”整體架構“ 章節中的圖，我們選定 Node12、Node14，打上label，zone=NodeUnit1；Node21、Node23 打上label，zone=NodeUnit2，
注意：上一步中 label的key與ServiceGroup 的UniqKey一致，value是NodeUnit的唯一key，value相同的節點表示屬于同一個NodeUnit，同一個 node 可以打多個 label 從而達到從多個維度劃分 NodeUnit的目的，如給 Node12 再打上label，test=a1
如果同一個集群中有多個ServiceGroup請為每一個ServiceGroup分配不同的Uniqkey

4）部署deploymentGrid

apiVersion: tkeedge.io/v1
kind: DeploymentGrid
metadata:
 name: deploymentgrid-demo
 namespace: default
spec:
 gridUniqKey: zone
 template:
  selector:
   matchLabels:
    appGrid: nginx
  replicas: 2
  template:
   metadata:
    labels:
     appGrid: nginx
   spec:
    containers:
    \- name: nginx
     image: nginx:1.7.9
     ports:
     \- containerPort: 80

apiVersion: tkeedge.io/v1 
kind: ServiceGrid 
metadata:  
  name: servicegrid-demo  
  namespace: default 
spec:  
  gridUniqKey: zone  
  template:   
    selector:    
     appGrid: nginx   
    ports:   
    \- protocol: TCP    
     port: 80    
     targetPort: 80
    sessionAffinity: ClientIP

5）部署serviceGrid

可以看到gridUniqKey欄位設定為了zone，所以我們在將節點分組時采用的label的key為zone，如果有三組節點，分別為他們添加zone: zone-0, zone: zone-1 ,zone: zone-2的label即可；這時，每組節點內都有了nginx的deployment和對應的pod，在節點內訪問統一的service-name也只會將請求發向本組的節點，

另外，對于部署了DeploymentGrid和ServiceGrid河駁加進集群的節點組，該功能會在新的節點組內自動創建指定的deployment和service，