中国移动10086客服容器云边协同实践案例

如果无法正常显示，请先停止浏览器的去广告插件。

2. CONTENTS 目录 01 云边协同背景 02 客服行业落地案例 03 总结与展望

3. 中国移动在线营销服务中心介绍在线营销服务中心是中国移动通信集团二级专业机构，负责全网在线服务资源和线上渠道运营管理，拥有全球最大的呼叫中心自有坐席4.4万，服务用户9亿，53个客服中心，是客服技术和客服业务的时代引领者。 2014年10月成立 2020年与中国移动集 2016年底中国移动各省中运营中心整合，成立 10086呼叫业务全部整合至 2018年入选国资委在线营销服务中心中移在线公司，实行专业化 “双百行动”企业经营。未来 2014年 2016年 2018年定位 A 线上渠道的生产运营者 5G精准营销外呼渠道支撑专席... B 在线服务的全网提供者 86热线、5G视频、互联网服务 2020年 C 全网生态合作运营的支撑者互联网权益、智慧家庭、全国连锁企业合作... 中心已承接中国移动10086全网在线服务包括（中国移动APP、门户网站、小程序、热线、短信、直播、实名认证等）服务渠道的集中化运营。形成了“31省+ 两园区”的整体格局，是集团公司下聚焦于数字化服务的全国性二级专业机构。 D 智能化营销服务能力的构建者大数据精准分析 5G视频新型交互体验...

4. 云原生路线 • 虚拟化时代，VMware简单虚拟化，资源发放效率低，资源不具备弹性伸缩能力，业务高峰无法快速扩容资源。虚拟化阶段 • 云原生时代，K8S+Docker容器云，分公司云化比例低，算力发挥有限， “话务集中控制+媒体就近接入” 架构导致网络带宽成本上升。云计算阶段 • 云计算时代，OpenStack+KVM资源池，虚拟化资源利用率低，自动弹性伸缩不足，无法应对驼峰式流量，业务集中化需求大幅增加，研发交付效率下降。云原生阶段 • 基于云原生架构，继续创新。云边协同阶段 • 云边协同时代，KubeEdge框架，将容器云能力向分公司下沉，打造中心+边缘一朵云，加速基础设施云改。未来

5. 云边协同驱动力公司核心的融合客服系统具有“话务集中控制、媒体就近接入”的架构特性，需在各省分公司机房部署少量的服务器设备，所以全网服务器资源形成以双中心+31省分中心为接入点的星状拓扑结构。另外为解决网络时延、音视频数据传输等瓶颈，满足营销服务业务高标准的用户体验要求，公司视频客服、全语音门户等多媒体业务系统向分公司下沉部署。分中心资源池暴露出以下问题：问题1：业务支撑响应慢。分公司业务系统存在独立资源池的“烟囱式”问题，系统间的服务器资源无法共享，敏捷性较差，无法实现系统快速弹性扩缩容，影响营销服务业务的客户体验和系统稳定性；问题2：业务运维效率低。分公司部署的业务模块均为人工手动维护，人工操作易出错、效率低、故障率高。问题3：资源利用率低。目前服务器以传统虚拟化技术为主要支撑形态，导致算力无法聚合，资源利用不充分，低效、冗余资源亟需整合利旧。 A中心 B中心智能客服应用智能客服应用精准营销平台实名认证概念图 A控制中心语音专线精准营销平台数据专线大数据分析 AI 实名认证控制中心语音专线大数据分析 AI 在线VPN/互联网分中心边缘计算软交换边缘存储媒体加速中继网关融合座席边缘通信互联网/PLMN B控制中心客户互联网/专网客户媒体节点

6. 云边协同选型分析（一）边缘存在形态主要有两种：边缘集群、边缘节点。 Ø 边缘集群 ü 全量管理能力 ü 额外的控制层实现协同 Ø ü ü ü ü 边缘节点复用云端管理能力云边协同离线自治原生K8S API

7. 云边协同选型分析（二）边缘节点形态下，当前主流的开源项目有：KubeEdge、OpenYurt和SuperEdge。对比项 KubeEdge OpenYurt SuperEdge 开源时间 2018年11月 2020年5月 2020年12月 CNCF Incubation Sandbox 无设备支持支持否否承载能力 >k8s =k8s =k8s 边缘组件数量（含kubelet） 1 3 5 资源占用 <=kubelet >kubelet >kubelet 社区活跃度 KubeEdge OpenYurt SuperEdge 3765 1705 1054 987 773 单元管理网格流量控制无无有无有 364 69 21 有 star issue 185 pr 63 159 fork 62 55 5 188 5 member 30 16 Contributors

