边缘容器作为以后热门的钻研方向，腾讯云容器团队在手不释卷做技术钻研的同时，也心愿能普惠到更多的云原生技术开发者们，为此推出【从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: DeploymentGridmetadata:    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/v1kind: DeploymentGridmetadata: name: deploymentgrid-demo namespace: defaultspec: 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应用此性能，之后咱们将实现该性能的界面化操作，升高用户应用难度。

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