Kubernetes邊緣場景下常見的容器應用管理方案是什么

這篇文章主要介紹“Kubernetes邊緣場景下常見的容器應用管理方案是什么”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“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邊緣場景下常見的容器應用管理方案是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。