共计 5863 个字符，预计需要花费 15 分钟才能阅读完成。
一、SuperEdge 的定义
援用下 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.
翻译过去的意思是：
SuperEdge 是开源的边缘容器解决方案，可能在单 Kubernetes 集群中治理跨地区的资源和容器利用。
咱们通过关键词来简略解释下这句话：
- 开源
这个计划尽管是由腾讯云容器团队开源的边缘容器解决方案，但这是一个齐全第三方中立的开源我的项目。官宣当日别离由 Intel、VMware、美团、寒武纪、首都在线、虎牙、腾讯独特官宣开源，并不禁腾讯一家说了算，在边缘有想法的同学和企业也欢送参加，共建边缘，独特推动边缘计算在理论场景的落地和倒退。
- 边缘容器解决方案
这句话不必过多的解释，次要做容器的编排和调度治理。然而目前做容器的调度编排最火的计划是 Kubernetes，为什么不拿 Kubernetes 间接做边缘容器的编排和调度治理呢？这个前面再解释。
- 单 Kubernetes 集群
还是用 Kubernetes 做容器编排调度，深刻理解后，发现 SuperEdge 团队并没有删减 Kubernetes 任意一行代码，也就是说齐全 Kubernetes 原生，具备 Kubernetes 对应版本的全副个性。
- 单 Kubernetes 集群中治理跨地区的资源和容器利用
重点词落在 单和 跨地区。为什么要在单 Kubernetes 集群中治理跨地区的资源和容器利用呢？场景、场景、还是场景决定的。
简略一个例子，有个连锁超市，10 个营业网点，每个网点都有一个当日的特价广告采购程序。各个营业网点之间，以及营业网点和核心管控面之间，网络齐全不通，齐全独立，造成地区隔离。每个网点的广告程序齐全一样，推送的内容也齐全一样，指标是可能在单 Kubernetes 集群中，治理 10 个营业网点，像治理一个网点一样轻松。
二、可能存在的问题
看了 SuperEdge 官网的个性，我也没齐全懂。什么是 Network tunneling? 为什么要 Built-in edge orchestration capability? 介绍的个性到底能够解决什么问题，我也存疑？
还是拿 有个连锁超市，10 个营业网点，核心和网点之间，网点和网点之间网络不通，但要部署运维同一个应用程序 来设计下解决方案，看看这其中须要解决的问题，兴许对 SuperEdge 的个性和设计初衷就能就更好的把握了。
咱们看下这个例子在理论的场景中，咱们将要面对的问题：
1.10 个营业网点一样的程序
尽管例子中只有 10 个营业网点，但理论中可能成千盈百。咱们也要思考当前的扩展性，成千盈百网点要让同一个程序全副都同步起来做一件事，难度天然不小。要是治理成千盈百的营业网点，就像治理一个网点一样轻松容易，那的确轻松不少。
2. 核心和网点之间，网点和网点之间网络不通
事实中实在存在这样的场景，毕竟专线耗时耗力老本高。实在的场景比较复杂，各个网点可能是一个小机房，也可能是一个小盒子，没有公网 IP。有的网点几百个盒子，只有一个盒子能够拜访外网，有的甚至所有的盒子都无法访问外网，部署的时候就相当的艰难。
3. 弱网、地区相隔甚远
边缘的场景不比核心，边缘的很多盒子，比方摄像头，各个区域都可能是走公网拜访或者 WIFI 连贯，时不时断网，短则几分钟，或者几个小时，长则几天都连不上网，都属于失常景象。更有甚者，断电重启一下……要在这种场景下保障边缘业务可能失常提供服务，尽可能进步服务的可用性，就是挑战了。
4. 如何晓得边缘节点的衰弱性？
边缘节点不衰弱了，就要把异样节点的服务调度到可用的节点下来，尽可能的保障服务的衰弱性。核心和边缘网络不通，各个网点的网络又不通的状况下，要怎么晓得网点节点的衰弱性？
5. 资源无限
嵌入式边缘节点往往资源无限，1G1C 很常见，如何保障边缘资源无限的状况下，把边缘服务运行起来？
6. 资源混部
核心云 Kubernetes 既想管理中心云利用，又想治理边缘利用，怎么搞呢？
…
不开展说了，这外面要思考的细节问题还是比拟多的，不能等在理论场景中碰到了才去解决，肯定要在方案设计的时候，就尽可能的解决掉将要面对的问题。这样咱们能力把无限的工夫投入到具体的业务中，而不是和底层架构较劲。
三、思考本人的解决方案
如果咱们遇到下面的问题，如何解决呢？
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 的解决方案。
四、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 开源我的项目的微信群，环境参加交换探讨。
<img src=”https://main.qcloudimg.com/raw/4a030d87d4bf0ed268edd96f8f38f1af.png” style=”zoom:50%;” />
SuperEdge 版本：
- SuperEdge-V0.4.0
- SuperEdge-V0.3.0
- SuperEdge-V0.2.0
- 多加公司联结开源 SuperEdge
TKE Edge 相干文章：
- 【TKE 边缘容器系列】用 edgeadm 一键装置边缘 K8s 集群和原生 K8s 集群
- 【TKE 边缘容器系列】从 0 到 N 理解 SuperEdge，这些干货肯定要看！【18 篇干货合集】
- 【TKE 边缘容器系列】突破内网壁垒，从云端一次增加成千盈百的边缘节点
- 【TKE 边缘容器系列】SuperEdge 云边隧道新个性：从云端 SSH 运维边缘节点
- 【TKE 边缘容器系列】一文读懂 SuperEdge 边缘容器架构与原理
- 【TKE 边缘容器系列】一文读懂 SuperEdge 分布式健康检查边端
- 【TKE 边缘容器系列】一文读懂 SuperEdge 拓扑算法
- 【TKE 边缘容器系列】一文读懂 SuperEdge 云边隧道
落地案例相干材料：
- 腾讯 WeMake 工业互联网平台的边缘容器化实际：打造更高效的工业互联网
- 完爆！用边缘容器，竟能秒级实现团队七八人一周的工作量
- 基于边缘容器技术的工业互联网平台建设
-
应用 TKE Edge 部署 EdgeX Foundry
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
