Superedge的新特性和未来之路

阅读原文时间：2021年09月29日阅读：1

王冬，腾讯云高级研发工程师，专注于Kubernetes、容器等云原生领域，SuperEdge 核心开发人员，现负责腾讯云边缘容器TKE Edge私有化相关工作。

2021年9月27号，，在VMware 联合了 Intel、 PingCAP 等多家合作公司举办的2021智能云边开源峰会边缘计算专场上，来自腾讯云的高级工程师王冬，发表《 SuperEdge 的新特性和未来之路》的分享。

SuperEdge 是2020年由腾讯联合 Intel、VMware、虎牙直播、寒武纪、首都在线和美团等多家公司共同发起的边缘计算分布式容器管理系统，旨在将 Kubernetes 集中式资源管理能力无缝拓展到边缘计算和分布式资源管理场景，统管边缘设备和应用，为众多的 IoT 设备赋能。

以下是分享全文。

SuperEdge 来源

SuperEdge 是腾讯云边缘容器管理系统 TKE Edge 产品族中的一个开源产品，其对应的商业产品是 TKE Edge 公有云服务和 TKE Edge 私有化服务。其公有云服务在2018年就在内部进行孵化，2019年正式公测并对外提供服务，目前对外完全免费；其私有化产品目前由灵雀云对外提供整体的交付和维保。

SuperEdge 和 TKE Edge 的关系

SuperEdge 开源的是 TKE Edge 的边缘能力组件，并不包含其商业产品集群创建的部分。其边缘能力组件是完全开源的，开源产品和商业产品的边缘能力是完全一致的，甚至其开源产品 SuperEdge 的功能会比其商业产品更新的还要早。因为腾讯目前内外只维护了一个仓库，就是 Github 的 SuperEdge。

SuperEdge 核心的边缘能力有4个:

L3级边缘自治能力

这个能力主要由浅红色的lite-apiserver提供。为什么需要能力？有两个原因：

第一是因为云边一般是弱网，也可能断网，在弱网和断网情况下要保证边缘服务稳定。lite-apiserver 在云边网络正常的情况下直接从云端 Kube-apiserver 请求数据，但是云端请求不到的时候就会从本地缓存中取出相关组件管控缓存返回给请求端，保证边缘服务的稳定。
第二是边缘节点或者边缘站点可能会断电重启，特别是在云边断网的时候重启边缘节点，边缘节点上的业务容器会无法拉起。有了 lite-apiserver 的本地缓存就能避免这个问题，会从本地存储中把业务容器加载起来。

除此之外 lite-apiserver 还提供了一些其他能力。比如：

以 InCluster 方式访问 kube-apiserver
支持所有类型资源的缓存，包括 CRD
边缘节点安全：lite-apiserver 用代理组件的权限去请求 kube-apiserver，而不是超级权限
支持多种缓存存储：Light Edge 可用本地文件存储，Heavy Edge 可以用 SQLite 等 KV 存储；

云边协同能力

这个能力主要由浅绿色的tunnel-cloud和tunnel-edge两个组件提供。这两个组件是腾讯云边缘计算团队完全自研的云边隧道，目前可以代理 TCP、HTTP、HTTPS、SSH 四种协议请求。为什么需要云边隧道能力？

第一是边缘节点一般是没有公网 IP 的，边缘节点可以主动访问云端的 Kube-apiserver，但是云端却无法直接访问边缘节点，所以需要云边反向隧道进行打通。
第二是为云边数据传输做准备，边缘部分数据是要回传云端进行分析和处理的，高效、安全的加密隧道是必要的条件。

不过 SuperEdge 这个云边隧道并不专属 SuperEdge，任何需要隧道的地方都可以拿去按自己的场景进行配置和直接使用。

海量站点管理能力

这个能力主要由浅紫色的application-grid-conterlloer和application-grid-wrapper两个组件提供。为什么需要这两个组件？

第一是边缘一般有很多类似的站点，需要部署同一套应用，我们不可能一一去部署，直接循环部署有的站点还会有差异，

application-grid-conterlloer就是为解决这问题而诞生的。用户的一份应用在云端一次提交便能同时部署到边缘多个站点，并且允许站点灰度能力，允许站点配置上有差异。
第二是防止边缘应用跨站点访问。因为各个站点基本提供一样的边缘服务，服务就可能会跨站点进行访问，跨站点访问会引起两个问题。A 站点可能会把 B 站点数据写紊乱，跨站点访问的延时不可控。

这个就是application-grid-wrapper解决的问题，他能把一个站点的流量锁定在一个站点之内，智能的配置后端的endponit，把服务锁定在用户想要的范围内。

上图便是这两个组件的一个典型使用示例图。站点 NodeUnit-1 和站点 NodeUnit-2 可以同时部署同一套服务 ServiceGroup-1，站点 NodeUnit-3 需要部署服务 ServiceGroup-2，并且各站点服务访问只在各站点内进行。站点的划分也是逻辑的，一个小机房可以划为一个或者多个站点，小机房内的节点也可以同属于多个站点，不同站点可以部署不同服务，来充分利用小机房内的资源。

