首先要说的当然是我们为什么要做 TiDB Operator，这得从 TiDB 本身的架构开始说起。下面是 TiDB 的架构图：
其中，TiKV 是一套分布式的 Key-Value 存储引擎，它是整个数据库的存储层，在 TiKV 中，数据被分为一个个 Region，而一个 Region 就对应一个 Raft Group，使用 Raft 协议做 Log Replication 来保证数据的强一致性。那么自然容易想到，我们只要水平增加 TiKV 节点数，再把数据切成更多的 Region 均匀分布在这些节点上，就能实现存储层的水平扩展。
TiDB 则是计算执行层，负责 SQL 的解析和查询计划优化，真正执行 SQL 时则通过 TiKV 提供的 API 来访问数据。
最后是 PD，PD 是集群的“大脑”，它一方面是是集群的 metadata server，TiKV 中的数据分布情况都会通过心跳上报给 PD 存储起来；另一方面又承担集群数据调度的任务，我们前面说 TiKV 要把数据拆成更多的 Region 均匀分布到节点上，什么时候拆、怎么拆、拆完分配到哪些节点上这些事情就都是 PD 通过调度算法来决定的。从直观上，PD 其实有点像 Kubernetes 里的 Control Plane。
这么一套架构的优势是分层清晰，指责明确，每一层都可以独立地做功能扩展和规模上的水平伸缩。但是这对于运维管理来说，是一个巨大的挑战，再加上 TiDB 本身的一些比较复杂的分布式共识算法和事务算法，可以说是把整个 TiDB 的运维入门门槛拉得相当高。另一方面，传统的基于虚拟机的部署方式也不能很好地发挥 TiDB 水平伸缩和故障自动转移的潜力。所以其实我们在内部很早就在尝试使用 Kubernetes 来编排管理 TiDB 集群，甚至在这个开源的 TiDB Operator 之前，我们还有一版废弃掉的 TiDB Operator。最后的事实也确实证明我们一直依赖的选择和投入是正确的，相信大家听了后面的分析，也会认同这一点。
接下来我们正式进入 TiDB Operator 的解读。其实 Operator 模式在 Kubernetes 社区已经不新鲜了，现在大部分流行的有状态应用都有自己的 Operator。但回顾一下 Operator 的一些概念仍然非常必要。
我们知道 Kubernetes 里两个很重要的概念就是声明式 API 和控制循环。所有的 API 对象都是对用户意图的记录，再由控制器去 watch 这些意图，对比实际状态，执行调谐（reconcile）操作来驱动集群达成用户意图。Kubernetes 本身有很多的内置 API 对象，比如 ReplicaSet 表达我们需要一个应用有几个实例，DaemonSet 表达我们希望在部分被选中的节点上每个节点运行且只运行一个实例。那我们该怎么向 Kubernetes 表达 “我需要一个 TiDB 集群呢“？答案就是定义一个用于描述 TiDB 集群的对象，在 Kubernetes 中，目前有两种方式可以定义一个新对象，一是 CustomResourceDefinition（CRD）、二是 Aggregation ApiServer（AA），其中 CRD 是相对简单也是目前应用比较广的方法。TiDB Operator 就用 CRD 定义了一个 “TidbCluster” 对象。
有了对象还没完，这个对象现在谁都还不认识它呢。这时候就是自定义控制器出场的时候了，我们的自定义控制器叫 tidb-controller-manager，它会 watch TidbCluster 对象和其它一些相关对象，并且按照我们编写的逻辑做调谐来驱动真实的 TiDB 集群向我们定义的终态转移。
CRD 加上控制器就是典型的 Operator 模式了。当然这还没完，很多逻辑控制器也是无能为力的，比如 Pod 的调度逻辑。这一块为了实现 TiDB 容器的自定义调度策略，我们编写了 Scheduler Extender。还有一些验证逻辑，比如某些特殊情况下，我们要阻止集群的变更，这样的逻辑就用 Admission Webhook 来实现。而在用户侧，我们则开发了 kubectl plugin 来做 TiDB 的一些特定操作。所以大家就可以知道，TiDB Operator 其实不止于 Operator，我们的核心理念是利用 Kubernetes 大量的扩展点，为 Kubernetes 全面注入 TiDB 的领域知识，把 Kubernetes 打造成 TiDB 的一个最佳底座。
这样做有两大好处（划重点）：
最低0.47元/天 解锁文章
5905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
