中国移动磐舟磐基平台的openEuler+KubeEdge落地实践

磐舟磐基平台及多省份集群管理的思考

磐舟一体化云交付平台是中国移动自主研发的面向开发人员的代码开发，自动部署的平台。磐舟一体化交付平台自研实现了一套GitOps驱动引擎，支持从需求设计、开发构建、测试部署的全部开发与运维功能需求，实现应用一键上磐基容器云平台。
磐基容器云平台是中国移动信息公司基于Kubernetes构建的企业级PaaS解决方案，实现Kubernetes能力的标准化封装及调用，包括提供开发和运行环境、资源弹性伸缩、精细化微服务管理、便捷一站式服务、跨地域多集群调度和智能监控维护等六大能力。
 磐舟和磐基是相互配合的，开发人员在磐舟集群上开发，部署到磐基PaaS集群上运行应用，也支持在磐舟上归档磐基集群ops配置，通过GitOps来管理、部署磐基集群。
 随着国产化进程推进，中国移动建设了大量的国产化服务器集群，磐基磐舟如何实现国产化的容器云开发交付一体化体系？在某资源池我们需要统一管理近500台鲲鹏服务器，源码可以通过磐舟统一编译为X86/ARM双架构的镜像，但是集群的管理也需要实现ARM自动化支持，开发交付环节频繁使用Kubernetes集群，最近2个月已有800多次的集群创建回收动作，人工支撑显然已经跟不上云原生的发展速度了。
另一个场景是，移动的开发人员在集团磐舟Kubernetes集群上进行开发，制作好镜像后，不能直接推送到省测公司的Kubernetes集群，需要运维人员在磐基中心集群上通过多级ssh跳板机，手工登录到省公司磐基k8s集群进行部署。这一步没有实现自动化，操作流程十分繁琐。
 想解决这些问题，我们进行了一些头脑风暴。
首先是考虑是否可以将集群统一？答案显然是不行。因为集团k8s集群，由于业务不同，不能和省公司的k8s集群合为一体。
那么是否可以做k8s的集群联邦？目前集团集群与省公司集群之间可能是比较远的(跨省)，集群联邦的整体消耗会大一些，并且目前跳板机的场景，跳到省公司集群一台机器上就够了，不需要看到省公司的所有机器。
维持ssh现状，维护shell脚本？shell脚本需要人力维护，在省公司的节点逻辑很可能需要使用service来完整，继续维护shell，第一不是那么CloudNative，第二也背离了磐基磐舟轻松上云的初衷。
本着达到灵活、易用，提升集群部署时效，解决端到端开发运维效率，成就内部客户的目的，我们针对整体场景做了进一步抽象，抽象成“1+31+N”的典型网络模型。
1个中心+“31+N”个边缘集群的场景，中心与集群、集群与集群，集群与N之间，存在着网络隔离与网络不可预知的情况；在这些集群之间，保持网络隔离的情况下，在中心节点做到云原生体验的自动化运维，做到GitOps自动化。
带着抽象之后的这个模型，我们在平台管理上进行了深入调研，最终选用了CNCF的项目KubeEdge来解决完成以上所有集群的统一管理。

KubeEdge是什么？解决什么问题？

KubeEdge的特点是在云边通信的资源消耗小，使用方式基于Kubernetes，上手方便，比较适合我们当前的场景。KubeEdge项目是华为云开源的一个基于Kubernetes的开放平台，并为网络应用提供基础架构支持，提供云和边缘之间的部署和元数据同步。KubeEdge具有以下几点关键优势：

01容器化应用封装
Build once, run anywhere

轻量化基础镜像，降低资源占用
02通用的应用抽象定义
业界事实标准

云上、边缘统一管理
03松耦合的架构
易扩展的API框架

易于定制平台组件
 KubeEdge 在架构上分为云端组件 CloudCore 和边缘侧 EdgeCore，详细的架构细节可以参考文档：
https://docs.kubeedge.io/en/docs/architecture/
最新发布的边缘版openEuler操作系统中已经集成了KubeEdge组件，支持在离线环境下快速搭建KubeEdge环境，详细内容可以参考文档：
https://docs.openeuler.org/zh/docs/22.03_LTS/docs/KubeEdge/overview.html

磐舟磐基平台的KubeEdge实践

通过对KubeEdge的应用场景分析，以及对移动内部1+31+N模型结合，我们可以将集团的“1”想象为KubeEdge的CloudCore节点、将各省公司的node节点想象为EdgeCore节点，从而就实现了1+31+N下的云边协同模型。映射到我们的具体场景是这样：

01集群业务部署场景
把集团的K8s master节点作为KubeEdge的CloudCore节点，省公司的node节点作为KubeEdge的EdgeCore节点，CloudCore节点与EdgeCore节点连接上后，在EdgeCore上启动磐舟GitOps业务中ArgoCD pod，统一下发CD一体化的元数据，从而将省公司资源池做到方便的集群创建、集群纳管，最终方便的达成自动化GitOps交付。
02集群自动化创建场景
 基于省公司的资源池来创建磐基PaaS集群，运维人员在master节点使用磐舟GitOps，通过CloudCore与EdgeCore的通信，部署来自openEuler社区的集群自动化部署工具-eggo的实例。之后在边缘侧，就可以通过eggo来自动化完成省公司磐基PaaS集群的创建。

 综上，通过将KubeEdge集成至磐基PaaS平台，成功打通移动集团与各省公司的网络，实现“1+31+N”的K8S集群全部连通、实现统一管理、简化多集群的运维系统、减少运营成本；同时也成功将前面提到的500台鲲鹏服务器以及它上面的BC-Linux for Euler集群纳入磐基PaaS平台的大家庭之中，运维效率大幅增加。

磐舟磐基平台在多集群管理的下一步计划

在完成KubeEdge集成到磐舟磐基平台这项专项工作之后，考虑到后续不仅是由master节点纳管单个edge节点，还会考虑在将南向集群的单个节点组成一个集群，实现控制面的自动化集群部署，支撑省公司集群的控制面自动化。磐舟磐基平台计划进一步集成CNCF社区最新的集群联邦方案Karmada来完成“1+31+N”的PaaS多集群统一管理工作。