分布式健康检查

这个能力主要由浅黄色的edge-health-admission和edge-health两个组件提供。为什么需要这两个组件？

第一是需要在云边断网的时候尽可能的反馈边缘节点的健康性。比如某个边缘的小机房的某个可用区云边断网了，云上暂时无法知道只是云边断网了，还是这个可用区宕机了。这个健康状况云上是没有办法知道，但是这个小机房的其他可用区可以通过定期 Check 去反馈彼此的健康状况。edge-health就起到了这个作用。
第二是维护边缘服务的稳定性，避免被反复重建。在把原生 Kubernetes 推向边缘后，原生 Kubernetes 的驱逐能力是不完全符合边缘的。在边缘弱网或者断网，节点的状态可能会出现反复的NotReady，但是边缘服务是正常的，并不受云边弱网的影响。可是云上的 Kubernetes 可不这么认为，一但节点不NotReady就可以引起边缘服务驱逐，将边缘服务反复迁移和重建，引起边缘服务的不稳定。而edge-health-admission就是为解决这个问题，他把edge-health反馈的边缘节点真实的健康状况反馈给 Kube-apiserver，防止边缘服务被误驱逐。

从去年12月开源到现在，SuperEdge 已经发了5个版本，带来了许多新特性，这里是4个比较典型的，其他的可关注 SuperEdge 社区。

新特性一：易用性一键创建与一键集成

从开源到现在，SuperEdge 一直在简单性和易用性上深耕。

一键创建边缘 K8s 集群

在用户没有 K8s 集群的时候，可以通过edgeadm init一键创建边缘 K8s 集群：
```
## 一键创建边缘集群
./edgeadm init --apiserver-cert-extra-sans=…

## 一键Join边缘节点
./edgeadm join  kube-api-addr   --token xxxx…
```
只需要一个 Master 节点和一个 Node 节点，2C2G 的资源便可以轻松玩转边缘，纳管用户洒落在任何地方的边缘节点和边缘设备。

实现上是改造了Kubeadm，在Kubeadm init之前加了Init node和Install container runtime, 之后 Addon CNI 网络插件和上面提到了边缘能力组件。

使用方式上和Kubeadm完全一样，只比Kubeadm多了2个参数。具体可查看：用 edgeadm 一键安装边缘 K8s 集群和原生 K8s 集群
一键集成边缘能力

在用户已经有了原生的 K8s 集群，可以通过Addon SuperEdge一键集成边缘能力。
```
## 一键Addon SuperEdge集成边缘能力
./edgeadm addon edge-apps --master-addr …

## 一键Join任意位置的边缘节点
./edgeadm  join kube-api-addr  --token=…
```
集成边缘能力之后原生的K8s集群将具备既能管理中心节点和中心应用，也能管理边缘节点和边缘应用的能力，实现中心和边缘混管、混部和互弹。能 Join 任意位置的边缘节点，不要求 SSH 到边缘节点，只要这个边缘节点能访问到中心的 Kube-apiserver 就能被 Join。除此之外，当然也具备 SuperEdge 所有的边缘能力。

实现的原理如下图：

用户通过任何方式搭建的原生K8s集群，edgeadm addon SuperEdge会把他配置成标准的Kubeadm Kubernetes集群，如果是 Kubeadm Kubernetes 更就可以直接跳过这步。之后准备Addon SuperEdge和Join edge node的前提条件。这里比较有挑战的点就是准备Join edge node的条件，实现任何 K8s 集群都能一键 join 进去任意位置的边缘节点。更详细原理可查看：Addon SuperEdge 让原生 K8s 集群可管理边缘应用和节点

新特性二：边缘托管集群 + 边缘独立集群 + 边缘联级集群

下面这个图是 SuperEdge 向边缘分布式多集群迈进的第一步。

SuperEdge 目前可以通过腾讯云边缘计算团队新开源的分布式多集群项目clusternet，实现在中心统一管控边缘托管集群，纳管边缘独立集群，甚至是边缘联级集群。

其中纳管的边缘独立集群不限于 SuperEdge 类型的 K8s 集群，还包括轻量级的 K3s 集群、MicroK8s 集群……及其他原生的 K8s 集群。

新特性三：Tunnel 远程登录内网节点和 HPA

tunnel-cloud 和 tunnel-edge 是云边隧道的两端，SuperEdge 每个 tunnel-cloud 实例 Pod 上并不是保留了所有边缘节点的的连接，而是每个 tunnel-cloud 只是承担了一部分边缘节点的 tunnel-edge 隧道连接，也就是每个云边隧道只有一条长连接。而其他大部分云边隧道项目都是云端每个实例需要保持和边缘节点的所有长链接：

长链接数量 = 隧道云端实例数 * 边缘节点个数

这样做的目的主要是支持 tunnel-cloud 自动扩缩容

随着一个边缘集群的边缘节点数量不断打破 SuperEdge 的上限，tunnel-cloud 不能再静态的去维护固定数量的实例，而要动态的去扩容去 tunnel-cloud 实例，以便接入更多的长连接，纳管更多的边缘节点，这就是 tunnel-cloud 自动 HPA 需求来源。

