作者
王冬，腾讯云高级研发工程师，专一于 Kubernetes、容器等云原生畛域，SuperEdge 外围开发人员，现负责腾讯云边缘容器 TKE Edge 私有化相干工作。
背景
2021 年 9 月 27 号，，在 VMware 联结了 Intel、PingCAP 等多家单干公司举办的 2021 智能云边开源峰会边缘计算专场上，来自腾讯云的高级工程师王冬，发表《SuperEdge 的新个性和将来之路》的分享。
SuperEdge 是 2020 年由腾讯联结 Intel、VMware、虎牙直播、寒武纪、首都在线和美团等多家公司独特发动的 边缘计算分布式容器管理系统，旨在将 Kubernetes 集中式资源管理能力无缝拓展到边缘计算和分布式资源管理场景，统管边缘设施和利用，为泛滥的 IoT 设施赋能。
以下是分享全文。
SuperEdge 的四大个性
-
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，避免边缘服务被误驱赶。
SuperEdge 的新个性及原理
从去年 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 将来的云边端
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 的一套边端服务即可治理相应站点的边缘设施。
后续 SuperEdge 也 会面向边缘站点做一系列的反对，包含站点自治、站点 Workload、站点容灾等，在云端对立治理用户的边缘站点。
最初送大家一句话：
边缘计算技术将成为万物互联胜利的要害，将低提早和低成本的服务于 5G 和数字化！
演讲原视频
https://attlee-1251707795.cos…
关注【腾讯云原生】公众号，后盾回复关键词【云边开源峰会】可获取演讲 PPT 原稿。
SuperEdge 相干文章：
- 腾讯云联结多家生态搭档，重磅开源 SuperEdge 边缘容器我的项目
- 【TKE 边缘容器系列】SuperEdge 易学易用【6 个短频教学合集】
- 【TKE 边缘容器系列】从 0 到 N 理解 SuperEdge【18 篇干货合集】
- 【TKE 边缘容器系列】一文读懂 SuperEdge 边缘容器架构与原理
- 【TKE 边缘容器系列】用 edgeadm 一键装置边缘 K8s 集群和原生 K8s 集群
- 【TKE 边缘容器系列】Addon SuperEdge 让原生 K8s 集群可治理边缘利用和节点
- 【TKE 边缘容器系列】在 SuperEdge 上用 EdgeX Foundry 接入 IoT 设施
- 【TKE 边缘容器系列】突破内网壁垒，从云端一次增加成千盈百的边缘节点
- 【TKE 边缘容器系列】SuperEdge 云边隧道新个性：从云端 SSH 运维边缘节点
- 【TKE 边缘容器系列】SuperEdge 高可用云边隧道有哪些特点？
落地案例相干材料：
- 腾讯 WeMake 工业互联网平台的边缘容器化实际：打造更高效的工业互联网
- 完爆！用边缘容器，竟能秒级实现团队七八人一周的工作量
- 基于边缘容器技术的工业互联网平台建设
- 应用 TKE Edge 部署 EdgeX Foundry
对于咱们
更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~
福利：公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！