Kubernetes邊緣場(chǎng)景下常見的容器應(yīng)用管理方案是什么

這篇文章主要介紹“Kubernetes邊緣場(chǎng)景下常見的容器應(yīng)用管理方案是什么”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Kubernetes邊緣場(chǎng)景下常見的容器應(yīng)用管理方案是什么”文章能幫助大家解決問題。

1. 邊緣簡(jiǎn)單服務(wù)場(chǎng)景

在筆者接觸過的邊緣需求中部分用戶業(yè)務(wù)場(chǎng)景比較簡(jiǎn)單，如：撥測(cè)服務(wù)。這種場(chǎng)景的特點(diǎn)是用戶希望在每個(gè)節(jié)點(diǎn)部署相同的服務(wù)，并且每個(gè)節(jié)點(diǎn)起一個(gè) pod 即可，這種場(chǎng)景一般推薦用戶直接使用 daemonset 部署。關(guān)于 daemonset 的特點(diǎn)和使用方式讀者可以閱讀 kubernetes 官方文檔。

2.邊緣單站點(diǎn)部署微服務(wù)場(chǎng)景

第二種場(chǎng)景是部署邊緣 SAAS 服務(wù)，由于涉及客戶商業(yè)機(jī)密，此處暫不舉例。用戶會(huì)在一個(gè)邊緣機(jī)房?jī)?nèi)部署一整套微服務(wù)，包括賬號(hào)服務(wù)、接入服務(wù)、業(yè)務(wù)服務(wù)、存儲(chǔ)及消息隊(duì)列，服務(wù)之間借助kubernetes的dns做服務(wù)注冊(cè)和發(fā)現(xiàn)。這種情況下客戶可以直接使用 deployment和service，其中最主要的困難不在于服務(wù)管理而是邊緣自治能力。

關(guān)于deployment和service的使用方式讀者可以閱讀kubernetes 官方文檔，關(guān)于TKE@edge 邊緣自治能力我們將會(huì)在后續(xù)推出相關(guān)文章介紹。

3.邊緣多站點(diǎn)部署微服務(wù)場(chǎng)景

場(chǎng)景特點(diǎn)

• 邊緣計(jì)算場(chǎng)景中，往往會(huì)在同一個(gè)集群中管理多個(gè)邊緣站點(diǎn)，每個(gè)邊緣站點(diǎn)內(nèi)有一個(gè)或多個(gè)計(jì)算節(jié)點(diǎn)。

• 希望在每個(gè)站點(diǎn)中都運(yùn)行一組有業(yè)務(wù)邏輯聯(lián)系的服務(wù)，每個(gè)站點(diǎn)內(nèi)的服務(wù)是一套完整的微服務(wù)，可以為用戶提供服務(wù)

• 由于受到網(wǎng)絡(luò)限制，有業(yè)務(wù)聯(lián)系的服務(wù)之間不希望或者不能跨站點(diǎn)訪問

常規(guī)方案

1.將服務(wù)限制在一個(gè)節(jié)點(diǎn)內(nèi)

該方案的特點(diǎn)：

服務(wù)以daemonset方式部署，以便每個(gè)邊緣節(jié)點(diǎn)上均有所有服務(wù)的 pod。如上圖所示，集群內(nèi)有A、B兩個(gè)服務(wù)，以daemonset部署后每個(gè)邊緣節(jié)點(diǎn)上均有一個(gè) Pod-A和Pod-B

服務(wù)通過localhost訪問，以便將調(diào)用鏈鎖定在同一個(gè)節(jié)點(diǎn)內(nèi)。如上圖所示，Pod-A和Pod-B之間以localhost訪問

該方案的缺點(diǎn)：

每個(gè)服務(wù)在同一個(gè)節(jié)點(diǎn)內(nèi)只能有一個(gè) Pod，這是由于daemonset工作機(jī)制所限，對(duì)于需要在同一節(jié)點(diǎn)上運(yùn)行多個(gè) Pod的服務(wù)來說這個(gè)限制極為不便。

Pod需要使用 hostnetWork模式，以便Pod之間可以通過localhost+port訪問。這意味著需要用戶很好地管理服務(wù)對(duì)資源使用，避免出現(xiàn)資源競(jìng)爭(zhēng)，如端口競(jìng)爭(zhēng)。

2.服務(wù)在不同站點(diǎn)叫不同的名字

該方案的特點(diǎn)：

• 相同服務(wù)在不同站點(diǎn)叫不同的名字，以便將服務(wù)間的訪問鎖定在同一個(gè)站點(diǎn)內(nèi)。如上圖所示，集群內(nèi)有A、B兩個(gè)服務(wù)，在site-1中分別命名為 svr-A-1、Svc-B-1，在site-2中分別命名為 svr-A-2、Svc-B-2。