8. CONTENTS 目录 01 云边协同背景 02 客服行业落地案例 03 总结与展望

9. 云边协同框架在k8s基础上通过云边代理模式构建“中心+边缘”的云边协同架构，实现以本部双中心服务器为中心节点，分中心为边缘节点的“计算拉伸方案”落地，将容器云计算能力下沉至边缘节点，实现统一的资源调度和纳管能力。 u 集中管理通过统一容器管理平台进行集群的管理 u 边缘纳管管理平台统一边缘节点的纳管 u 离线自治 Kubeedge基础上增加边缘代理，提升离线自治能力 u CI/CD 复用管理平台CICD构建能力，提升服务发布效率 u 云边协同构建数据协同、管理协同、运维协同的平台。

10. 边缘网络边缘节点网络可选模型较多，综合分析对比，确定落地网络方案，实现分公司内流量闭环。 CNI 规范场景结论 CNM Container Network Interface，CNI是由CoreOS提出的一个容器网络规范。已采纳改规范的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。另外 Contiv Networking, Project Calico 和 Weave这些项目也为CNI提供插件。 Container Network Model，CNM是一个被 Docker 提出的规范。现在已经被Cisco Contiv, Kuryr, Open Virtual Networking (OVN), Project Calico, VMware 和 Weave 这些公司和项目所采纳。 1. 分公司节点与分公司容器边缘节点网络互通 2. 分公司边缘Pod访问总部服务 calico ipip网络

11. 边缘服务访问 | 能力下沉集群内访问通过coreDNS实现服务暴露，集群外部访问通过Ingress实现服务暴露。集群内集群外 API Server 云端分公司用户 list/watch资源变化云端分公司 KubeProxy CoreDNS 创建 Pod1 API Server list/watch资源变化 Ingress Controller 析解域名 ipvs或者 iptables规则 Pod1 Pod2 Pod... Podn

12. 边缘服务访问 | 服务分组分流流量隔离为应对超大规模流量接入，实现流量隔离，定义多IngressController并分配给一个或多个租户访问流量 K8s集群服务1流量服务2流量分组部署支持分组部署，满足应用系统的故障隔离，并缩小故障影响范围租户1：项目1 租户负载均衡控制器自定义负载均衡器租户2：项目2 租户负载均衡控制器灰度发布为及早获得用户反馈，降低新应用升级的影响，将特定用户的请求分发到灰度服务，从而控制风险，并对产品特性的发布有一个循序渐进的迭代过程无感知发布采用主备服务模式，在发布过程中按照流量比例进行实例自动伸缩，从而达到业务无中断、用户无感知 A组流量服务分组A B组流量服务分组B 灰度X组流量 A/B/X组流量灰度服务分组X 服务分组A/B/C

13. 边缘资源管理常规的租户分区模式有资源配额限制，资源碎片化较为严重，不能有效的支撑容器云弹性伸缩的特性，不适合企业级大规模应用。资源池技术： ü 污点技术：通过污点标签技术，将集群划分多个资源池； ü 调度能力：通过多污点容忍方式，按污点优先级不同，定义资源池调度优先级。资源池优势： ü 提升资源利用率：不需要租户分区保留冗余资源，减少资源碎片化； ü 资源应急支撑能力：急资源池集中冗余资源算力，可大幅增强紧急状态下的资源支撑能力。

14. 边缘代理大边缘场景下，下沉较多的云端能力，构建边缘代理，提升系统组件离线自治能力，全面建设节点级别离线自治能力。原有模式 ? 问题改进模式 API Server 网络断链之后，系统组件如何提供离线自治能力？ API Server ó 解决方式 CloudCore Node CoreDns Calico- node Kube- Proxy 云端云端边缘边缘 CloudCore Node EdgeProxy EdgeCore ingress controller EdgeCore CoreDns ingress controller Calico- node Kube- Proxy 增加边缘代理模块，通过http代理方式，代理系统组件请求，拦截请求数据，缓存在本地，在离线时，使用缓存数据对系统组件提供服务 ü Tips：该模式无法解决relist/rewatch的问题，可以尝试使用KubeEdge 1.6版本的边缘list-watch功能

