1.2.1 TiDB Operator 简介及原理

—— 化繁为简的艺术

1.2.1.1 背景

小时候,想象着 2020 年机器人早就普及了,机器人管家叫我起床,机器人厨师端上早餐,机器人司机开车送我去上班,路上还有机器人交警,到了公司是机器人姐姐接待,下班去看的是机器人牙医而且一点也不疼。

“快醒醒,客户爸爸问你 TiDB 集群怎么还没搞好?”

“天啊,为什么都 2020 年了还要人手动去维护分布式集群?为什么这群人要把 TiDB 设计成这么多组件?为什么 TiDB 集群半夜挂了不派个机器人去修复?”

“兄 dei,K8s 了解一下?“

1.2.1.2 简介

TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统,提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator,TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。

​ ——来自 PingCAP 官方定义

TiDB Operator 像“牧羊人”一样,持续的监督并管理着 TiDB 各组件“羊群”以恰当的状态运行在主机集群“牧场”上。现在运维人员只要告诉 Operator “What to do“,而由 Operator 来决定 “How to do”。在最新版本 TiDB Operator 甚至可以根据实际情况来决定 “What to do”,比如:auto-scaler。真正实现了自动化运维,减轻运维人员维护压力,提高服务能力。

1.2.1.3 TiDB Operator 架构

TiDB Operator 架构

1.2.1.4 TiDB Operator 组件

  • TiDB Cluster 定义:CRD(CustomResourceDefinition)定义了 TidbCluster 等自定义资源,使得 Kubernetes 世界认识 TiDB Cluster 并让其与 DeploymentStatefulSet 一同享受 Kubernetes 的头等公民待遇。目前 TiDB Operator v1.1.0 版本包含的 CRD 有:TidbClusterBackupRestoreBackupScheduleTidbMonitorTidbInitializer 以及 TidbClusterAutoScaler
  • 控制器:tidb-controller-manager 包含了一组自定义控制器,控制器通过循环不断比对被控制对象的期望状态与实际状态,并通过自定义的逻辑驱动被控制对象达到期望状态。
  • 调度器:tidb-scheduler 是一个 Kubernetes 调度器扩展,它为 Kubernetes 调度器注入 TiDB 集群特有的调度逻辑,比如:为保证高可用,任一 Node 不能调度超过 TiDB 集群半数以上的 TiKV 实例。

1.2.1.5 自定义资源

  • TiDB Cluster 资源:CR(CustomResource)声明了 TiDB Cluster 自定义资源对象,它声明了 TidbCluster 对象的期望状态,并被控制器逻辑不断进行处理,同时将实际运行状态记录下来。

1.2.1.6 Kubernetes 控制平面

  • kube-apiserver:Kubernetes 控制平面的前端,所有组件通过 API Server 获取或更新对象信息。

  • kube-controller-managerTidbCluster 等 CR 封装了 StatefulSetDeploymentCronJob 等原生对象,所以依然需要 K8s 原生控制器来进行控制逻辑。

  • kube-scheduler:调度 TiDB Cluster 的 Pod,filtering 阶段,kube-scheduler 筛选出的节点会再经过 tidb-scheduler 筛选一次,然后 kube-scheduler 再进行 scoring 选择最合适的节点进行 Pod 调度。

举个栗子(脑洞):

小明买了辆家用车,去修车厂改造成变形金刚。

这辆家用车类似 DeploymentStatefulSet 这类原厂的标准化组件。改造成独一无二的变形金刚需要设计图纸(CRD)。同时原来车上的零件需要实现新的功能(自定义控制器),轮子不仅能转还可以当关节,后备箱不仅能装东西还可以变成脚。修车厂(K8s 控制平面)根据设计图纸和控制逻辑真的造出了一个变形金刚(CR)。这个变形金刚可以根据环境的不同而改变形态(调度器),甚至还可以在战斗损坏后进行修复(调和)。

1.2.1.7 原理浅析

TiDB-Operator-control-flow

TiDB Operator 中使用 Helm Chart 封装了 TiDB 集群定义。整体的控制流程如下:

  1. 用户通过 Helm 创建 TidbCluster 对象和相应的一系列 Kubernetes 原生对象,比如执行定时备份的 CronJob
  2. TiDB Operator 会通过 Kubernetes API Server watch TidbCluster 以及其它相关对象,基于集群的实际状态不断调整 PD、TiKV、TiDB 的 StatefulSetService 对象;
  3. Kubernetes 的原生控制器根据 StatefulSetDeploymentCronJob 等对象创建更新或删除对应的 Pod
  4. PD、TiKV、TiDB 的 Pod 声明中会指定使用 tidb-scheduler 调度器,tidb-scheduler 会在调度对应 Pod 时应用 TiDB 的特定调度逻辑。

基于上述的声明式控制流程,TiDB Operator 能够自动进行集群节点健康检查和故障恢复。部署、升级、扩缩容等操作也可以通过修改 TidbCluster 对象声明“一键”完成。