乐趣区

关于kubernetes:vivo大规模-Kubernetes-集群自动化运维实践

jiezi

作者：vivo 互联网服务器团队 -Zhang Rong

一、背景

随着 vivo 业务迁徙到 K8s 的增长，咱们须要将 K8s 部署到多个数据中心。如何高效、牢靠的在数据中心治理多个大规模的 K8s 集群是咱们面临的要害挑战。kubernetes 的节点须要对 OS、Docker、etcd、K8s、CNI 和网络插件的装置和配置，保护这些依赖关系繁琐又容易出错。

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

  • 须要人工黑屏化集群运维操作，存在操作失误和集群配置差别。
  • 部署脚本工具没有具体的版本控制，不利于集群的降级和配置变更。
  • 部署脚本上线须要破费大量的工夫验证，没有具体的测试用例和 CI 验证。
  • ansible 工作没有拆分为模块化装置，应该化整为零。具体到 K8s、etcd、addons 的等角色的模块化治理，能够独自执行 ansible 工作。
  • 次要是通过二进制部署，须要本人保护一套集群管理体系。部署流程繁琐，效率较低。
  • 组件的参数治理比拟凌乱，通过命令行指定参数。K8s 的组件最多有 100 以上的参数配置。每个大版本的迭代都在变动。

本文将分享咱们开发的 Kubernetes-Operator，采纳 K8s 的申明式 API 设计，能够让集群管理员和 Kubernetes-Operator 的 CR 资源进行交互，以简化、升高工作风险性。只须要一个集群管理员就能够保护成千上万个 K8s 节点。

二、集群部署实际

2.1 集群部署介绍

次要基于 ansible 定义的 OS、Docker、etcd、k8s 和 addons 等集群部署工作。

次要流程如下：

  1. Bootstrap OS
  2. Preinstall step
  3. Install Docker
  4. Install etcd
  5. Install Kubernetes Master
  6. Install Kubernetes node
  7. Configure network plugin
  8. Install Addons
  9. Postinstall setup

下面看到是集群一键部署要害流程。当在多个数据中心部署完 K8s 集群后，比方集群组件的安全漏洞、新性能的上线、组件的降级等对线上集群进行变更时，须要小心谨慎的去解决。咱们做到了化整为零，对单个模块去解决。防止全量的去执行 ansible 脚本，减少保护的难度。针对如 Docker、etcd、K8s、network-plugin 和 addons 的模块化治理和运维，需提供独自的 ansible 脚本入口，更加精密的运维操作，笼罩到集群大部分的生命周期治理。同时 kubernetes-operator 的 api 设计的时候能够不便抉择对应操作 yml 去执行操作。

集群部署优化操作如下：

（1）K8s 的组件参数治理通过 ConmponentConfig[1]提供的 API 去标识配置文件。

  • 【可维护性】当组件参数超过 50 个以上时配置变得难以治理。
  • 【可降级性】对于降级，版本化配置的参数更容易治理。因为社区一个大版本的参数没有变动。
  • 【可编程性】能够对组件（JSON/YAML）对象的模板进行修补。如果你启用动静 kubelet 配置选项，批改参数会主动失效，不须要重启服务。
  • 【可配置性】许多类型的配置不能示意为 key-value 模式。

（2）打算切换到 kubeadm 部署

  • 应用 kubeadm 对 K8s 集群的生命周期治理，缩小本身保护集群的老本。
  • 应用 kubeadm 的证书治理，如证书上传到 secret 里缩小证书在主机拷贝的工夫耗费和从新生成证书性能等。
  • 应用 kubeadm 的 kubeconfig 生成 admin kubeconfig 文件。
  • kubeadm 其它性能如 image 治理、配置核心 upload-config、主动给管制节点打标签和污点等。
  • 装置 coredns 和 kube-proxy addons。

（3）ansible 应用标准

  • 应用 ansible 自带模块解决部署逻辑。
  • 防止应用 hostvars。
  • 防止应用 delegate_to。
  • 启用–limit 模式。
  • 等等。

2.2 CI 矩阵测试

部署进去的集群，须要进行大量的场景测试和模仿。保障线上环境变更的可靠性和稳定性。

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

（1）语法测试：

  • ansible-lint
  • shellcheck
  • yamllint
  • syntax-check
  • pep8

（2）集群部署测试：

  • 部署集群
  • 扩缩容管制节点、计算节点、etcd
  • 降级集群
  • etcd、Docker、K8s 和 addons 参数变更等