該方案的缺點(diǎn)：

• 服務(wù)在不同站點(diǎn)名字不同，因而服務(wù)之間不能簡(jiǎn)單地通過服務(wù)名A和B來調(diào)用，而是在 site-1中用 Svc-A-1、Svc-B-1，在site-2中用 Svc-A-2、Svc-B-2。對(duì)于借助 k8s dns 實(shí)現(xiàn)微服務(wù)的業(yè)務(wù)極為不友好。

場(chǎng)景痛點(diǎn)

1.k8s本身并不直接針對(duì)下述場(chǎng)景提供方案。

• 首先是眾多地域部署問題：通常，一個(gè)邊緣集群會(huì)管理許多個(gè)邊緣站點(diǎn)（每個(gè)邊緣站點(diǎn)內(nèi)有一個(gè)或多個(gè)計(jì)算資源），中心云場(chǎng)景往往是一些大地域的中心機(jī)房，邊緣地域相對(duì)中心云場(chǎng)景地域更多，也許一個(gè)小城市就有一個(gè)邊緣機(jī)房，地域數(shù)量可能會(huì)非常多；在原生k8s中，pod的創(chuàng)建很難指定，除非使用節(jié)點(diǎn)親和性針對(duì)每個(gè)地域進(jìn)行部署，但是如果地域數(shù)量有十幾個(gè)甚至幾十個(gè)，以需要每個(gè)地域部署多個(gè)服務(wù)的deployment為例，需要各個(gè)deployment的名稱和selector各不相同，幾十個(gè)地域，意味著需要上百個(gè)對(duì)應(yīng)的不同name，selector，pod labels以及親和性的部署yaml，單單是編寫這些yaml工作量就非常巨大；

• services服務(wù)需要與地域關(guān)聯(lián)，比如音視頻服務(wù)中的轉(zhuǎn)碼和合成服務(wù)，要在所屬地域內(nèi)完成接入的音視頻服務(wù)，用戶希望服務(wù)之間的相互調(diào)用能限制在本地域內(nèi)，而不是跨地域訪問。這同樣需要用戶同樣準(zhǔn)備上百個(gè)不同selector和name的本地域deployment專屬的service的部署yaml；

• 一個(gè)更復(fù)雜的問題是，如果用戶程序中服務(wù)之間的相互訪問使用了service名，那么當(dāng)前環(huán)境下，由于service的名稱各個(gè)地域都不相同，對(duì)于用戶而言，原來的應(yīng)用甚至都無法工作，需要針對(duì)每個(gè)地域單獨(dú)適配，復(fù)雜度太高。

2.另外，使用方為了讓容器化的業(yè)務(wù)在調(diào)度方案上與之前運(yùn)行在 vm或者物理機(jī)上的業(yè)務(wù)保持一致，他們很自然就想到為每個(gè) pod 分配一個(gè)公網(wǎng)IP，然而公網(wǎng)IP數(shù)量明顯是不夠用的。

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

為解決上述痛點(diǎn)，TKE@edge 開創(chuàng)性地提出和實(shí)現(xiàn)了 serviceGroup 特性，兩個(gè)yaml文件即可輕松實(shí)現(xiàn)即使上百地域的服務(wù)部署，且無需應(yīng)用適配或改造。

seviceGroup功能介紹

serviceGroup可以便捷地在共屬同一個(gè)集群的不同機(jī)房或區(qū)域中各自部署一組服務(wù)，并且使得各個(gè)服務(wù)間的請(qǐng)求在本機(jī)房或本地域內(nèi)部即可完成，避免服務(wù)跨地域訪問。

原生 k8s 無法控制deployment的pod創(chuàng)建的具體節(jié)點(diǎn)位置，需要通過統(tǒng)籌規(guī)劃節(jié)點(diǎn)的親和性來間接完成，當(dāng)邊緣站點(diǎn)數(shù)量以及需要部署的服務(wù)數(shù)量過多時(shí)，管理和部署方面的極為復(fù)雜，乃至僅存在理論上的可能性；與此同時(shí)，為了將服務(wù)間的相互調(diào)用限制在一定范圍，業(yè)務(wù)方需要為各個(gè)deployment分別創(chuàng)建專屬的service，管理方面的工作量巨大且極容易出錯(cuò)并引起線上業(yè)務(wù)異常。

serviceGroup就是為這種場(chǎng)景設(shè)計(jì)的，客戶只需要使用ServiceGroup提供的DeploymentGrid和ServiceGrid兩種tkeedge自研的kubernetes 資源，即可方便地將服務(wù)分別部署到這些節(jié)點(diǎn)組中，并進(jìn)行服務(wù)流量管控，另外，還能保證各區(qū)域服務(wù)數(shù)量及容災(zāi)。

