天翼云基于 KubeEdge 的大规模 CDN 场景落地实践
2021 年 11 月 13 日，在云原生边缘计算论坛中，中国电信天翼云容器研发技术专家阮兆银发表了主题为《天翼云基于 KubeEdge 的大规模 CDN 场景落地实践》的演讲。介绍了天翼云 CDN 在云化过程中，如何通过 KubeEdge 完成 CDN 边缘节点纳管、CDN 边缘服务自动化部署升级以及边缘服务灾备等实践活动。
▲阮兆银 / 中国电信天翼云容器研发技术专家
演讲主要包含以下四个方面的内容：
1）天翼云 CDN 云化项目背景
2）基于 kubeedge 的边缘节点管理
3）边缘应用服务部署
4）未来架构演进方向思考
01 天翼云 CDN 云化项目背景
天翼云 CDN 业务背景
中国电信以“2+4+31+X”的资源布局加速云网融合。“X”是接入层面，把内容和存储放到离用户最近的地方，实现网随云动、入云便捷、云间畅达，满足用户按需选择和低时延需求。天翼云虽然 CDN 起步较晚，但是目前基本的 CDN 功能已一应俱全，且资源储备丰富，支持精准调度，秉承质量优先，整体业务发展正步入快车道。
边缘服务容器化背景
与其他云厂商和传统的 CDN 厂商不同，天翼云 CDN 起步较晚，但也恰逢云原生理念大行其道。因此，我们选择了通过容器与 k8s 编排技术构建 CDN PaaS 平台，但是 CDN 边缘服务尚未完成云原生改造。
存在的问题：
如何纳管大规模分布在边缘的 CDN 节点？
如何对 CDN 边缘服务进行可靠的部署和升级？
如何构建统一、可扩展资源调度平台？
02 基于 kubeedge 的边缘节点管理
CDN 物理节点架构
CDN 提供的缓存加速服务，解决最后一公里加速问题。为了满足就近接入和快速响应， 大部分 CDN 节点需要部署到近用户侧，通过 CDN 全局流量调度系统将用户访问接入到就近节点。通常 CDN 节点具有呈离散分布的特点，大部分以各地区域 IDC 和地市级别 IDC 机房资源为主，每个边缘机房根据出口带宽和服务器资源规划，搭建多个 CDN 服务集群。
边缘服务容器化技术选型
在考虑做容器化的过程中，我们前期进行了技术选型和研究，主要是三个方向：
标准 K8s：边缘节点以标准 worker 节点加入到 master，但这种方式也会存在问题，如果连接过多容易造成 Relist，k8s master 端负载压力大；网络波动，造成 pod 被驱逐，导致不必要重建
分节点接入 CDN 边缘节点：分集群部署 K8s 或 K3s。这种方式的控制面与集群过多，无法构建统一的调度平台，而且每个 KPI 集群若按高可用方式部署也至少需要 3 台，会过度占用机器资源；
云边接入：通过 KubEedge 方式接入，按照这种方式，可以收敛边缘节点连接，接入统一的 K8S 集群，并且提供云边协同，边缘自治等能力，还保留了大部分 K8s 的原生能力。
基于 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 观察周期；
观察过后，进入下一个检测周期，直到连接均衡。
连接数变化示意图
重启之后的均衡情况
03 边缘应用服务部署
CDN 加速服务整体流程
CDN 它主要分为两大核心系统：调度系统和缓存系统。调度系统会实时采集全网的 CDN 链路情况，实时的节点的情况，以及节点的带宽成本的情况，从而决策出最优调度的覆盖数据，将这个数据推给 Local Dns 或 302 或 hds 的一个的调度器。
Local Dns 拿到最优数据后，来进行 Dns 的解析响应，用户端通过解析响应可就近接入到边缘集群，边缘集群因为涉及到缓存，有可能涉及到 miss，如果 miss 后，它会回到上一层的缓存，一般会有两层或者三层的中转的缓存，最终回到原状。如果中转的缓存也没有，数据会再回到云站，这是 CDN 服务的整体流程。
在缓存系统，一般不同产品的缓存会使用不同的服务，比如面向直播的流媒体的加速服务和一些静态的加速会有一些区别。这也给开发和维护造成了一些成本，后面它们的融合可能也是一个趋势。
CDN 缓存服务的特点
资源独占：缓存服务是要最大利用存储，机器上的存储和带宽的资源的一个服务，所以说它需要独占
大规模高服用：规模很大，覆盖广，同个软件或同一台机器的缓存服务，可能要承接上万个域名，甚至 10 万域名
容灾分区故障：容忍组内小部分节点的缓存丢失，或者是全局有少量的节点缓存失效，缓存过多会造成击穿，反之击穿就回到上层的缓存，造成访问延迟变大，最终引起服务异常。
高可用：4/7 层 LB 具备实时探测和切流、引流能力；L4 LB 保证组内主机间的流量均衡；L7 LB 通过一致性哈希尽量保证让每个 url 在组内只存一份副本
从以上的特征，我们看到 CDN 在部署中，要解决以下问题：
如何让节点容器有序和可控的升级？
如何进行版本的 A/B 测试？
如何对升级过程进行校验？
我们的升级部署方案包括：
分批升级与组内升级并发控制：
创建分批升级任务
控制器按指定机器进行升级
细粒度版本设置：
创建主机粒度版本映射
控制器增加 pod 版本选择逻辑
优雅升级：
通过 lifecycle 的 prestop/postStart 实现常规切流与恢复
特殊场景联动 GSLB 进行切流
升级校验：Controller 与监控系统联动，升级过程发现服务异常，及时终止与回滚
编排安全防护：Workload 粒度与 pod 粒度通过 Adminsion Webhook 增加校验是否符合期望修改与删除
基于 kubeedge CDN 边缘容器容灾与迁移
迁移步骤：
1）备份 etcd，在新集群中 restore；
2）切换接入 DNS；
3）重启 cloudcore 断开云边 hub 连接；
优点：
成本低，由于 KubeEdge 的边缘自治特性，边缘容器无重建，服务无中断；
流程简单，可控，服务安全性高；
CDN 大规模文件分发
需求场景：
CDN 边缘服务配置
GSLB 调度决策数据
容器镜像预热任务
04 未来架构演进方向思考
边缘计算挑战
资源管理：分布广泛，种类多，架构、规格不统一
网络时延、可靠：异构网络，移动网络等弱网环境，带宽受限，稳定性不足
安全：边缘服务更难形成统一的安全防护体系
业务多样：场景、业务种类多样
基于 CDN 的边缘计算平台基础能力
资源：
CDN 节点覆盖广、潮汐特性特性资源冗余；
通过 Kubeedge 提供了云边协同；
可延伸端侧，具有异构资源部署与管理能力；
调度与网络：
专用 EDNS 支持地市级精准调度 ， 实现真正就近接入；
CDN 服务与边缘计算服务统一调度；
云边专用网络，管理通道、数据回传、动态加速网络更可靠；
大规模 V6 支持
安全能力：
CDN Waf 抗 D、流量清洗、近源拦截等;
证书加速与安全，SSL 硬件卸载、keyless 无私钥方案，提供边缘安全接入；
网关：
边缘调度与丰富的负载均衡能力；
通用协议处理能力，常规流媒体协议，满足大多互联网加速场景
CDN 边缘计算演进
边缘基础设施建设
节点扩展边缘计算与 CDN 混合节点
节点粒度的 service mesh 网络
完善容器隔离与安全
CDN 网关 ingress 化、通用化
CDN 边缘资源虚拟化
构建边缘 serverless 容器平台
构建 CDN 调度与容器统一资源调度平台
业务探索
离线计算类、视频编转码、视频渲染
批量作业
拨测、压测类
最后，欢迎大家加入 KubeEdge 社区，一起让边缘计算的生态更加繁荣！
附：KubeEdge 社区贡献和技术交流地址
Github 地址: https://github.com/kubeedge/kubeedge
Slack 地址: https://kubeedge.slack.com
邮件列表: https://groups.google.com/forum/#!forum/kubeedge
每周社区例会: https://zoom.us/j/4167237304
Twitter: https://twitter.com/KubeEdge
文档地址: https://docs.kubeedge.io/en/latest/
还未添加个人签名 2020.02.11 加入
还未添加个人简介
评论