（3）性能和功能测试：

  • 查看 kube-apiserver 是否失常工作
  • 查看节点之间网络是否失常
  • 查看计算节点是否失常
  • K8s e2e 测试
  • K8s conformance 测试
  • 其余测试

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

具体的部署步骤如下：

  1. 在 K8s 集群部署 gitlab-runner，并对接 GitLab 仓库。
  2. 在 K8s 集群部署 Containerized-Data-Importer (CDI)[4]组件，用于创立 pvc 的存储虚拟机的映像文件。
  3. 在 K8s 集群部署 kubevirt，用于创立虚拟机。
  4. 在代码仓库编写 gitlab-ci.yaml[5], 布局集群测试矩阵。

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

具体 CI 流程如下：

  1. 开发人员提交 PR。
  2. 触发 CI 主动进行 ansible 语法查看。
  3. 执行 ansible 脚本去创立 namespace，pvc 和 kubevirt 的虚拟机模板，最终虚拟机在 K8s 上运行。这里次要用到 ansible 的 K8s 模块 [6] 去治理这些资源的创立和销毁。
  4. 调用 ansible 脚本去部署 K8s 集群。
  5. 集群部署完进行性能验证和性能测试等。
  6. 销毁 kubevirt、pvc 等资源。即删除虚拟机，开释资源。

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

kubevirt 次要能力如下：

  • 提供规范的 K8s API，通过 ansible 的 K8s 模块就能够治理这些资源的生命周期。
  • 复用了 K8s 的调度能力，对资源进行了管控。
  • 复用了 K8s 的网络能力，以 namespace 隔离，每个集群网络相互不影响。

三、Kubernetes-Operator 实际

3.1 Operator 介绍

Operator 是一种用于特定利用的控制器，能够扩大 K8s API 的性能，来代表 K8s 的用户创立、配置和治理简单利用的实例。基于 K8s 的资源和控制器概念构建，又涵盖了特定畛域或利用自身的常识。用于实现其所治理的利用生命周期的自动化。

总结 Operator 性能如下：

  1. kubernetes controller
  2. 部署或者治理一个利用，如数据库、etcd 等
  3. 用户自定义的利用生命周期治理
  • 部署
  • 降级
  • 扩缩容
  • 备份
  • 自我修复
  • 等等

3.2 Kubernetes-Operator CR 介绍

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 等控制器。

3.3 Kubernetes-Operator 架构

vivo 的利用散布在数据中心的多个 K8s 集群上，提供了具备集中式多云治理、对立调度、高可用性、故障复原等要害个性。次要搭建了一个元数据集群的 pass 平台去治理多个业务 K8s 集群。在泛滥要害组件中，其中 kubernetes-operator 就部署在元数据集群中，同时独自运行了 machine 控制器去治理物理资源。

上面举例局部场景如下：

场景一：

当大量利用迁徙到 kubernets 上，管理员评估须要扩容集群。首先须要审批物理资源并通过 pass 平台生成对应 machine 的 CR 资源，此时的物理机处于备机池里，machine CR 的状态为闲暇状态。当管理员创立 ClusterDeploment 时所属的 MachineSet 会去关联闲暇状态的 machine，拿到闲暇的 machine 资源，咱们就能够观测到以后须要操作机器的 IP 地址生成对应的 inventory 和变量，并创立 configmap 并挂载给 job。执行扩容的 ansible 脚本，如果 job 胜利执行完会去更新 machine 的状态为 deployed。同时跨集群同步 node 的控制器会查看以后的扩容的 node 是否为 ready，如果为 ready，会更新以后的 machine 为 Ready 状态，才实现整个扩容流程。

场景二：

当其中一个业务集群呈现故障，无奈提供服务，触发故障复原流程，走对立资源调度。同时业务的策略是调配在多个业务集群，同时配置了一个备用集群，并没有在备用集群上调配实例，备用集群并不理论存在。

有如下 2 种状况：

  1. 其它的业务集群能够承载故障集群的业务，kubernetes-operator 不须要执行任何操作。
  2. 如果其余业务集群不能承载故障集群的业务。容器平台开始预估资源，调用 kubernetes-operator 创立集群，即创立 clusterDeployment 从备机池里抉择物理机器，观测到以后须要操作机器的 IP 地址生成对应的 inventory 和变量，创立 configmap 并挂载给 job。执行集群装置的 ansible 脚本, 集群失常部署实现后开始业务的迁徙。

3.4 Kubernetes-Operator 执行流程

  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 集群的运维难度。

退出移动版