【翻译】e-Cloud。使用KubeEdge的大规模CDN

CSDN-Ada助手

于 2022-06-24 18:06:07 发布

阅读量448

点赞数 1

作者：阮兆银 2022年3月18日

来自KubeEdge的阮兆银的项目文章

本文介绍了e-Cloud如何使用KubeEdge来管理CDN边缘节点，自动部署和升级CDN边缘服务，并在其将CDN服务迁移到云端时实施边缘服务灾难恢复（DR）。

本文包括以下四个部分。

项目背景
基于KubeEdge的边缘节点管理
边缘服务部署
架构演进方向

项目背景

中国电信e-Cloud CDN服务

中国电信通过2+4+31+X的资源部署，加速云网协同。X是靠近用户的接入层。e-Cloud是CDN的后来者，但他们的CDN发展迅速。e-Cloud提供所有基本的CDN功能和丰富的资源，支持精确调度，并提供高质量的服务。

背景介绍

与其他云计算厂商和传统的CDN厂商不同，e-Cloud的CDN是云原生开发的。他们建立了一个运行在容器和Kubernetes上的CDN PaaS平台，但并没有完成CDN边缘服务的云原生重构。

他们曾经面临的问题。

如何管理大量的CDN边缘节点？
如何部署和升级CDN边缘服务？
如何构建一个统一的、可扩展的资源调度平台？

基于KubeEdge的边缘节点管理

CDN节点架构

CDN提供缓存加速功能。为了实现就近访问和快速响应，大多数CDN节点都部署在用户附近，因此请求可以由CDN全局流量调度系统调度到附近的节点。大多数CDN节点离散地分布在区域IDC中。根据出口带宽和服务器资源，在每个边缘机房设置了多个CDN服务集群。

容器化技术选择

在容器化的过程中，他们在早期阶段考虑了以下技术。

标准的Kubernetes。边缘节点作为标准工人节点被添加到集群中，并由主节点管理。然而，太多的连接造成了重列问题和Kubernetes主节点的沉重负荷。吊舱由于网络波动而被驱逐，导致不必要的重建。

按节点访问。Kubernetes或K3s被部署在集群中。但会有太多的控制平面和集群，无法构建一个统一的调度平台。如果每个KPI集群以HA模式部署，至少需要三台服务器，占用过多的机器资源。

云边缘接入。边缘节点使用KubeEdge连接到Kubernetes集群。更少的边缘节点连接被生成，云-边缘协同、边缘自治和原生Kubernetes功能可以被实现。

解决方案设计

上图显示了优化后的架构。

在每个区域中心和数据中心创建了几个Kubernetes集群，以避免单点访问和单个Kubernetes集群的重负荷。边缘节点被连接到离它们最近的区域集群上。早期的1.3版本只提供单组、多节点的HA解决方案。它不能满足大规模的管理。所以他们采用了多组部署。

这种模式在早期阶段很有效。然而，当边缘节点和部署的集群数量增加时，出现了以下问题。

CloudCore多副本部署中的不平衡连接

the connection process from the hub to upstream and then to the API server

上图显示了从集线器到上游再到API服务器的连接过程。上游模块使用单线程分发消息。因此，消息的提交速度很慢，某些边缘节点未能及时向API服务器提交消息，导致部署异常。

为了解决这个问题，e-Cloud以多副本模式部署了CloudCore，但在CloudCore升级或意外重启期间，连接是不平衡的。e-Cloud随后向多副本添加了第4层负载平衡，并配置了listconnection等负载平衡策略。然而，第4层负载平衡有缓存过滤机制，不能确保连接的均匀分布。

经过优化，他们采用了以下解决方案。

CloudCore多副本平衡解决方案

CloudCore实例启动后，它通过ConfigMaps报告实时连接数等信息。
它根据自身和其他实例的连接数，计算出每个节点的预期连接数。
它计算实时连接数和预期连接数之间的差异。如果差值大于可容忍的最大差值，实例开始释放连接，并开始一个30秒的观察期。
观察期结束后，实例开始一个新的检测期。当连接数达到平衡时，它将停止这个过程。

连接数的变化

重启后的负载平衡

边缘服务部署

CDN加速过程

CDN由两个核心系统组成：调度和缓存。调度系统实时收集整个网络上的CDN链接、节点和节点带宽使用状况，计算最佳调度路径，并将路径数据推送给本地DNS、302重定向或HTTP动态流（HDS）。

然后，本地DNS服务器对数据进行解析，并将结果发送给客户端，这样客户端就可以访问最近的边缘集群。边缘集群检查它是否已经缓存了请求的内容。如果没有缓存命中，边缘集群会检查它的上两层或三层是否已经缓存了该内容。如果没有，边缘集群从云站点检索内容。

在缓存系统中，产品所使用的服务，如直播流和静态内容加速，是不同的。这需要更多的开发和维护成本。不同加速服务的融合可能是一种趋势。

CDN缓存服务的特点。

1.独有的存储和带宽资源

2.大规模的覆盖。软件或机器的缓存服务甚至可以支持10万个域名。

3.按区域容忍DR故障。少数节点的缓存会丢失或过期。缓存内容太多，会造成故障。当这样时，内容会被反缓存到上层。因此，访问速度减慢，服务变得不正常。

4.4.高可用性。负载均衡提供实时检测和流量切换/分流。第4层负载平衡确保了组内主机之间的流量平衡。第7层负载均衡通过一致的散列确保每个URL只有一个副本被存储在一个组中。

在CDN部署过程中，以下问题值得注意。

可控的节点容器升级
版本的A/B测试
升级验证

升级部署方案包括

批量升级和组内升级的并发控制
- 创建一个批量升级任务
- 通过控制器对指定节点进行升级
细致的版本设置
- 创建主机级的版本映射
- 在控制器中添加选择吊舱版本的逻辑
优雅的升级。
- 使用停运前和停运后脚本进行正常的流量切换和恢复
- 在特殊情况下关联GSLB进行流量切换
升级验证。控制器与监控系统一起工作。如果在升级过程中检测到服务异常，控制器会停止升级并回滚到源版本。
安全协调。入场网络钩子被用来检查工作负载和pod是否符合预期。

基于KubeEdge的CDN边缘容器DR和迁移

迁移程序

备份etcd并在新集群中恢复它。
切换到DNS。
重新启动CloudCore，并断开云和边缘中心的连接。

优势

低成本。通过KubeEdge的边缘自主性，边缘容器不需要重建，服务也不会中断。
过程简单、可控，服务安全性高

CDN大规模文件分发

场景

CDN边缘服务配置
GSLB调度决策数据
容器图像缓冲任务

架构演进方向

边缘计算的挑战

管理广泛分布的、不同的资源，架构和规范不一致
异构网络、移动网络和其他薄弱网络的带宽有限，稳定性差
边缘服务缺乏统一的安全系统
广泛的服务场景和类型

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

资源。
- 分布式节点和为服务激增预留的多余资源
- 通过KubeEdge实现云-边缘的协同效应
- 客户机上的异构资源部署和管理
调度和网络。
- 专用的EDNS，用于市级和就近接入的精确调度
- CDN和边缘计算的统一调度
- 用于可靠管理通道、数据回程和动态加速的云边缘专用网络
- 支持IPv6
安全性。
- CDN+WAF防DDoS、流量清洗和近源拦截
- HTTPS加速、SSL卸载和无钥匙认证
网关。
- 边缘调度和强大的负载平衡
- 处理一般协议，包括流媒体协议