15. 边缘故障隔离采用两级隔离架构，实现自动监测、自动隔离等功能，全面覆盖集群关键组件及Node故障等场景，有效降低业务故障时间，保障业务持续稳定运行。隔离控制器 p 精确识别问题 APIServer 细粒度组件运行状态监控，叠加故障场景云端边缘分公司1 分公司... Pod流量秒级切断，降低故障对业务影响 Node Node- Agent Pod Ingress- Checker OS p 秒级故障诊断 ... 组件 p 双向心跳探测提升故障判断的准确率，避免 node-agent启动引起问题 p 区域级别探测 region=xxx region=... 精准识别单节点问题或者区域故障，避免边缘弱网环境下误判

16. 离线IP保持原生CNI组件基本上依赖云端能力（APIServer/ETCD），离线时无法完成IP分配，建设IP快照能力，实现Pod IP 在离线重启保持不变。原有模式改进模式 API Server API Server Node ? 问题 IP分配由CNI进行控制，如何在离线情况下， Pod重启依旧保持原有IP？ ó 解决方式对CNI返回结果增加IP快照信息，在网络正常时，调用ipam组件进行IP分配；离线时使用本地磁盘 ※ 无侵入 Node 探测healthz接口 calico calico- ipam calico snapshot -ipam calico- ipam 对整体CNI的设计没有太多的侵入性的设计，可灵活对接其他CNI的实现 ※ 易部署通过DaemonSet进行分发二进制即可 disk ※ 易使用简单调整已有的CNI配置文件即可完成使用

17. 分级镜像仓库云边网络质量较差，采用统一的云端镜像仓库，镜像拉取可对网络带来较大的冲击，设计分级镜像仓库，降低镜像拉取对网络的冲击。 ü 中心主备双仓：主仓库对接OSS，备用仓库非高可用部署使用本地磁盘高可用：主仓库通过keepalived +vip方式提供服务 _x0001_ ü 边缘独立部署：分公司部署独立镜像仓库，边缘节点就近拉取镜像高可用：采用非高可用方式部署，但与中心仓库形成主备模式 ü 管理集中构建：利用管理平台CI能力实现镜像的集中构建统一推送：分公司业务镜像实现对中心和边缘仓库的统一推送

18. 联邦监控采用Prometheus+AlertManager+Grafana的形式监控，打造“中心+边缘”联邦式监控。 Ø 联邦监控分公司部署非高可用Prometheus，与云端Prometheus构建集群联邦 Ø 统一展示数据集中汇总到总部Prometheus 集群，统一对接Grafana面板进行数据展示 Ø 集中告警数据在总部Prometheus进行分析，接入AlterManager进行数据告警 Ø 个性采集边缘侧Prmetheus可根据业务监控需求，灵活对业务进行统一的监控数据采集

19. CONTENTS 目录 01 云边协同背景 02 客服行业落地案例 03 总结与展望

20. 部分基于KubeEdge定制改造 1 keadm debug工具套件 l 丰富边缘节点故障时排查手段，简化边缘问题排查方式。主要包含keadm debug get/check/diagnose/collect命 2 令 l 已贡献给KubeEdge社区 CloudCore内存占用优化 l 优化CloudCore内部 informer、client的使用方式，精简LocationCache缓存数据，整体内存占用降低40%左右 l 已贡献给KubeEdge社区 3 节点默认标签和污点 l 边缘节点启动时默认增加指定的label和taint，简化边缘节点添加特定属性的操作流程 l 已贡献给KubeEdge社区 4 主机资源预留 l 边缘节点预留系统资源，允许设置节点最大Pod数，避免整体资源被Pod全部占用，提升边缘节点的稳定性 l 待社区审核

21. 云边协同落地经验总结基于KubeEdge云边协同框架，提升了对边缘的纳管能力以及服务发布效率社区出发从落地出发，完善KubeEdge能力，做社区贡献回馈社区场景驱动细化故障场景，打造全面的故障隔离方案，缩小故障影响范围深入业务满足业务是第一优先级，提供合理的网络方案以及负载均衡方案完善周边构建分级镜像仓库，联邦监控等不断完善日常使用环节

22. 未来演进方向统一负载架构 • 边缘节点基于kubevirt的统一负载架构（虚拟化和容器）坚持创新边缘中间件服务纳管 • 完成对边缘的中间件服务容器化的纳管 1.3W+ ...

23.