王冬,腾讯云高级研发工程师,专注于Kubernetes、容器等云原生领域,SuperEdge 核心开发人员,现负责腾讯云边缘容器TKE Edge私有化相关工作。
2021年9月27号,在 VMware 联合了 Intel、 PingCAP 等多家合作公司举办的2021智能云边开源峰会边缘计算专场上,来自腾讯云的高级工程师王冬,发表《 SuperEdge 的新特性和未来之路》的分享。
SuperEdge[1] 是2020年由腾讯联合 Intel、VMware、虎牙直播、寒武纪、首都在线和美团等多家公司共同发起的边缘计算分布式容器管理系统,旨在将 Kubernetes 集中式资源管理能力无缝拓展到边缘计算和分布式资源管理场景,统管边缘设备和应用,为众多的 IoT 设备赋能。
以下是分享全文。
SuperEdge 核心的边缘能力有4个:
这个能力主要由浅红色的lite-apiserver
提供。为什么需要能力?有两个原因:
除此之外 lite-apiserver 还提供了一些其他能力。比如:
这个能力主要由浅绿色的tunnel-cloud
和tunnel-edge
两个组件提供。这两个组件是腾讯云边缘计算团队完全自研的云边隧道,目前可以代理 TCP、HTTP、HTTPS、SSH 四种协议请求。为什么需要云边隧道能力?
不过 SuperEdge 这个云边隧道并不专属 SuperEdge,任何需要隧道的地方都可以拿去按自己的场景进行配置和直接使用。
这个能力主要由浅紫色的application-grid-conterlloer
和application-grid-wrapper
两个组件提供。为什么需要这两个组件?
application-grid-conterlloer
就是为解决这问题而诞生的。用户的一份应用在云端一次提交便能同时部署到边缘多个站点,并且允许站点灰度能力,允许站点配置上有差异。这个就是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 一直在简单性和易用性上深耕。
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 集群
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-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
模块。远程批量添加边缘节点分为两种情况:
penetrator
的关键是无法直接SSH到的边缘节点怎么实现批量添?
腾讯云边缘团队最近刚开源了团队的第二个开源项目 Clusternet[2],这并不是一个集群网络相关的开源项目,而是为了实现像访问Internet网络一样,访问用户各处K8s集群
的目标而构建的一个分布式多集群管理开源项目。为什么需要这个项目?
上图是 Clusternet 的架构,目前由两个组件clusternet-agent
和 clusternet-hub
组成。clusternet-agent
负责把 K8s 集群注册到父集群,clusternet-hub
负责处理注册、聚合各个子 K8s 集群 Kube-apiserver,以及把应用部署到多个 K8s 集群。
下图表述的是目前边缘 K8s 集群云边 Service 互访和边边 Service 互访的现状。
云边 Service 互访大多都是以 NodePort 方式对外暴露,很少有边缘项目实现像原生 K8s 集群一样,在一个集群内Service无缝进行互访
。
边边 Service 互访困难更高,要是边边之间是单向网络还能通过打隧道互访,要是物理网络完全不通只能通过云端中转。就算实现了云边 Service 互访和边边 Service 互访,又如何避免性能损失,以及突破云边和边边物理网络的不稳定性?
这里的解决方案可关注 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 和数字化!
【演讲原视频】
关注【腾讯云原生】公众号,后台回复关键词【云边开源峰会】可获取演讲PPT原稿。
往期精选推荐
SuperEdge 相关文章:
落地案例相关资料:
[1]
SuperEdge: 【https://link.segmentfault.com/?url=https%3A%2F%2Fgithub.com%2Fsuperedge%2Fsuperedge】
[2]
Clusternet: 【https://github.com/clusternet/clusternet】
互动赢好礼
精读文章,回答问题赢好礼
Q1: 如何保证云边 Service 互访不受弱网的影响?
Q2:如何突破边边网络的限制,实现边边 Service 互访?
9月30日上午11点,由作者选出回答最佳的3位读者,送定制T恤一件。
点个“在看”每天学习最新技术