vivo 大规模容器集群运维平台实践

作者：来自 vivo 互联网服务器团队- Zhou Qi 、Kong Manyu

容器平台已经成为支持应用运维和摆设的重要基础设施，当前 vivo 内部容器平台共有20+生产集群，管理数万物理机节点，运维管理难度不断增大。为提升运维服从和稳定性，容器团队开辟了北斗运维管理平台用于办理大规模集群运维题目。北斗容器运维管理平台包罗资源管理，集群扩缩容，巡检，事件中心，监控中心等功能。通过这些能力的构建，提升了集群的稳定性，从而提升了运维服从，节流了人力投入。
一、容器建立初期面临的挑战

vivo 容器平台已经成为支持应用运维和摆设的重要基础设施，当前vivo内部容器化平台共有20+生产集群，管理数万物理机节点，运维管理难度不断增大，容器集群运维题目重要会合在以下几个方面：

• 黑屏操作流程复杂：黑屏操作依赖工程师个人技能和经验，容器运维操作流程复杂易出错。
  
• 人工巡检耗时费力：巡检功能对于集群运维尤为重要，但人工巡检，耗时费力。
  
• 多集群管理难度大：随着业务的不断接入，集群数量不断增加，多集群的运维难度大。
  
• 自研组件管理复杂：为扩展平台能力，自研组件越来越多，对这些组件进行高效管理也成为一个难题。
  
• 历史事件查询困难：大规模容器集群会产生大量的历史事件，大量历史事件的存储和快速查询较为困难。
  

仅靠人工很难运维大规模的容器化平台，办理当前面临的题目需从白屏化和自动化入手，将黑屏操作转为白屏操作，将复杂的运维操作通过程序实现自动化，进而实现运维操作的标准化，提升整体的运维服从。
二、北斗平台办理方案

2.1 北斗平台构建目的

针对大规模容器集群运维面临的挑战，我们开始构建统一的容器集群运维管理平台，平台构建目的如下：

• 提升运维操作白屏化率: 实现运维操作白屏化率大于90%，实现高频运维操作白屏化。
  
• 实现多集群管理: 实现对不同集群的资源、设置的统一管理。
  
• 实现自动化巡检: 可根据详细运维需求制定巡检策略，实验定期巡检。
  
• 实现应用中心：实现自研组件的标准化安装，实现组件设置、组件版本的统一管理。
  
• 加强题目定位能力：提供事件查询，日志查询，监控查询能力，帮助运维研发快速定位题目。
  

基于以上的目的和需求，vivo 容器团队进行了相干能力和工具的开辟，构建了北斗运维管理平台。
2.2 北斗平台能力矩阵

以上为北斗运维平台的能力矩阵，北斗运维平台包括运营中心、机器管理、集群管理、集群运维、资源管理、基础服务几大核心模块覆盖了运维管理的各个维度。

• 运营中心：提供关键运营数据的展示，嵌入了 Grafana 的监控面板，为用户提供全方位立体化的数据监控。
  
• 机器管理：支持对集群节点的统一管理和白屏操作，支持机器的添加，机器变动记载的查询，从而便于把控机器的全生命周期。
  
• 集群管理：支持对集群的基础资源、服务组件和应用资源的统一管理，提供创建集群，纳管已有集群，节点自动化扩缩容等能力。
  
• 集群运维：支持集群巡检，Etcd 的可视化管理，Etcd 数据备份恢复，ip地址池管理，镜像管理，变动管理等能力。
  
• 资源管理：支持对集群资源和业务应用的全方位管理。
  

三、平台核心能力构建

3.1 节点扩缩容工具建立

3.1.1 题目背景

集群节点的扩容和缩容是频率较高的运维操作，人工按照文档进行黑屏操作步调繁琐，流程复杂，易出现误操作，影响集群稳定性。因此，实现集群节点扩缩容自动化成为重要办理的题目。
3.1.2 办理方案

3.1.2.1 集群扩缩容白屏化

为了办理集群扩缩容题目，我们借助了 Kubernetes 控制器模型设计了 kubeops-controller 模块，用于实现节点的自动扩缩容和集群安装。我们将所有的操作抽象为 Kubernetes 的 crd 资源 operation，operation 资源定义如下：

1. apiVersion: vcluster.caas.xxxx.com/v1alpha1
2. kind: Operation
3.         name: scaleup-2024
4.         namespace: beidou-system
5. spec:
6.         clusterName: product-cluster
7.         operationType: ScaleUp
8.         operationFlow:
9.                 - preCheck
10.                 - scaleUp
11.                 - postCheck
12.         operationMachines:
13.                 - ip: 127.0.0.1
14.                         role: Compute
15.         user: admin

复制代码

下图为扩缩容模块的架构设计图。

如架构设计图所示扩缩容组件包罗以下重要模块：

