白话边缘计算解决方案 SuperEdge

1、SuperEdge的定义

SuperEdge is an open source container management system for edge computing to manage compute resources and container applications in multiple edge regions. These resources and applications, in the current approach, are managed as one single Kubernetes cluster.git

翻译过来的意思是：github

SuperEdge 是开源的边缘容器解决方案，可以在单 Kubernetes 集群中管理跨地域的资源和容器应用。算法

咱们经过关键词来简单解释下这句话：api

开源

这个方案虽然是由腾讯云容器团队开源的边缘容器解决方案，但这是一个彻底第三方中立的开源项目。官宣当日分别由 Intel、VMware、美团、寒武纪、首都在线、虎牙、腾讯共同官宣开源，并不禁腾讯一家说了算，在边缘有想法的同窗和企业也欢迎参与，共建边缘，共同推动边缘计算在实际场景的落地和发展。缓存

边缘容器解决方案

这句话不用过多的解释，主要作容器的编排和调度管理。可是目前作容器的调度编排最火的方案是Kubernetes，为何不拿 Kubernetes 直接作边缘容器的编排和调度管理呢？这个后面再解释。微信

单 Kubernetes 集群

仍是用 Kubernetes 作容器编排调度，深刻了解后，发现 SuperEdge 团队并无删减 Kubernetes 任意一行代码，也就是说彻底 Kubernetes 原生，具有 Kubernetes 对应版本的所有特性。网络

单 Kubernetes 集群中管理跨地域的资源和容器应用

重点词落在单和跨地域。为何要在单 Kubernetes 集群中管理跨地域的资源和容器应用呢？场景、场景、仍是场景决定的。架构

简单一个例子，有个连锁超市，10个营业网点，每一个网点都有一个当日的特价广告推销程序。各个营业网点之间，以及营业网点和中心管控面之间，网络彻底不通，彻底独立，造成地域隔离。每一个网点的广告程序彻底同样，推送的内容也彻底同样，目标是可以在单 Kubernetes 集群中，管理10个营业网点，像管理一个网点同样轻松。app

2、可能存在的问题

看了SuperEdge官网的特性，我也没彻底懂。什么是 Network tunneling? 为何要 Built-in edge orchestration capability? 介绍的特性到底能够解决什么问题，我也存疑？

仍是拿有个连锁超市，10个营业网点，中心和网点之间，网点和网点之间网络不通，但要部署运维同一个应用程序来设计下解决方案，看看这其中须要解决的问题，也许对SuperEdge的特性和设计初衷就能就更好的掌握了。

咱们看下这个例子在实际的场景中，咱们将要面对的问题：

1.10个营业网点同样的程序

虽然例子中只有10个营业网点，但实际中可能成百上千。咱们也要考虑之后的扩展性，成百上千网点要让同一个程序所有都同步起来作一件事，难度天然不小。要是管理成百上千的营业网点，就像管理一个网点同样轻松容易，那确实轻松很多。

2.中心和网点之间，网点和网点之间网络不通

现实中真实存在这样的场景，毕竟专线耗时耗力成本高。真实的场景比较复杂，各个网点多是一个小机房，也多是一个小盒子，没有公网IP。有的网点几百个盒子，只有一个盒子能够访问外网，有的甚至全部的盒子都没法访问外网，部署的时候就至关的困难。

3.弱网、地域相隔甚远

边缘的场景不比中心，边缘的不少盒子，好比摄像头，各个区域均可能是走公网访问或者WIFI链接，时不时断网，短则几分钟，或者几个小时，长则几天都连不上网，都属于正常现象。更有甚者，断电重启一下……要在这种场景下保证边缘业务可以正常提供服务，尽量提升服务的可用性，就是挑战了。

4.如何知道边缘节点的健康性？

边缘节点不健康了，就要把异常节点的服务调度到可用的节点上去，尽量的保证服务的健康性。中心和边缘网络不通，各个网点的网络又不通的状况下，要怎么知道网点节点的健康性？

5.资源有限

