tidb-in-action
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 架构
1.2.1.4 TiDB Operator 组件
- TiDB Cluster 定义：CRD（
CustomResourceDefinition）定义了TidbCluster等自定义资源，使得 Kubernetes 世界认识 TiDB Cluster 并让其与Deployment、StatefulSet一同享受 Kubernetes 的头等公民待遇。目前 TiDB Operator v1.1.0 版本包含的 CRD 有：TidbCluster、Backup、Restore、BackupSchedule、TidbMonitor、TidbInitializer以及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-manager：TidbCluster等 CR 封装了StatefulSet、Deployment、CronJob等原生对象，所以依然需要 K8s 原生控制器来进行控制逻辑。 -
kube-scheduler：调度 TiDB Cluster 的 Pod，filtering阶段，kube-scheduler 筛选出的节点会再经过tidb-scheduler筛选一次，然后 kube-scheduler 再进行scoring选择最合适的节点进行 Pod 调度。
举个栗子（脑洞）：
小明买了辆家用车，去修车厂改造成变形金刚。
这辆家用车类似 Deployment、StatefulSet 这类原厂的标准化组件。改造成独一无二的变形金刚需要设计图纸（CRD）。同时原来车上的零件需要实现新的功能（自定义控制器），轮子不仅能转还可以当关节，后备箱不仅能装东西还可以变成脚。修车厂（K8s 控制平面）根据设计图纸和控制逻辑真的造出了一个变形金刚（CR）。这个变形金刚可以根据环境的不同而改变形态（调度器），甚至还可以在战斗损坏后进行修复（调和）。
1.2.1.7 原理浅析
TiDB Operator 中使用 Helm Chart 封装了 TiDB 集群定义。整体的控制流程如下：
- 用户通过 Helm 创建
TidbCluster对象和相应的一系列 Kubernetes 原生对象，比如执行定时备份的CronJob； - TiDB Operator 会通过 Kubernetes API Server watch
TidbCluster以及其它相关对象，基于集群的实际状态不断调整 PD、TiKV、TiDB 的StatefulSet和Service对象； - Kubernetes 的原生控制器根据
StatefulSet、Deployment、CronJob等对象创建更新或删除对应的Pod； - PD、TiKV、TiDB 的
Pod声明中会指定使用tidb-scheduler调度器，tidb-scheduler会在调度对应Pod时应用 TiDB 的特定调度逻辑。
基于上述的声明式控制流程，TiDB Operator 能够自动进行集群节点健康检查和故障恢复。部署、升级、扩缩容等操作也可以通过修改 TidbCluster 对象声明“一键”完成。