• beidou-api: 北斗平台的 API 层，用于吸收和响应外部请求。
  
• kube-apiserver: Kubernetes API 层，负责处理和响应来自集群内部和外部的所有API请求。
  
• kubeops-controller: 用于处理 operation 扩缩容操作的控制器。
  
• Job: Job 用于创建和管理一次性任务或定时任务，确保任务能够乐成完成而且不会重复运行，这里重要用于实验 Ansible 脚本。
  

用户在控制台创建扩容任务后，beidou-api 会捕捉其中的参数并调用 Kubernetes 接口创建 operation，operation 中包罗了集群标识，待扩缩容节点，操作类型等信息。kubeops-controller 控制器会监听 operation 的创建，并根据 operation 参数来实验相应的流程任务。kubeops-controller 会依据扩容或缩容参数来创建 Job，Job 则会实验 Ansible 脚本来自动完成集群安装和节点扩缩容任务，其中的 Ansible 脚本是基于 Kubespray 项目进行定制化改造而成。
1）扩容操作
扩容分为三个小步：扩容前检查，扩容，扩容后检查。通过三个步调确保能够乐成扩容集群节点，每个步调都会启动一个 Job 来实验 Ansible 脚本完成任务。

• 扩容前检查：通过 Ansible 脚本来检查磁盘空间是否够用，内核版本是否符合需求，是否残留 kubelet 和 Docker 等进程。通过扩容前检查来确保节点能够顺遂安装。
  
• 扩容：扩容节点则会实验 Ansible 脚本将节点添加到集群。
  
• 扩容后检查：节点是否处于就绪状态，网络是否连通，确保节点就绪后，会放开调度投入生产。
  

2）缩容操作
缩容操作重要分为两个步调：缩容前检查，缩容。

• 缩容前检查：必要先检查节点是否存在业务 Pod。如果存在业务 Pod，平台会提供一键迁移业务功能，避免对业务造成影响。
  
• 缩容：实验 Ansible 脚本删除节点的 kubelet，Docker 等服务，并清理残留数据，确保不影响下次的节点安装。
  

3）节点康健检查
在进行运维操作时，需随时检查集群节点的康健状态，检查流程包括网络侦测、pod 是否可正常创建等，通过这个步调可进行题目排查。节点康健检查是通过实验 Ansible 脚本来检查 kubelet、Docker、kube-proxy 服务的运行状态，检测节点的网络连通性。
3.1.2.2 扩缩容全流程自动化

扩缩容白屏化功能的构建办理了黑屏操作存在的题目，但节点的扩容操作依然涉及多个步调，即使白屏操作，也无法避免繁琐的流程。为了进一步节流人力，提升服从，实现一键扩缩容节点迫在眉睫，我们设计实现了全流程自动化功能。为了实现全流程自动化扩缩容功能，我们在 operation 的上层设计了 autooperationtask crd，autooperationtask 的定义如下:

1. apiVersion: vcluster.caas.xxxx.com/v1alpha1
2. kind: AutoOperationTask
3. metadata:
4.         name: scaleup-xxxxxx
5.         namespace: beidou-system
6. spec:
7. cluster:cluster-example
8. clusterType: native  
9. operationIds:    
10.         - scale-up  
11. operationTaskMachines:    
12.         - name: xx.xx.xx.xx    
13.         - name: xx.xx.xx.xx  
14. operationTaskStep:    
15.         - step: ScaleUpPreCheck       
16.         - step: ScaleUpWorkprocess    
17.         - step: ScaleUp    
18.         - step: UncordonNodes    
19.         - step: ScaleUpSubWorkprocess  
20. operationTaskType: ScaleUp

复制代码

如上架构图所示，全流程自动化重要包罗如下模块：

• AutoOperationTask-controller：全流程自动化控制器，会对 autooperationtask 进行处理。
  
• 网络模块: 网络模块的作用是处理网络相干的任务，如调用网络接口设置节点网络
  
• 任务处理模块：此模块的重要作用是根据需求按顺序创建operation。
  
• kubeops-controller: 任务处理控制器，会对 operation进行处理。
  

AutoOperationTask-controller会连续监听autooperationtask crd 的创建事件，任务处理模块会根据 autotask 定义的流程和步调，创建 operation（上文提到的对扩缩容等任务的抽象）。kubeops-controller 会监听 operation 的创建，并创建 Job 实验脚本。

上图是可视化的扩缩容流程，通过这种设计，我们将所有能够顺序实验的任务简化成一个自动化任务，全流程自动化将所有的操作串联起来，不仅可以节流人工操作的时间，而且支持及时追踪任务进程，观测任务状态。
3.1.3 达成结果

