关于腾讯云:从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> 字段就是原先 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。

前期瞻望

目前须要通过部署 yaml 应用此性能，之后咱们将实现该性能的界面化操作，升高用户应用难度。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！