来源：《华为云DTSE》第五期开源专刊

作者：徐飞  华为云高级软件工程师，KubeEdge社区TSC

摘要：由于边缘计算场景需求的日益增长，传统架构面临诸多问题，KubeEdge将云原生应用扩展到边缘计算，利用 Kubernetes 的能力来高效的管理和调度边缘设备上的工作负载。通过提供边缘设备的本地计算、存储和网络能力，减少云与边缘之间的数据传输延迟，提升应用的效率和响应速度。未来，KubeEdge 将持续创新，进一步加强可扩展性、安全性和多样化的场景支持，推动云原生边缘计算领域的发展。

1. 背景与挑战

传统边缘计算行业多层级独立控制、设备缺乏开放性，系统集成复杂等问题，导致边缘应用开发成本高，上线速度慢，缺乏智能。华为从2016年开始研究如何将易扩展、易迁移的云原生技术架构运用到边缘计算领域。

华为云于2018年11月开源业界首个云原生边缘计算项目KubeEdge，并在2019年3月捐献到云原生计算基金会（CNCF）。KubeEdge 将 Kubernetes 原生的容器编排和调度能力拓展到边缘，完整的打通了边缘计算中云、边、设备协同的场景，为用户提供一体化的云边端协同解决方案。

自开源以来，社区一直秉承开源开放的治理模式，在开放协作的理念下蓬勃发展，目前已被广泛应用于智能交通、智慧园区、工业制造、金融、航天、物流、能源、智能CDN等行业，本文结合天翼云大规模CDN场景，介绍KubeEdge社区行业落地实践。

创新使能，开放共治的云原⽣边缘计算社区

2. KubeEdge的布局和核心技术

KubeEdge基于Kubernetes原生的容器编排和调度能力之上，扩展实现了边云协同、计算下沉、海量边缘设备管理、边缘自治等能力，完整的打通了边缘计算中云、边、设备协同的场景。将云原生技术延伸到了边缘计算领域，实现了云原生生态与边缘计算生态的互通。

 KubeEdge基于Kubernetes之上，在100%兼容Kubernetes API的基础上，结合边缘计算中网络不稳定、资源受限、海量边缘设备等场景，实现的技术点包括：

1. 基于Kubernetes构建平台，提供云-边-端一致的业界标准云原生应用管理框架，解决云边协同架构中云平台厂商绑定问题；
2. 大幅优化边缘节点组件资源占用，支持管理小规格边缘网关节点；
3. 在云边之间引入双线多路复用通道，重新实现K8s控制面与节点通信机制，引入可靠校验机制，解决边缘节点与云上组件连接带宽受限、网络质量不可靠等问题；
4. 边缘节点支持数据本地持久化，支持边缘节点离线自治；
5. 北向基于Kubernetes CRD引入设备管理API，支持以Kubernetes的API标准管理边缘设备；
6. 南向提供物联网设备接入框架，内置多种主流物联网通信协议实现，并支持用户自定义扩展，解决异构设备接入复杂性问题。

3. 多领域、多行业生产落地

KubeEdge目前已被应用于广泛应用智能交通、智慧园区、工业制造、金融、航天、物流、能源、智能CDN等行业，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田等行业代表项目。

3.1 天翼云基于KubeEdge的大规模CDN场景落地实践

3.1.1天翼云CDN业务背景

中国电信以“2+4+31+X”的资源布局加速云网融合。“X”是接入层面，把内容和存储放到离用户最近的地方，实现网随云动、入云便捷、云间畅达，满足用户按需选择和低时延需求。目前天翼云基本的CDN功能已一应俱全，且资源储备丰富，支持精准调度，秉承质量优先，整体业务发展正步入快车道。

3.1.2边缘服务容器化背景​

与其他云厂商和传统的CDN厂商不同，天翼云CDN起步较晚，但也恰逢云原生理念大行其道。因此，我们选择了通过容器与Kubernetes编排技术构建CDN PaaS平台，但是CDN 边缘服务尚未完成云原生改造

存在的问题： 1）如何纳管大规模分布在边缘的CDN节点？ 2）如何对CDN边缘服务进行可靠的部署和升级？ 3）如何构建统一、可扩展资源调度平台？