通过扩缩容全流程自动化的建立，我们将扩容20台机器的时间从60分钟缩短到10分钟，从原本的人工十几个步调才气完成的流程变为一键摆设，且没有出现过由于人工操作失误而引入的题目。目前，通过北斗体系实验了5000+ 的扩缩容任务，交付了上万台机器。未来团队将连续优化扩容服从，缩短康健检测时间。
3.2 集群巡检工具建立

3.2.1 题目背景

集群常会出现一些不可预料的题目，这些题目都严重影响集群的稳定性。

• 集群节点题目：cpu, 内存使用率过高，磁盘占满，内核死锁，文件体系崩溃等。这些都会导致节点 Pod 不可用，影响用户的业务。及时发现节点题目对于运维来说至关重要，尽早介入处理才可以避免更为严重的题目发生。
  
• 资源设置题目：除了节点题目外，集群设置题目，证书逾期和资源定义不规范，都大概导致集群不可用，带来严重隐患，为避免这些潜在题目影响到生产环境，巡检能力的构建变得尤为重要。
  

集群巡检必要具备如下能力：

• Kubernetes资源巡检：巡检 Kubernetes 集群的Deployment、StatefulSet 等资源设置是否符合要求。
  
• 集群节点巡检：巡检节点磁盘、内存、cpu 使用率、内核日志是否存在题目。
  
• 自定义脚本巡检：支持自定义脚本巡检。
  

3.2.2 办理方案

为办理如上题目，实现巡检目的，我们开辟了 kube-doctor 组件来对集群进行巡检。

上图为 kube-doctor 的架构设计：

• inspection crd：用于记载巡检的基本信息，包括巡检名称、巡检脚本、巡检集群、巡检时间、巡检策略等
  
• inspection-operator：inspection-operator 控制器会监听 inspection 的创建，并对其进行处理，inspection 会根据 inspection 定义的巡检时间和巡检内容，交给 cron-controller 模块处理。
  
• cron-controller: cron-controller 负责按照巡检任务 inspection 定义的巡检周期驱动 worker 定时实验任务，worker则负责详细巡检任务的实验。
  
• work-pool: worker 资源池，当有新的巡检任务需实验时，cron-controlle 会从 worker 池中获取 worker，驱动 worker 实验定时任务。
  
• 巡检驱动：为了支持不同类型和不同场景的巡检，我们设计了巡检驱动功能。巡检驱动必要实现两个标准的巡检接口 RunInspectionTask 和 StoreReport。
  

如下为 go 语言实现的 driver 接口：

1. type InspectionInterface interface {
2.         RunInspectionTask(ctx context.Context, cluster []ScheduledCluster) (error, []string, *AlertInfo)  
3.   StoreReport(result interface{}, cluster ScheduledClusteralertMessages *SyncMessages) error
4. }

复制代码

RunInspectionTask 实验详细巡检任务，例如到指定节点实验脚本，并获取结果。StoreReport 的作用则是存储巡检报告，存储巡检报告支持将数据存储到 MySQL 大概 Elasticsearch。目前定义了自定义脚本，数据指标和节点指标三种 driver。

• 自定义脚本: 用户可以自定义的脚本，到指定的集群节点实验，并获取到实验结果。
  
• 数据指标：数据指标来自于监控模块 promethuse。
  
• 节点指标：获取 node-problem-detector（用于发现节点题目的开源组件） 的实验数据。
  

3.2.3 达成结果

目前 kube-doctor 已经实验了数千次的巡检任务，生成数千份巡检报告，帮助运维及时发现容器集群题目。
3.3 应用中心建立

3.3.1 题目背景

随着业务的发展，集群内自研组件的增多使得对组件的管理变得复杂，基于此题目我们需着手构建应用中心能力，对组件进行统一管理。应用中心必要具备如下能力：

• 应用模版管理：支持上传 Chart 包到 vivo 对象存储，可发布到应用中心，发布乐成后支持对 Chart 模版进行更新，按照版本管理。
  
• 应用摆设管理：支持将应用直接摆设到不同的集群和 Namespace，摆设过程中可监听修改参数。常用参数支持设置在 values.yml 文件中直接编辑修改，无需重新打 Chart 包，使摆设流程更方便高效。
  
• 应用实例管理：支持查察应用在哪些集群摆设了哪些实例，点击应用实例可以跳转到实例详情，查察实例的设置等相干信息，进行相应的设置修改和升级。
  

3.3.2 办理方案

为办理如上题目，我们开辟了应用中心功能，将集群中各类组件和服务托管到北斗平台进行统一管理。通过 Kubernetes 提供的应用安装管理组件 Helm 实验应用的安装、摆设、升级及设置修改等，方便在不同集群中分发和摆设应用，支持服务的全生命周期管理。下图为应用中心的架构设计：

3.3.2.1 模板管理

