磐舟磐基平台：基于 KubeEdge 的落地实践

2023-06-26
广东
本文字数：2502 字
阅读完需：约 8 分钟

本文分享自华为云社区《中国移动：磐舟磐基平台基于KubeEdge的落地实践》，作者：中国移动磐舟磐基团队 & 华为 iSula 团队 & CNCF 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 具有以下几点关键优势：

容器化应用封装

» Build once, run anywhere

» 轻量化基础镜像，降低资源占用

通用的应用抽象、定义

» 业界事实标准

» 云上、边缘统一管理

松耦合的架构

» 易扩展的 API 框架

» 易于定制平台组件

磐舟磐基平台的 KubeEdge 实践

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

» 集群业务部署场景：把集团的 K8s master 节点作为 KubeEdge 的 CloudCore 节点，省公司的 node 节点作为 KubeEdge 的 EdgeCore 节点，CloudCore 节点与 EdgeCore 节点连接上后，在 EdgeCore 上启动磐舟 GitOps 业务中 ArgoCD pod，统一下发 CD 一体化的元数据，从而将省公司资源池做到方便的集群创建、集群纳管，最终方便的达成自动化 GitOps 交付。

» 集群自动化创建场景：基于省公司的资源池来创建磐基 PaaS 集群，运维人员在 master 节点使用磐舟 GitOps，通过 CloudCore 与 EdgeCore 的通信，部署来自 openEuler 社区的集群自动化部署工具-eggo 的实例。之后在边缘侧，就可以通过 eggo 来自动化完成省公司磐基 PaaS 集群的创建。

综上，通过将 KubeEdge 集成至磐基 PaaS 平台，成功打通移动集团与各省公司的网络，实现“1+31+N”的 K8S 集群全部连通、

实现统一管理、简化多集群的运维系统、减少运营成本；同时也成功将前面提到的 500 台鲲鹏服务器以及它上面的 BCLinux for Euler 集群纳入磐基 PaaS 平台的大家庭之中，运维效率大幅增加。

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

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