3.1.3基于KubeEdge的边缘节点管理

CDN物理节点架构

CDN提供的缓存加速服务，解决最后一公里加速问题。为了满足就近接入和快速响应，大部分CDN节点需要部署到近用户侧，通过CDN 全局流量调度系统将用户访问接入到就近节点。通常CDN节点具有呈离散分布的特点，大部分以各地区域IDC和地市级别IDC机房资源为主，每个边缘机房根据出口带宽和服务器资源规划，搭建多个CDN服务集群。

边缘服务容器化技术选型​

在考虑做容器化的过程中，我们前期进行了技术选型和研究，主要是三个方向：标准K8s：边缘节点以标准worker节点加入到master，但这种方式也会存在问题，如果连接过多容易造成Relist，K8s master端负载压力大；网络波动，造成pod被驱逐，导致不必要重建；分节点接入CDN边缘节点：分集群部署K8s或K3s。这种方式的控制面与集群过多，无法构建统一的调度平台，而且每个KPI集群若按高可用方式部署也至少需要3台，会过度占用机器资源；云边接入：通过KubEedge方式接入，按照这种方式，可以收敛边缘节点连接，接入统一的K8s集群，并且提供云边协同，边缘自治等能力，还保留了大部分K8s的原生能力。

3.1.4基于KubeEdge边缘节点纳管方案​

上图是我们目前架构的示意图，我们在各区域中心及数据中心建若干个K8s集群，K8s集群下面是边缘按就近规划的接入到区域的集群。 为了避免单点接入，以及单K8s集群CloudCore 负载过大的问题，在各大区建设K8s集群，用于边缘节点的接入和应用编排管理。但在社区早期1.3版本中，当时提供的高可用方案只是单组多重这种高可用方式，而实际是无法满足我们大规模纳管的性能要求，因此我们后面在社区推出多组部署方式。 这种部署方式在早期使用的过程中并没有问题，但当接入的边缘节点，还有部署的容器数量过多时，这个问题就逐渐暴露出来：

CloudCore 多副本部署连接不均衡问题​

上图为hub到upstream 最终提交到apiserver的示意图。中间 upstream模块有一部分的分发，它是用单线程的方式来运行，中间upstream模块，因为只有单线程，会导致消息提交过慢，边缘节点的一些node无法及时提交给apiserver，最终引起我们部署方面的一些异常。后面我们把CloudCore按多副本去部署，又出现了在CloudCore进行升级或者一些意外重启过程中，会发现连接不均衡的问题。为了解决这个问题，我们在多副本之前，部署了4层的lb，并在lb上配置了诸如listconnection的负载均衡策略，但实际上像 ls这种负载4层的负载平衡，它都有一些筛选的缓存机制，并不能保证连接的均衡的分配。基于以上背景我们进行了优化：

CloudCore多副本均衡优化方案​

• CloudCore 每个实例在启动后各自通过Configmap 的方式上报实时的连接数等信息； ② CloudCore结合本地实例与其他实例的连接数， 计算每个机器的期望连接数 ③ 计算本地连接数与期望连接数的相差比例，相差比例大于最大可容忍连接数差，进入连接待释放阶段，并进入一个30s 观察周期； ④ 观察过后，进入下一个检测周期，直到连接均衡。

3.1.5边缘应用服务部署

CDN加速服务整体流程

CDN它主要分为两大核心系统：调度系统和缓存系统。调度系统会实时采集全网的CDN链路情况，实时的节点的情况，以及节点的带宽成本的情况，从而决策出最优调度的覆盖数据，将这个数据推给Local Dns或302或hds的一个的调度器。Local Dns拿到最优数据后，来进行 Dns的解析响应，用户端通过解析响应可就近接入到边缘集群，边缘集群因为涉及到缓存，有可能涉及到miss，如果miss后，它会回到上一层的缓存，一般会有两层或者三层的中转的缓存，最终回到原状。