serviceGroup關(guān)鍵概念

1.整體架構(gòu)

NodeUnit

• NodeUnit通常是位于同一邊緣站點(diǎn)內(nèi)的一個(gè)或多個(gè)計(jì)算資源實(shí)例，需要保證同一NodeUnit中的節(jié)點(diǎn)內(nèi)網(wǎng)是通的

• ServiceGroup組中的服務(wù)運(yùn)行在一個(gè)NodeUnit之內(nèi)

• tkeedge 允許用戶設(shè)置服務(wù)在一個(gè) NodeUnit中運(yùn)行的pod數(shù)量

• tkeedge 能夠把服務(wù)之間的調(diào)用限制在本 NodeUnit 內(nèi)

NodeGroup

• NodeGroup 包含一個(gè)或者多個(gè) NodeUnit

• 保證在集合中每個(gè) NodeUnit上均部署ServiceGroup中的服務(wù)

• 集群中增加 NodeUnit 時(shí)自動(dòng)將 ServiceGroup 中的服務(wù)部署到新增 NodeUnit

ServiceGroup

• ServiceGroup 包含一個(gè)或者多個(gè)業(yè)務(wù)服務(wù)

• 適用場(chǎng)景：1）業(yè)務(wù)需要打包部署；2）或者，需要在每一個(gè) NodeUnit 中均運(yùn)行起來并且保證pod數(shù)量；3）或者，需要將服務(wù)之間的調(diào)用控制在同一個(gè) NodeUnit 中，不能將流量轉(zhuǎn)發(fā)到其他 NodeUnit。

• 注意：ServiceGroup是一種抽象資源，一個(gè)集群中可以創(chuàng)建多個(gè)ServiceGroup

2.涉及的資源類型

DepolymentGrid

DeploymentGrid的格式與Deployment類似，<deployment-template>字段就是原先deployment的template字段，比較特殊的是gridUniqKey字段，該字段指明了節(jié)點(diǎn)分組的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字段，該字段指明了節(jié)點(diǎn)分組的label的key值；

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

3.使用示例

以在邊緣部署nginx為例，我們希望在多個(gè)節(jié)點(diǎn)組內(nèi)分別部署nginx服務(wù)，需要做如下事情：

1）確定ServiceGroup唯一標(biāo)識(shí)

這一步是邏輯規(guī)劃，不需要做任何實(shí)際操作。我們將目前要?jiǎng)?chuàng)建的serviceGroup邏輯標(biāo)記使用的 UniqKey為：zone。

2）將邊緣節(jié)點(diǎn)分組

這一步需要使用TKE@edge控制臺(tái)或者kubectl 對(duì)邊緣節(jié)點(diǎn)打 label，tke@edge控制臺(tái)操作入口如下圖：

3）界面在集群的節(jié)點(diǎn)列表頁，點(diǎn)擊 ”編輯標(biāo)簽“即可對(duì)節(jié)點(diǎn)打 label

• 借鑒 ”整體架構(gòu)“ 章節(jié)中的圖，我們選定 Node12、Node14，打上label，zone=NodeUnit1；Node21、Node23 打上label，zone=NodeUnit2。

• 注意：上一步中 label的key與ServiceGroup 的UniqKey一致，value是NodeUnit的唯一key，value相同的節(jié)點(diǎn)表示屬于同一個(gè)NodeUnit。同一個(gè) node 可以打多個(gè) label 從而達(dá)到從多個(gè)維度劃分 NodeUnit的目的，如給 Node12 再打上label，test=a1

• 如果同一個(gè)集群中有多個(gè)ServiceGroup請(qǐng)為每一個(gè)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字段設(shè)置為了zone，所以我們?cè)趯⒐?jié)點(diǎn)分組時(shí)采用的label的key為zone，如果有三組節(jié)點(diǎn)，分別為他們添加zone: zone-0, zone: zone-1 ,zone: zone-2的label即可；這時(shí)，每組節(jié)點(diǎn)內(nèi)都有了nginx的deployment和對(duì)應(yīng)的pod，在節(jié)點(diǎn)內(nèi)訪問統(tǒng)一的service-name也只會(huì)將請(qǐng)求發(fā)向本組的節(jié)點(diǎn)。

另外，對(duì)于部署了DeploymentGrid和ServiceGrid后才添加進(jìn)集群的節(jié)點(diǎn)組，該功能會(huì)在新的節(jié)點(diǎn)組內(nèi)自動(dòng)創(chuàng)建指定的deployment和service。

關(guān)于“Kubernetes邊緣場(chǎng)景下常見的容器應(yīng)用管理方案是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。