本文来源于《华为云DTSE®》第五期开源专刊，更多文章请查看：https://bbs.huaweicloud.com/blogs/435823

　　作者：徐飞 华为云高级软件工程师，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缓存服务的特点：

　　1、资源独占：缓存服务是要最大利用存储，机器上的存储和带宽的资源的一个服务，所以说它需要独占

　　2、大规模高服用：规模很大，覆盖广，同个软件或同一台机器的缓存服务，可能要承接上万个域名，甚至10万域名

　　3、容灾分区故障：容忍组内小部分节点的缓存丢失，或者是全局有少量的节点缓存失效，缓存过多会造成击穿，反之击穿就回到上层的缓存，造成访问延迟变大，最终引起服务异常。

　　4、高可用：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