作者
背景
SuperEdge 的四大特性
-
SuperEdge 来源 SuperEdge 是腾讯云边缘容器管理系统 TKE Edge 产品族中的一个开源产品，其对应的商业产品是 TKE Edge 公有云服务和 TKE Edge 私有化服务。其公有云服务在2018年就在内部进行孵化，2019年正式公测并对外提供服务，目前对外完全免费；其私有化产品目前由灵雀云对外提供整体的交付和维保。
-
SuperEdge 和 TKE Edge 的关系 SuperEdge 开源的是 TKE Edge 的边缘能力组件，并不包含其商业产品集群创建的部分。其边缘能力组件是完全开源的，开源产品和商业产品的边缘能力是完全一致的，甚至其开源产品 SuperEdge 的功能会比其商业产品更新的还要早。因为腾讯目前内外只维护了一个仓库，就是 Github 的 SuperEdge。
L3级边缘自治能力
这个能力主要由浅红色的
lite-apiserver提供。为什么需要能力？有两个原因：
-
第一是 因为云边一般是弱网，也可能断网，在弱网和断网情况下要保证边缘服务稳定。lite-apiserver 在云边网络正常的情况下直接从云端 Kube-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，但是云端却无法直接访问边缘节点，所以需要云边反向隧道进行打通。
-
第二是为云边数据传输做准备，边缘部分数据是要回传云端进行分析和处理的，高效、安全的加密隧道是必要的条件。
海量站点管理能力
application-grid-conterlloer
和
application-grid-wrapper
两个组件提供。
为什么需要这两个组件？-
第一是 边缘一般有很多类似的站点，需要部署同一套应用，我们不可能一一去部署，直接循环部署有的站点还会有差异， application-grid-conterlloer就是为解决这问题而诞生的。用户的一份应用在云端一次提交便能同时部署到边缘多个站点，并且允许站点灰度能力，允许站点配置上有差异。 -
第二是 防止边缘应用跨站点访问。因为各个站点基本提供一样的边缘服务，服务就可能会跨站点进行访问，跨站点访问会引起两个问题。A 站点可能会把 B 站点数据写紊乱，跨站点访问的延时不可控。
application-grid-wrapper
解决的问题，他能把一个站点的流量锁定在一个站点之内，智能的配置后端的
endponit
，把服务锁定在用户想要的范围内。分布式健康检查
edge-health-admission
和
edge-health
两个组件提供。
为什么需要这两个组件？
-
第一是 需要在云边断网的时候尽可能的反馈边缘节点的健康性。
edge-health
就起到了这个作用。
-
第二是 维护边缘服务的稳定性，避免被反复重建。
NotReady
，但是边缘服务是正常的，并不受云边弱网的影响。可是云上的 Kubernetes 可不这么认为，一但节点不
NotReady
就可以引起边缘服务驱逐，将边缘服务反复迁移和重建，引起边缘服务的不稳定。而
edge-health-admission
就是为解决这个问题，他把
edge-health
反馈的边缘节点真实的健康状况反馈给 Kube-apiserver，防止边缘服务被误驱逐。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 所有的边缘能力。
edgeadm addon SuperEdge
会把他配置成标准的
Kubeadm Kubernetes
集群，如果是 Kubeadm Kubernetes 更就可以直接跳过这步。之后准备
Addon SuperEdge
和
Join edge node
的前提条件。这里比较有挑战的点就是准备
Join edge node
的条件，实现任何 K8s 集群都能一键 join 进去任意位置的边缘节点。更详细原理可查看：
Addon SuperEdge 让原生 K8s 集群可管理边缘应用和节点新特性二：边缘托管集群 + 边缘独立集群 + 边缘联级集群
clusternet
，实现在中心统一管控边缘托管集群，纳管边缘独立集群，甚至是边缘联级集群。新特性三：Tunnel 远程登录内网节点和 HPA
长链接数量 = 隧道云端实例数 * 边缘节点个数
随着一个边缘集群的边缘节点数量不断打破 SuperEdge 的上限，tunnel-cloud 不能再静态的去维护固定数量的实例，而要 动态的去扩容去 tunnel-cloud 实例，以便接入更多的长连接，纳管更多的边缘节点，这就是 tunnel-cloud 自动 HPA 需求来源。
新特性四：远程批量添加边缘节点
penetrator
模块。远程批量添加边缘节点分为两种情况：-
云端能 SSH 到的边缘节点 云端能 SSH 到边缘节点这个操作比较常规，通过下发一个 SSH 的 Job, 批量 SSH 远程执行命令添加边缘节点。
penetrator的关键是无法直接SSH到的边缘节点怎么实现批量添？ -
云端不能 SSH 到的边缘节点 不能直接 SSH 到的边缘节点，如下图，可以通过一个代理或者其他办法把同一子网的一个节点加入到边缘 K8s 集群。以这个边缘节点为跳板，然后把任务 Job 下发到这个跳板节点，然后就可以批量的执行添加和这个跳板节点同一内网的边缘节点。这样就实现了远程批量添加不能 SSH 到的边缘内网节点。
SuperEdge 未来的云边端
SuperEdge 未来的云上
像访问Internet网络一样，访问用户各处K8s集群
的目标而构建的一个分布式多集群管理开源项目。
为什么需要这个项目？-
第一是为了满足海量边缘节点的管理 一个 K8s 集群管理的边缘节点是有限的，原生的 K8s 集群目前社区给出的节点上限是5000。K8s 集群管理的节点越多，维护成本和技术难度都将指数级上升。把数量庞大的节点放在一个集群里面，本身面临的风险就是比较高的，一旦中心有问题，节点的应用可能都会受到影响。要管理上万的边缘节点，单集群并不优雅，反而是小而美的多集群更安全更稳定。clusternet 目前能够纳管各式各样的 K8s 集群，包括公有云的、私有化的和边缘K8s集群。可以实现在中心一个控制面统一管理和访问和各个 K8s 集群，并且可以实现从纳管的集群互相访问。 -
第二是为了满足站点和应用容灾的需要 纳管各种 K8s 集群只是实现分布式多集群管理的第一步，集群容灾、应用容灾才是目的。边缘站点断网断电的可能性要比中心更高也更频繁。站点宕机之后相应站点服务需要在临近站点或者备份站点上继续提供服务，集群迁移、同城双活是迫切的需求。边缘的应用也不会只部署在一个站点之内，一个站点崩溃还需要在其他站点上继续提供服务。
clusternet-agent
和
clusternet-hub
组成。
clusternet-agent
负责把 K8s 集群注册到父集群，
clusternet-hub
负责处理注册、聚合各个子 K8s 集群 Kube-apiserver，以及把应用部署到多个 K8s 集群。SuperEdge 未来的边上
在一个集群内Service无缝进行互访
。
SuperEdge 未来的端上
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 都会以 Addon 的方式让用户去自由选择，绝不强绑定任何边缘设备平台。
20:36
往期精选推荐
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
关于我们
更多关于云原生的案例和知识，可关注同名【腾讯云原生】公众号~
福利：公众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69984638/viewspace-2794257/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