为管理应用模板，我们定义了 helmapp CRD和helmappversion CRD。用户可以上传 chart 包，前端将分析其内容并传递给 beidou-api，以创建 helmapp CRD 并存储到 vivo 对象存储体系，同时会创建一个 helmappversion CRD，用于记载版本和存储地址，以便进行安装操作。

• helmapp crd: 用于记载 chart 包的基本信息，如应用名称、应用描述、应用 log 等信息。
  
• helmappversion crd: 用于记载 chart 包的版本信息和存储地址，便于安装包的获取。
  

3.3.2.2 实例管理

应用安装包安装到集群后会生成一个运行中的应用，也就是一个应用实例，对此我们设计了 release crd 用于表示一个应用实例，通过调用 beidou-api 接口创建 release（实例），控制器监听到创建事件后从 crd 中获取必要安装的chart包名称和版本，并从 vivo 对象存储体系中获取 chart 包，从 values 中读取相干参数，末了获取 cluster crd 中的 kubeconfig 数据，通过这种方式就能够将应用安装到不同集群中。

• release crd：存储应用实例信息，包括 chart 包名称、版本等信息
  
• beidou-release-controller：监听 release 创建事件，并对 release 进行处理。
  
• values: release spec 中定义的应用设置参数。
  

3.3.3 达成结果

目前通过应用中心管理的应用达到了50+，管理的应用实例达到200+，实现了降低组件管理复杂度，提升管理服从，且与AI和数据部分合作用于复杂应用的摆设和管理。
3.4 事件采集和监控体系构建

3.4.1 题目背景

在 Kubernetes 中，事件（Events）是集群在特定对象上发生的特定时间点上的状态变革记载。事件涵盖有关 Pod 的调度决策、Container 的状态变革、节点的压力环境等重要信息。事件可帮助开辟工程师和集群运维工程师明白集群内部发生的事件。通过 Kubernetes 中的事件，可快速发现和定位题目。但当前集群的事件都存储于 Etcd，事件查察较为贫苦，由于 Etcd 空间限制，无法恒久存储事件，这些题目为追溯历史题目造成困难。
3.4.2 办理方案

针对此题目，平台开辟了事件采集存储组件 beidou-event，上图 beidou-event 架构图。

• beidou-event: beidou-event模块会及时监听kube-apiserver 的事件，并将事件按照一定的格式输出到主机的某一个目录。
  
• vivo 日志体系：vivo 日志体系由 vivo 开辟用于专门的日志采集和存储的体系，这里也可以使用ELK等日志采集方案。
  
• Elasticsearch: vivo 日志体系采集完数据后会将数据存储到Elasticsearch。
  
• Beidou-api: beidou-api 会调用 Elasticsearch 获取事件数据并在前端作展示。
  

3.4.3 达成结果

当前 Elasticsearch 保持在30亿+的事件数量，历史事件的查询帮助运维和研发快速定位历史题目，在题目追溯上发挥了重要作用。
四、总结与展望

经过几年的能力建立，我们基本实现了北斗平台构建目的。

• 90%以上高频操作实现白屏化：北斗运维平台已经将90%的黑屏运维操作实现白屏化。各种高频率文件设置，资源设置，资源调解，题目定位都可以通过北斗运维管理平台进行。操作人，操作内容皆可通过审计功能进行追溯。
  
• 集群安装和扩缩容工具大幅提效：通过北斗平台安装数个k8s集群，扩容了上万台机器。标准化的程序实验规避了由于人为操作导致的失误，保证了集群的稳定性和可靠性。通过白屏化简化了操作流程，扩容由原本的人工实验十几个步调，实现了一键扩缩容，缩减了扩缩容时间，提升了运维的服从。
  
• 运营中心实现全方位运营监控：通过运营中心的资源概览和监控功能可帮助及时掌握集群数量，集群规模，资源填充率，集群资源使用环境等关键指标，便于对资源进行治理，避免由于资源题目影响业务。
  
• 巡检能力助力题目及时发现办理：集群巡检功能自投入使用已经生成了3000+份的巡检报告，详细记载了巡检过程中发现的不符合规范和巡检规则的风险项。通过巡检功能及时发现集群存在的不稳定因素，帮助运维同事及时排除题目。
  
• 事件采集助力集群题目排查：事件采集和查询功能在题目定位过程发挥重要作用，为题目的办理提供重要线索。同时，事件中心归纳了核心且关键的事件指标，便于掌控集群的运行状况。
  
• 应用中心标准化组件安装：应用中心功能管理所有的自研组件，组件的安装、升级和设置修改变得更加便利。同时，此功能开放给高级用户用于复杂应用的摆设。
  

北斗容器自动化运维平台的构建进一步解放了人力，提升了运维服从，支持了上万台机器数十个容器集群的运维。容器运维平台未来会向智能化自动化方向发展，实现平台自动侦测题目，办理题目，结合人工智能技能，提供更加智能的运维平台，进一步提升运维服从和集群稳定性。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。