嵌入式边缘节点每每资源有限，1G1C很常见，如何保证边缘资源有限的状况下，把边缘服务运行起来？

6.资源混部

中心云Kubernetes既想管理中心云应用，又想管理边缘应用，怎么搞呢？

...

不展开说了，这里面要考虑的细节问题仍是比较多的，不能等在实际场景中碰到了才去解决，必定要在方案设计的时候，就尽量的解决掉将要面对的问题。这样咱们才能把有限的时间投入到具体的业务中，而不是和底层架构较劲。

3、思考本身的解决方案

若是咱们遇到上面的问题，如何解决呢？

1.10个营业网点同样的程序

让一个程序以不变的环境，一份程序处处运行，比较好的解决方式是什么？容器，一个测试好的镜像，只要底层机型系统一致，运行起来问题不大。

2.用什么作容器的编排调度呢？

固然是 Kubernetes，可问题是开源社区的 Kubernetes 能直接拿来用吗？答案是：不能！为何？由于Kubernetes官网网络模型中明确代表：

Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):
- pods on a node can communicate with all pods on all nodes without NAT
- agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

也就说 Kubernetes 要求节点和 kube-apiserver 所在 master 节点网络互通，即节点的组件能访问 master 节点的组件，master 节点的组件也能访问节点的组件。咱们的第二问题是中心和网点间网络不通，直接部署原生的Kubernetes 显然是行不通的，那么咱们该如何解决边缘服务的管理呢？

3.弱网

弱网的话，即便咱们中心和边缘创建了链接，可是中心和边缘也会时不时的断网，断网的状况下如何保证边缘容器正常服务呢？还有重启边缘节点，边缘容器可以正常服务的问题。

4.地域相隔甚远，边缘节点的部署怎么搞？

地域相隔甚远就得考虑部署的问题，咱们不可能每部署一个网点都跑到用户那里去。出了什么问题，还得用户给开个后门，远程链接用户的节点去解决。

...

拿真实的场景思考下来，面临的问题还真是很多，但愿这些问题能够引发你们的深思，边缘解决方案没有统一的标准，只能要能平滑的解决客户的问题，就是完美的方案。

下来咱们一块儿看看 SuperEdge 的解决方案。

4、SuperEdge的功能

在介绍功能以前咱们先把 SuperEdge 的架构图贴出来，一边看架构图，一边挖掘 SuperEdge 的实现：

1.Network tunneling（tunnel隧道）

看了这个功能的介绍和 SuperEdge 的架构图，其实 Network tunneling 就是图中的 tunnel 隧道。在边缘节点部署一个 tunnel-edge, 在中心部署一个 tunnel-cloud。由 tunnel-edge 主动向 tunnel-cloud 发起请求创建长链接，这样即便边缘节点没有公网IP也能创建边端和云端的链接，让中心和边缘节点互通，本质就是 tunnel 隧道技术。

2.Edge autonomy（边缘自治）

这个主要是解决弱网和重启的。即便有了 Network tunneling，边缘节点和云端的网络不稳定是改变不了的事实，动不动断连仍是存在的。边缘自治功能知足两个边缘场景：一是中心和边缘之间断网，边缘节点的服务是不受影响的；二是边缘节点重启，重启以后，边缘节点上的服务仍然可以恢复。

这个功能是怎么实现的？

看看 lite-apiserver 的介绍就明白了。这个组件把边缘节点请求中心的管理数据所有都缓存下来了，利用落盘数据在工做，维持了边缘服务，即便重启也能正常提供服务。不过有个问题，边缘自治的应用也会产生数据，产生的数据如何处理？会不会产生脏数据，影响边缘服务呢？这个问题留给你们思考。

3.Distributed node health monitoring（分布式健康检查）

不过我更疑惑了，为何中心和边缘节点断网了，边缘节点的服务没有被驱逐呢？按照Kubernetes的逻辑，边缘节点NotReady，节点上的服务应该会被驱逐到其余Ready的节点上才对，为何没有产生驱逐呢？难道SuperEdge关闭了边缘节点的驱逐。经我确认SuperEdge并无关闭驱逐，并且在官网开源文档中强调只有在确认边缘节点异常的状况下才会产生Pod驱逐。