如果中转的缓存也没有，数据会再回到云站，这是CDN服务的整体流程。 在缓存系统，一般不同产品的缓存会使用不同的服务，比如面向直播的流媒体的加速服务和一些静态的加速会有一些区别。这也给开发和维护造成了一些成本，后面它们的融合可能也是一个趋势。 CDN缓存服务的特点：

• 资源独占：缓存服务是要最大利用存储，机器上的存储和带宽的资源的一个服务，所以说它需要独占
• 大规模高服用：规模很大，覆盖广，同个软件或同一台机器的缓存服务，可能要承接上万个域名，甚至10万域名
• 容灾分区故障：容忍组内小部分节点的缓存丢失，或者是全局有少量的节点缓存失效，缓存过多会造成击穿，反之击穿就回到上层的缓存，造成访问延迟变大，最终引起服务异常。
• 高可用：4/7层LB具备实时探测和切流、引流能力；L4 LB保证组内主机间的流量均衡；L7 LB通过一致性哈希尽量保证让每个url在组内只存一份副本

从以上的特征，我们看到CDN在部署中，要解决以下问题： 1）如何让节点容器有序和可控的升级？ 2）如何进行版本的A/B 测试？ 3）如何对升级过程进行校验？

我们的升级部署方案包括​

分批升级与组内升级并发控制：创建分批升级任务；

控制器按指定机器进行升级、细粒度版本设置：创建主机粒度版本映射；

控制器增加pod 版本选择逻辑，优雅升级：通过lifecycle的 prestop/postStart 实现常规切流与恢复，特殊场景联动GSLB进行切流；

升级校验：Controller与监控系统联动，升级过程发现服务异常，及时终止与回滚；

编排安全防护：Workload 粒度与pod粒度通过Adminsion Webhook增加校验是否符合期望修改与删除；

3.1.6基于KubeEdge CDN边缘容器容灾与迁移​

迁移步骤：

1. 备份etcd，在新集群中restore；
2. 切换接入DNS；
3. 重启CloudCore 断开云边hub连接；

优点： 1、成本低，由于KubeEdge的边缘自治特性，边缘容器无重建，服务无中断； 2. 流程简单，可控，服务安全性高；

3.1.7 CDN大规模文件分发​

需求场景： •CDN边缘服务配置 •GSLB调度决策数据 •容器镜像预热任务

3.1.8未来架构演进方向思考

边缘计算挑战

资源管理：分布广泛，种类多，架构、规格不统一

网络时延、可靠：异构网络，移动网络等弱网环境，带宽受限，稳定性不足

安全：边缘服务更难形成统一的安全防护体系

业务多样：场景、业务种类多样

基于CDN的边缘计算平台基础能力​

资源： CDN节点覆盖广、潮汐特性特性资源冗余；通过Kubeedge提供了云边协同；可延伸端侧，具有异构资源部署与管理能力；

调度与网络：专用EDNS支持地市级精准调度，实现真正就近接入；CDN服务与边缘计算服务统一调度；云边专用网络，管理通道、数据回传、动态加速网络更可靠；大规模V6支持；

安全能力：CDN Waf 抗D、流量清洗、近源拦截等; 证书加速与安全，SSL硬件卸载、keyless无私钥方案，提供边缘安全接入；

网关：边缘调度与丰富的负载均衡能力；通用协议处理能力，常规流媒体协议，满足大多互联网加速场景。

业务探索​

未来将在离线计算类、视频编转码、视频渲染、批量作业、拨测、压测类持续探索实践。

4.   总结

作为业界首个云原生边缘计算社区，KubeEdge社区目前已完成包括业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目等在内的诸多行业代表项目。截至目前，KubeEdge在全球已有超1600名开发者参与代码贡献，覆盖中国、美国、德国、韩国、日本、土耳其、意大利、波兰、墨西哥、俄罗斯、英国、西班牙、印度、尼加拉瓜等国家，100余家企业与科研机构参与项目合作。

在未来，KubeEdge社区将在固定边缘、移动边缘、边缘AI等领域不断探索，KubeEdge社区期待与你协作创新，共同促进云原生边缘计算发展！

附：KubeEdge社区贡献和技术交流地址

网站: https://kubeedge.io

GitHhub地址: https://github.com/kubeedge/kubeedge