| 编辑推荐: |
本文主要讲解了什么是边缘计算？边缘计算为什么重要？边缘计算集中式的3大难题、边缘计算发展现状，管理边缘容器的方案以及边缘场景下的容器应用部署和管理。
本文来自于博客园 ，由火龙果软件Anna编辑推荐。 |
|
边缘容器的起源
30秒了解什么是边缘计算？边缘计算为什么重要？
根据边缘计算产业联盟的定义，边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。边缘计算将计算、网络、存储、带宽等能力从云延伸到网络边缘的新型架构模式，其能效友好、带宽充足、延迟低等特性很好地补充了集中化计算模式遇到的问题。
图片：边缘计算技术作为5G网络架构中核心，智能化改造趋势分析
30秒看完边缘计算集中式的3大难题
随着信息技术的发展，计算资源模式由单一的集中化变成了往集中化和边缘化两个方向的分化，集中化即当前如火如荼的云计算，边缘化即最近几年兴起的边缘计算。云计算给世界带来的变革大家有目共睹，但有了云计算为什么还需要边缘计算呢？这就需要一起来了解集中式的云计算中遇到的问题：
PUE 问题。PUE（Power Usage Effectiveness）电源使用效率，是评价数据中心能源效率的指标。集中式数据中心耗电量巨大，属于高耗能产业，不符合绿色能源、节能减排理念，其规模和数量受政策限制。根据
IDC 统计，全球数据中心数量在 2015 年达到顶峰，然后开始逐年下降，预计 2021 年会比 2015
年降低 15%。
数据来源：数据中心白皮书数据及预测、光大证券研究所
安全隐私问题。应用和数据是企业的核心资源，随着越来越多的行业互联网化，如何保证应用和数据的可靠性、安全性是企业最关心的议题之一。
技术新需求问题。随着技术的发展，单靠数据中心已经很难满足需求。
典型场景包括：
1）物联网技术，大量的智能终端位于网络边缘，集中计算模式不能满足所有应用场景；
2）移动互联网技术的发展，5G 为移动互联网注入了巨大的能量，集中计算模式满足不了直播、游戏、音视频等应用在带宽、延迟等方面的需求。
30秒了解边缘计算发展现状
目前边缘计算研究领域主要集中在：计算模型、体系结构、信息安全等方面。
计算模型主要有：雾计算、移动边缘计算、智能边缘计算等，涵盖物联网、无线通信网、移动互联网等领域。
体系结构有：ETSI 参考架构、MEC 架构、ECC 参考架构、SWoT 架构、AI-EC 架构。
目前边缘计算研究热点主要是延迟敏感、实时性要求高的场景，如：
云基础设施 2.0。国内外各大云厂商逐渐从 “中心云” 模式转换到 “云计算 + 边缘计算”模式，细化出多种行业云：金融云、游戏云、直播云、教育云等。
物联网。随着 IoT 规模的快速增长，越来越多的数据无法直接上传到云中心，在设备侧完成数据存储、分析、处理将越来越重要
工业互联网。工业互联网的本质和核心是把设备、生产线、工厂、供应商、产品和客户紧密地连接融合起来，从而提高效率，推动整个制造服务体系智能化。
CDN。CDN 本质上是在靠近用户的位置分发内容，边缘计算可以让 CDN 离用户更近，提供更低时延、更大带宽的服务。
5G。国家标准组织 ETSI 认为移动边缘计算 MEC 是一种将基站和互联网业务深度融合的技术，可以灵活地在物理网络切分出逻辑网络以满足复杂多变的应用需求。
15秒扫完边缘计算带来的挑战
与强劲的市场需求矛盾的是，边缘计算目前尚没有一套成熟的技术体系，存在的问题包括：
缺失技术标准和规范
没有统一的体系结构
边缘设备异构严重
边缘设备数量庞大、分布广阔
服务质量保障
边缘容器诞生带来的希望之光
容器技术是最近几年发展势头很好的技术之一，相比物理机和虚拟机，容器技术非常轻量级，并且具有如下优点：部署简单、支持多环境、启动时间更短、易扩容、易迁移，比较常见的容器技术有
Docker 和 Containerd。这些特点很好地解决了 “边缘设备异构严重” 这一问题。
但是在管理主机数量规模较大的业务场景时，单机容器管理方案往往力不从心。Kubernetes 是当前最流行的容器编排和管理系统，它实现了一套高效的应用管理、应用自修复、资源管理、线上运维和排障机制，并且形成了监控告警、服务网格、日志及调用链分析、CI/CD
等方面的一系列生态。这些有助于解决 “缺失技术标准和规范”、“没有统一的体系结构”、“服务质量保障”、“管理成本高”等方面的问题。
然而，Kubernetes 原本是针对集中式资源管理场景设计，简单地应用到边缘计算场景会遇到诸多不适应，导致系统不稳定甚至在某些场景下运行不起来。
边缘容器的目的就是通过解决 Kubernetes 所有不适应边缘计算场景的点，实现使用集中式的 Kubernetes
来管理分散的边缘设备。
边缘容器也遇到了挑战
通常来说，为了管理上的方便集群控制中心都是集中式设计、部署在指定地区，或者为了保障高可用有选择性地部署在某几个地区。目前较常见情况是控制中心部署在云厂商云端中心机房（公有云）或者用户中心机房（私有云）；边缘设备位于边缘云机房、移动边缘站点、用户现场设备。
为了让 Kubernetes 更好地用于边缘计算场景，我们有必要整理出边缘计算场景的主要特性：
云边弱网络。控制中心和边缘设备之间网络较复杂，因特网、以太网、5G、WIFI 等形态均有可能，网络质量差次不齐没有保障。
边缘设备之间网络情况复杂。边缘设备之间有可能是局域网，也有可能位于不同的地区、相互不通。
边缘设备资源紧张。相对而言，边缘计算设备从边缘云、移动边缘站点、用户现场设备，单个设备的硬件资源逐渐变少。其中用户现场单设备内存有可能不到
1G。
边缘服务管理要求复杂。在中心云机房，应用可以根据节点资源择优部署；而在边缘场景，应用部署需要考虑网络和地域等属性。
1分钟讲述管理边缘容器的方案
业界目前有多种边缘容器管理的解决方案，腾讯云针对私有云和公有云分别推出 tinykube 和 TKE@edge。这里主要介绍公有云TKE@edge整套方案致力于保持对原生
Kubernetes 功能及其生态完全兼容、以尽量少的改动达到让原生 Kubernetes 支持边缘计算场景的目标。
整体架构如下：
TKE@edge 整体是云端管控架构，Master 位于中心，边缘节点全部是 worker 节点。云边引入
tunnel 和 hub 两个通信组件，支持身份认证和数据加密；云端引入两个自研的 Controller：serviceGroup-Controller、observer-Controller；边端引入
store 和 observer；用户集群 master 组件运行在云端 metacluster 基础集群，用户集群数据统一保存在云端
Etcd 集群；使用者可通过 TKE@edge 控制台或者在本地使用 kubectl 工具直接管理自己的集群，也可以基于
TKE@edge 之上二次开发管理平台。
TKE@egde解决了边缘容器什么问题 云边弱网络。hub 组件的核心作用是解决边到云弱网络问题，该组件代理了边缘节点上所有核心组件向
apiserver 发起的请求，并且将关键数据持久化保存在本地。当云边网络异常时，节点侧依然可以使用这些数据，避免因云边弱网络原因引起业务异常。另外，边缘弱网络很容易触发
Kubernetes 驱逐机制，引起不符合预期的 Pod 驱逐动作，TKE@edge 首创分布式健康检测机制可以智能地识别驱逐时机，保障系统在弱网络下正常运转。
边缘设备之间网络情况复杂。复杂性表现在一个集群内的节点极可能分布在多个边缘局域网内（通常称为节点或者站点，site，为避免与
Kubernetes 集群中的节点一词混淆，后面均称站点），意味着同一站点内的节点之间可达，站点之间的节点之间通常不可达，这会影响集群内服务之间的调用。TKE@edge
首创 serviceGroup 资源，该资源支持用户指定服务之间流量拓扑策略，实现按策略访问。
边缘设备资源紧张。原生 Kubernetes 中主要是 Master 组件资源消耗较大，节点侧资源消耗并不多。TKE@edge
采用云端管控架构，让 Master 组件部署在资源丰富的中心侧，边缘侧只运行 kubelet、kube-proxy
等资源消耗少的组件，边缘侧只需要较少资源即可满足条件。
边缘服务管理要求复杂。集群内包含多个站点时，通常希望在每个站点部署一整套微服务，理论上我们可以通过给每一个服务在每一个站点分配不同的名字来实现目的，实际上这么操作会带来两方面的问题：1）服务名太多难以管理；2）同一服务在不同站点名字不同，难以通过服务名访问；3）当增加或者撤销站点时需要人工添加和删除对应的
yaml，这无疑会带来管理灾难。TKE@edge 首创 serviceGroup 能自动完成上述操作，大大降低管理困难。
TKE@edge闪闪发光的亮点 serviceGroup。能解决边缘设备之间网络复杂及边缘服务管理困难问题。客户只需要使用 ServiceGroup
提供的 DeploymentGrid 和 ServiceGrid 两种 TKE@edge 自研的 Kubernetes
资源，即可一键将服务部署到所有边缘站点中，同时还能保证服务在各站点的实例数量、提高应用在每个站点的高可用。
hub。实现关键数据本地持久化，保障系统在弱网络下正常运转。即使节点与 Master 断网的情况下应用也不受影响，并且可以做到节点重启后应用自动恢复。
observer。分布式健康检测机制，可以识别边缘节点健康情况，智能识别应用驱逐的时机。
tunnel。云边隧道机制，允许从云端登录容器、查看日志、往容器上传下载文件。对于无公网地址的设备，该功能可以明显提升运维效率。
定制网络组件。站点整体与云端失联情况下服务正常运行，并且允许边缘节点发生重启。
高可用
Master 组件。托管于腾讯云有 SLA 保证、并且有腾讯云 TKE 团队运维；Master
组件支持自动扩缩容，可根据集群压力自动调整实例数量，以满足业务需求。
边缘节点和站点。目前可以做到边缘端运行微服务时，边缘站点整体与管控端掉线的情况下业务不受影响，掉线期间允许计算资源发生重启。
业务应用。保证站点内业务 Pod 可用数量，支持一个服务在同一节点上运行多个 Pod。
易用性
监控告警。支持集群和Pod级监控告警，维度包括 CPU、内存、网络，告警方式有电话、短信、微信、邮件
边缘资源管理。一键添加、删除边缘节点（限腾讯云边缘计算资源）
应用管理。一键部署、更新、删除应用，Helm 应用打包管理（规划中）
界面化操作。目前集群管理、节点管理、Workload 和常用 Kubernetes 资源管理、日志和事件查询等均可以通过
Web 界面完成，大大降低使用门槛。（产品目前是白名单开放，使用前请在腾讯云官网上申请加白名单）
CICD。支持使用蓝盾，支持 Coding 系统（规划中）
帮扶运维
云端登录边缘应用容器内部，云端往/从容器内部传输文件
云端查看业务日志、事件
应用日志采集（规划中）
接下来聊聊边缘场景下的容器应用部署和管理。
大家对使用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字段，比较特殊的是gridUniqKey字段，该字段指明了节点分组的label的key值；
apiVersion: tkeedge.io/v1
kind: DeploymentGrid
metadata:
name:
namespace:
spec:
gridUniqKey: <NodeLabel Key>
<deployment-template> |
ServiceGrid
ServiceGrid的格式与Service类似，字段就是原先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使用此功能，之后我们将实现该功能的界面化操作，降低用户使用难度。
|
