随着vivo业务迁移到k8s的增长，我们需要将k8s部署到多个数据中心。如何高效、可靠地在数据中心管理多个大规模的k8s集群是我们面临的关键挑战。kubernetes的节点需要对os、docker、etcd、k8s、cni和网络插件的安装和配置，维护这些依赖关系繁琐又容易出错。

以前集群的部署和扩缩容主要通过ansible编排任务，黑屏化操作、配置集群的inventory和vars执行ansible playbook。集群运维的主要困难点如下：

本文将分享我们开发的Kubernetes-Operator，采用K8s的声明式API设计，可以让集群管理员和Kubernetes-Operator的CR资源进行交互，以简化、降低任务风险性，只需要一个集群管理员就可以维护成千上万个k8s节点。

主要基于ansible定义的OS、docker、etcd、k8s和addons等集群部署任务。

主要流程如下：

上面是集群一键部署关键流程。当在多个数据中心部署完k8s集群后，比如集群组件的安全漏洞、新功能的上线、组件的升级等对线上集群进行变更时，需要小心谨慎地处理。我们做到了化整为零，对单个模块去处理。避免全量地去执行ansible脚本，增加维护的难度。针对如docker、etcd、k8s、network-plugin和addons的模块化管理和运维，需提供单独的ansible脚本入口，更加精细的运维操作，覆盖到集群大部分的生命周期管理。同时kubernetes-operator的api设计的时候可以方便选择对应操作yml去执行操作。

集群部署优化操作如下：

1）k8s的组件参数管理通过ConmponentConfig提供的API去标识配置文件

2）计划切换到kubeadm部署

3）ansible使用规范

部署出来的集群，需要进行大量的场景测试和模拟，保证线上环境变更的可靠性和稳定性。

CI矩阵部分测试案例如下。

1）语法测试

2）集群部署测试

3）性能和功能测试

这里利用了GitLab、gitlab-runner、ansible和kubevirt等开源软件构建了CI流程。

详细的部署步骤如下：

①在k8s集群部署gitlab-runner，并对接GitLab仓库。

②在k8s集群部署Containerized-Data-Importer (CDI)组件，用于创建pvc的存储虚拟机的映像文件。

③在k8s集群部署kubevirt，用于创建虚拟机。

④在代码仓库编写gitlab-ci.yaml, 规划集群测试矩阵。

如上图所示，当开发人员在GitLab提交PR时会触发一系列操作。这里主要展示了创建虚拟机和集群部署。其实在我们的集群还部署了语法检查和性能测试gitlab-runner，通过这些gitlab-runner创建CI的job去执行CI流程。

具体CI流程如下：

①开发人员提交PR。

②触发CI自动进行ansible语法检查。

③执行ansible脚本去创建namespace，pvc和kubevirt的虚拟机模板，最终虚拟机在k8s上运行。这里主要用到ansible的k8s模块去管理这些资源的创建和销毁。

④调用ansible脚本去部署k8s集群。

⑤集群部署完进行功能验证和性能测试等。

⑥销毁kubevirt、pvc等资源，即删除虚拟机，释放资源。

如上图所示，当开发人员提交多个PR时，会在k8s集群中创建多个job，每个job都会执行上述的CI测试，互相不会产生影响。这种主要使用kubevirt的能力，实现了k8s on k8s的架构。

kubevirt主要能力如下：

Operator是一种用于特定应用的控制器，可以扩展 K8s API的功能，来代表k8s的用户创建、配置和管理复杂应用的实例。基于k8s的资源和控制器概念构建，又涵盖了特定领域或应用本身的知识，用于实现其所管理的应用生命周期的自动化。

总结 Operator功能如下：

1）kubernetes controller

2）部署或者管理一个应用，如数据库、etcd等

3）用户自定义的应用生命周期管理

kubernetes-operator使用很多自定义的CR资源和控制器，这里简单地介绍功能和作用。

【ClusterDeployment】：管理员配置的唯一的CR，其中MachineSet、Machine和Cluster它的子资源或者关联资源。ClusterDeployment是所有的配置参数入口，定义了如etcd、k8s、lb、集群版本、网路和addons等所有配置。

【MachineSet】：集群角色的集合包括控制节点、计算节点和etcd的配置和执行状态。

【Machine】：每台机器的具体信息，包括所属的角色、节点本身信息和执行的状态。

【Cluster】：和ClusterDeployment对应，它的status定义为subresource，减少clusterDeployment的触发压力。主要用于存储ansible执行器执行脚本的状态。

【ansible执行器】：主要包括k8s自身的job、configMap、Secret和自研的job控制器。其中job主要用来执行ansible的脚本，因为k8s的job的状态有成功和失败，这样job 控制器很好观察到ansible执行的成功或者失败，同时也可以通过job对应pod日志去查看ansible的执行详细流程。configmap主要用于存储ansible执行时依赖的inventory和变量，挂到job上。secret主要存储登陆主机的密钥，也是挂载到job上。

【扩展控制器】：主要用于扩展集群管理的功能的附加控制器，在部署kubernetes-operator我们做了定制，可以选择自己需要的扩展控制器。比如addons控制器主要负责addon插件的安装和管理。clusterinstall主要生成ansible执行器。remoteMachineSet用于多集群管理，同步元数据集群和业务集群的machine状态。还有其它的如对接公有云、dns、lb等控制器。

vivo的应用分布在数据中心的多个k8s集群上，提供了具有集中式多云管理、统一调度、高可用性、故障恢复等关键特性。主要搭建了一个元数据集群的pass平台去管理多个业务k8s集群。在众多关键组件中，其中kubernetes-operator就部署在元数据集群中，同时单独运行了machine控制器去管理物理资源。

下面举例部分场景如下：

场景一：

场景二：

1）集群管理员或者容器平台触发创建ClusterDeployment的CR，去定义当前集群的操作。

2）ClusterDeployment控制器感知到变化进入控制器。

3）开始创建machineSet和关联machine资源。

4）ClusterInstall控制器感知ClusterDeployment和Machineset的变化，开始统计machine资源，创建configmap和job，参数指定操作的ansible yml入口，执行扩缩容、升级和安装等操作。

5）调度器感知到job创建的pod资源，进行调度。

6）调度器调用k8s客户端更新pod的binding资源。

7）kubelet感知到pod的调度结果，创建pod开始执行ansible playbook。

8）job controller感知job的执行状态，更新ClusterDeployment状态。一般策略下job controller会去清理configmap和job资源。

9）NodeHealthy感知k8s的node是否为ready，并同步machine的状态。

10）addons控制器感知集群是否ready，如果为ready去执行相关的addons插件的安装和升级。

vivo大规模的K8s集群运维实践中，从底层的集群部署工具的优化，到大量的CI矩阵测试，保证了我们线上集群运维的安全和稳定性。采用了K8s托管K8s的方式来自动化管理集群（K8s as a service），operator检测当前的集群状态，判断是否与目标一致，当出现不一致时，operator会发起具体的操作流程，驱动整个集群达到目标状态。

当前vivo的应用主要分布在自建的数据中心的多个K8s集群中，随着应用的不断的增长和复杂的业务场景，需要提供跨自建机房和云的多个K8s集群去运行原云生的应用程序，就需要Kubernetes-Operator提供对接公有云基础设施、apiserver的负载均衡、网络、dns和Cloud Provider 等，同时也需要后续不断完善，降低K8s集群的运维难度。