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

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

## 1. 邊緣簡單服務場景

![img](https://main.qcloudimg.com/raw/2055d9be72467eed1263b0834d3e1f81.jpg)

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

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

![img](https://main.qcloudimg.com/raw/22713191e5b7451002c624f132962622.jpg)

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

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

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

![img](https://main.qcloudimg.com/raw/41033756be456f6cfa81d250b31c3502.jpg)

### 場景特點

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

### 常規方案

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

![img](https://main.qcloudimg.com/raw/a252b582e6544469b1cbae080f18ca02.jpg)

**該方案的特點：**

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

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

**該方案的缺點：**

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

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

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

![img](https://main.qcloudimg.com/raw/28a7c732fb4c8a88182f67b851f6b622.jpg)

**該方案的特點：**

- 相同服務在不同站點叫不同的名字，以便將服務間的訪問鎖定在同一個站點內。如上圖所示，叢集內有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.整體架構**

![img](https://main.qcloudimg.com/raw/f33b6e80caf4944a2670e1796799acd5.jpg)

**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>欄位就是原先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>欄位就是原先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控制檯操作入口如下圖：

![img](https://main.qcloudimg.com/raw/b2383e32575b7caa29816fd6e70e2515.png)

**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也只會將請求發向本組的節點。

![img](https://main.qcloudimg.com/raw/b2383e32575b7caa29816fd6e70e2515.png)

另外，對於部署了DeploymentGrid和ServiceGrid後才新增進叢集的節點組，該功能會在新的節點組內自動建立指定的deployment和service。

## 後期展望

目前需要透過部署yaml使用此功能，之後我們將實現該功能的介面化操作，降低使用者使用難度。</service-template></nodelabel></service-template></deployment-template></nodelabel></deployment-template>

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

相關文章

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