那么 SuperEdge 是如何确认边缘节点异常的呢？我后面在 edge-health 的组件介绍中找到了答案。

edge-health 运行在每一个边缘节点上，探测某个区域内边缘节点的健康性。原理大概是这样的，在某个区域内，边缘节点之间是能互相访问的，而后运行在每一个边缘节点的 edge-health 周期性的互相访问，确认彼此的健康性，也包括本身。按照你们的探测结果，统计出每一个边缘节点的健康性，要是有XX%节点认为这个节点异常(XX%是healthcheckscoreline 参数配置的，默认100%) ，那么就把这个结果反馈给中心组件 edge-health admission。

edge-health admission 部署在中心，结合边缘节点的状态和 edge-health 的投票结果，决定是否驱逐边缘服务到其余边缘节点。经过运用 edge-health，设置好 healthcheckscoreline，只要是边缘节点不是真正的宕机，服务就不会驱逐。一来提升了边缘服务的可用性，二来很好的扩展了 Kubernetes 驱逐在边缘的运用。

可我仍有个疑问，要是有个边缘节点确实宕机了，服务也被驱逐到了其余边缘节点，可是后面这个边缘节点的健康性恢复了，边缘节点上的服务怎么处理？

4.Built-in edge orchestration capability

这个功能，我的认为是最具实用性的。也是就由架构图的application-grid controller和application-grid wrapper 两个组件联合提供的ServerGroup能力。

ServiceGroup有什么用呢？拿那个连锁超市有10个营业网点的例子来讲，大概提供了两个功能：

多个营业网点能够同时部署一套特价广告推销解决方案；

这个有什么稀奇的呢？注意是同时，就是说您有一个deployment，给中心集群提交了一次，就能够同时给10个营业网点，每一个网点都部署一套这样的deployment解决方案。这样就能作到，管理10个营业网点的特价广告推销程序，像管理一个网点的特价广告推销程序同样轻松。而且新加入的网点，会自动部署特价广告推销解决方案，彻底不用管版本、命名的问题了。

多个站点部署的服务有差异，即灰度能力

这个属于 ServiceGroup 的扩展功能，同一套服务在不一样地域可能有字段的差别，或者镜像版本不同，能够利用DeploymentGrid 的 templatePool 定义不一样地域或者站点的模板，利用 Kubernestes Patch 功能，Patch 出基于基础版本不一样运行版本。这样在某个服务上线前，进行一个地域的灰度，或者定义一套服务在各个站点运行的服务不一样，利用 DeploymentGrid 的 templatePool 就能够简单的进行管理。

同一套解决方案不跨网点访问；

什么意思？即便各个网点网络互通，每一个网点都部署了特价广告推销程序，A网点的程序也不会去访问B网点的特价广告推销服务，只会访问本网点的服务，实现了流量闭环。

这么作的好处我的认为有两个：

实现了网点访问流量闭环，本网点的服务只能访问本网点；
促进了边缘自治，要是一个网点链接不上中心，这个网点彻底能够利用本身的服务实现自治，并不会访问其余网点。

这个功能确实在边缘的场景中很实用，能够把 application-grid controller和application-grid wrapper 两个组件独立的部署在 Kubernetes 集群中，解决多个网点多套解决方案的管理问题，你们也能够按 ServerGroup的文档本身体验体验。

今天说到这里，基本把 SuperEdge 的基本功能分析的差很少了，后面有机会在深刻剖析SuperEdge内部的原理！

5. 合做和开源

TKE Edge 边缘容器管理服务的边缘计算能力核心组件已经开源到 SuperEdge项目，欢迎共建边缘计算，参与 SuperEdge 开源项目的建设，让您开发的边缘能力惠及更多人。如下是SuperEdge开源项目的微信群，环境参与交流讨论。

SuperEdge版本：

TKE Edge相关文章：

落地案例相关资料：

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