本文来源于《华为云 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
广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。