最后这个小特性是借助 tunnel 隧道，SuperEdge 支持了远程安全的SSH到无公网IP的边缘节点，为用户远程操作无公网 IP 的边缘节点带来了极大的便利性。

新特性四：远程批量添加边缘节点

新特性的最后一个是远程批量添加边缘节点。这是 SuperEdge 落地生产批量化的一个需求，相关代码已经开源到 SuperEdge 的penetrator模块。远程批量添加边缘节点分为两种情况：

云端能 SSH 到的边缘节点

云端能 SSH 到边缘节点这个操作比较常规，通过下发一个 SSH 的 Job, 批量 SSH 远程执行命令添加边缘节点。

penetrator的关键是无法直接SSH到的边缘节点怎么实现批量添？
云端不能 SSH 到的边缘节点

不能直接 SSH 到的边缘节点，如下图，可以通过一个代理或者其他办法把同一子网的一个节点加入到边缘 K8s 集群。以这个边缘节点为跳板，然后把任务 Job 下发到这个跳板节点，然后就可以批量的执行添加和这个跳板节点同一内网的边缘节点。这样就实现了远程批量添加不能 SSH 到的边缘内网节点。

SuperEdge 未来的云上

腾讯云边缘团队最近刚开源了团队的第二个开源项目 Clusternet，这并不是一个集群网络相关的开源项目，而是为了实现像访问Internet网络一样，访问用户各处K8s集群的目标而构建的一个分布式多集群管理开源项目。为什么需要这个项目？

第一是为了满足海量边缘节点的管理

一个 K8s 集群管理的边缘节点是有限的，原生的 K8s 集群目前社区给出的节点上限是5000。K8s 集群管理的节点越多，维护成本和技术难度都将指数级上升。把数量庞大的节点放在一个集群里面，本身面临的风险就是比较高的，一旦中心有问题，节点的应用可能都会受到影响。

要管理上万的边缘节点，单集群并不优雅，反而是小而美的多集群更安全更稳定。clusternet 目前能够纳管各式各样的 K8s 集群，包括公有云的、私有化的和边缘K8s集群。可以实现在中心一个控制面统一管理和访问和各个 K8s 集群，并且可以实现从纳管的集群互相访问。
第二是为了满足站点和应用容灾的需要

纳管各种 K8s 集群只是实现分布式多集群管理的第一步，集群容灾、应用容灾才是目的。边缘站点断网断电的可能性要比中心更高也更频繁。站点宕机之后相应站点服务需要在临近站点或者备份站点上继续提供服务，集群迁移、同城双活是迫切的需求。边缘的应用也不会只部署在一个站点之内，一个站点崩溃还需要在其他站点上继续提供服务。

上图是 Clusternet 的架构，目前由两个组件clusternet-agent 和 clusternet-hub组成。clusternet-agent负责把 K8s 集群注册到父集群，clusternet-hub负责处理注册、聚合各个子 K8s 集群 Kube-apiserver，以及把应用部署到多个 K8s 集群。

SuperEdge 未来的边上

下图表述的是目前边缘 K8s 集群云边 Service 互访和边边 Service 互访的现状。

云边 Service 互访大多都是以 NodePort 方式对外暴露，很少有边缘项目实现像原生 K8s 集群一样，在一个集群内Service无缝进行互访。

边边 Service 互访困难更高，要是边边之间是单向网络还能通过打隧道互访，要是物理网络完全不通只能通过云端中转。就算实现了云边 Service 互访和边边 Service 互访，又如何避免性能损失，以及突破云边和边边物理网络的不稳定性？

这里的解决方案可关注 SuperEdge 社区，后续会推出相关的解决方案。

SuperEdge 未来的端上

端上 SuperEdge 已经实现 Addon 原生的 Edgex Foundry, 可以通过如下命令有选择的部署 Edgex Foundry 的各层组件：

attlee➜  ✗ ./edgeadm addon edgex -h
Addon edgex to Kubernetes cluster

Usage:
edgeadm addon edgex [flags]

Flags:
--core       Addon the edgex core-services to cluster.
--app        Addon the edgex application-services to cluster.
--device     Addon the edgex device-services to cluster.
--ui         Addon the edgex ui  web to your cluster.

详细的操作可查看在 SuperEdge 上用 EdgeX Foundry 接入 IoT 设备。

这只是 SuperEdge 实现边缘设备管理的第一步，EdgeX Foundry 也只是众多设备管理平台中的一种，后续 SuperEdge 还会和更多的缘设备平台进行抽象和集成，推出多平台边缘设备平台无缝衔接的解决方案。但无论是那种方案，SuperEdge 都会以 Addon 的方式让用户去自由选择，绝不强绑定任何边缘设备平台。

最后这张图是目前 SuperEdge 和 EdgeX Foundry 在端边的部署方式，以及设备的接入方式。一个站点只用部署 SuperEdge 和 EdgeX Foundry 的一套边端服务即可管理相应站点的边缘设备。