本文主要介绍谐云在边缘计算-分布式数据中心子场景下，基于开源框架KubeEdge开展云边协同落地过程中的实践经验，为企业带来全面的数字化转型新模式。
边缘计算场景概述
典型的边缘计算场景分为:
1. 物联网近场场景（例如智慧城市，智能家居等），其特点是需要接入海量设备。
2. 分布式数据中心场景（例如游戏服务器，CDN），其特点是计算资源按地理区域离散分布，但无需接入设备。
传统分布式架构数据中心在技术层次上，主要包括两个概念：
🔹单个数据中心的分布式架构
🔹多个数据中心的分布式架构。
前者通常是指基于IaaS或PaaS云计算架构而建设成的数据中心，这种架构已经成为主流数据中心建设模式。后者主要指基于数据复制技术，由多个数据中心统一整合成的联合数据中心，旨在实现业务连续性灾备，多中心运营和管理等。
边缘计算下的分布式数据中心关注点和传统分布式架构数据中心有所不同，原因在于边缘计算领域内的应用对带宽和时延的极度敏感，这要求数据中心必然是近端、小型而大量分布的。在靠近城市、商业区或者通信基站的区域下，将建成更多的小型数据中心以支撑如物联网、AI、云游戏等应用。
案例亮点Highlight
谐云为国内某大型公司已搭建了私有容器云PaaS中心云平台，大部分业务已经上云，但全国各省市级数据中心的业务部署运维仍然是传统的人工模式，服务器资源利用率低下。每个省市级数据中心均可视为一个边缘数据中心，其特点是规模小（10+台），分布广（全国分布），数量多（100+DC），边缘业务运维成本高，这也是很多企业会面临的问题。
那如何解决这些问题呢？谐云在云边协同方面的研究成果为企业带来全面数字化转型新模式。
1. 基于主流K8S架构，复用云原生生态赋能云边协同平台
2. 基于中心容器云，边缘去中心化，权限高度收敛于中心云
3. 支持云边跨公网，无需为DC大量铺设专线
4. 边缘有限自治，云边断连下节点仍能稳定对外服务
5. 边缘数据中心逐节点入云，入云粒度最小至单节点
云边协同平台旨将中心容器云的弹性计算能力下沉至边缘省市级数据中心，以此来提升边缘应用的交付速度，提升资源利用率，提升业务运维效率，进而合理有效的降低边缘的运维成本。
方案选型-边缘计算领域现有框架与Kubernetes联邦
- K3S
- EdgeX
- Openyurt
- KubeEdge
- Kube Federation
上述四种业内开源边缘计算框架+Kube Federation中，设计时偏向于物联网近场场景的框架有K3S、EdgeX和KubeEdge；设计时偏向于分布式数据中心场景的框架有OpenYurt、Kube Federation和KubeEdge。
K3S与EdgeX，前者是K8S的精简版，旨在在边缘受限的计算资源下部署kubernetes集群，但是集群与集群之间的联合并未考虑，属于单数据中心的分布式系统建设方案；后者核心是基于与硬件和操作系统完全无关的参考软件平台建立的互操作框架，加速物联网方案的部署，但并不是基于Kubernetes的扩展，而无法较好地适配Kubernetes上层生态的成熟方案，例如监控、日志、微服务等。这两者均不太符合边缘计算场景下的分布式数据中心。
Federation并不是典型的边缘计算框架，其主要解决多K8S集群的协调运作问题，符合传统分布式计算中心场景。但在设计上未考虑边缘计算场景，对于节点数量规模少于10台的超小型计算中心再部署K8S集群将有较大占比的服务器用于构建K8S控制面节点（为保证高可用一般是3台），这是开销巨大的。且由于Kube Federation V1版本在k8s v1.10后被抛弃，V2版本迭代慢，各种特性未GA，我们最终并未选择基于Kube Federation搭建云边协同平台。
接下来重点介绍基于Kubernetes的两个边缘计算架构KubeEdge与Openyurt。
Kubernetes在边缘
随着Kubernetes成为容器编排领域的事实标准，云原生领域的开源生态快速繁荣发展。谐云认为一个好的边缘计算框架必然是基于Kubernetes的扩展，以复用已有的生态与开源力量，为云边协同平台赋能，是降本增效的最佳解决途径。
边缘计算框架在 Kubernetes 系统里，需要解决下面的问题:
1. 网络断连时，节点异常或重启时，内存数据丢失，业务容器无法恢复；
2. 网络长时间断连，云端控制器对业务容器进行驱逐；
3. 长时间断连后网络恢复时，边缘和云端数据的一致性保障。
4. 网络不稳定下，K8S client ListWatch机制下为保证数据一致性，在每次重连时都需要同步ReList一次，较大规模的边缘节点数量加以较不稳定的网络，将造成巨大的网络开销和API Server的cpu负担，特别是不可靠的远距离跨公网场景。
OpenYurt与KubeEdge所做的种种设计都是为了解决以上四个问题。不同的是OpenYurt设计思路是针对K8S HTTP api请求的代理与缓存，而KubeEdge的设计思路是K8S事件监听与消息化可靠推送-监听边缘资源的增删改查事件并主动推送至边缘节点：
1. 对于问题一，OpenYurt和KubeEdge在边缘均设计了持久化的边缘数据库，节点重启后若网络仍然断连，数据将从边缘数据库中读入。
2. 对于问题二，OpenYurt和KubeEdge均使用Admission Webhook方案，在云上拦截、控制作用于边缘资源的请求。
3. 对于问题三，OpenYurt会在网络恢复时，从云端同步最新的数据。而KubeEdge则是每隔一段时间比较云上资源与边缘资源的版本差异，若云上资源较新，则生成一例增删改事件下发至边缘节点，网络断连时此事件被抛弃，网络重连时事件发送成功，触发边缘同步更新。
4. 对于问题四，暂不知OpenYurt对此做了何设计，在KubeEdge中，由于数据一致性由云端维护，同步均由云端发起，边端不再有类List请求。
5. OpenYurt同KubeEdge都是星型拓扑结构，在边缘去中心化，一个边缘数据中心的所有边缘节点都是同等级的peer node，同云中心的kubelet节点一致，均强受制于云上master节点，只是在地理区位上距离master节点有远近之分。
KubeEdge同时适用于边缘计算下的物联网与分布式数据中心场景，但是在后者中并不需要一些为物联网近场场景而设计的设备侧功能，使用上可以禁用；OpenYurt在阿里内部主要配合CDN业务，在设计上并未考虑在平台层进行设备接入，而是认为设备应该由基于平台的物联网应用接入，更适配分布式数据中心场景。但由于OpenYurt在今年6月才开源，谐云边缘计算团队在19年12月便开始了技术预研与选型，因而最终选择了18年便已经开源KubeEdge。
KubeEdge软件架构
谐云落地实践与KubeEdge改造赋能将在第二部分着重讲述，请关注下期分享～
