共計 4955 個字符，預計需要花費 13 分鐘才能閱讀完成。

這篇文章主要介紹“Kubernetes 邊緣場景下常見的容器應用管理方案是什么”的相關知識，丸趣 TV 小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“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 字段就是原先 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 控制臺操作入口如下圖：

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。

關于“Kubernetes 邊緣場景下常見的容器應用管理方案是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注丸趣 TV 行業資訊頻道，丸趣 TV 小編每天都會為大家更新不同的知識點。