前言
首先什么是TiDB呢？TiDB就是一个分布式的关系型数据库，采用了存储和计算分离的架构。那什么又是Cloud TiDB呢？Cloud TiDB就是运行在Kubernetes&Docker上的TiDB。那为什么要把TiDB运行在上Kubernetes&Docker呢？因为这样可以非常方便地基于Kubernetes完成数据库自动化管理，使TiDB的快速部署和高效运维成为现实。
01
简介
先简单介绍下kubernetes和docker。Docker大家应该都已经很熟悉了，我行许多应用已经实现了容器化。docker就是容器的一种，是一种轻量级的虚拟化技术，Linux上的容器是基于内核提供的cgroup和namespace技术实现的。Kubernetes是Google开源的一个容器编排引擎，通过Kubernetes我们可以轻松实现对docker 等容器的高效部署和管理。
Cloud TiDB的核心目标是解决如何在大规模集群中更有效地管理多套TiDB数据库实例，以提高集群资源利用率的问题。核心功能包括：
一键建库
资源隔离
自动化运维
故障自治愈
跨地域高可用
这些核心功能的实现都离不开Cloud TiDB的核心：TiDB operator，它解决了有状态的分布式数据库服务与k8s适配的关键问题。下面我们详细的介绍一下TiDB operator：
云计算大势所趋，也是我行“ABCD”发展战略中的重要一环。在云原生时代，以 Kubernetes 为代表的编排系统能够充分利用云上的可编程基础设施，实现无状态应用的弹性伸缩与自动故障转移。那么类似数据库这种有状态的应用该如何跟上大趋势呢？Operator 模式应运而生，Operator 的灵感很简单，Kubernetes 自身是用 Deployment、DaemonSet 等 API 对象来记录用户的意图，并通过 control loop控制集群状态向目标状态收敛，那么我们当然也可以定义自己的API对象，记录自身领域中的特定意图，并通过自定义的control loop完成状态收敛。
在Kubernetes中，添加自定义API对象的最简单方式就是 CustomResourceDefinition（CRD），而添加自定义 control loop 的最简单方式则是部署一个自定义控制器。自定义控制器 + CRD 就是 Operator。具体到 TiDB 上，用户可以向 Kubernetes 提交一个 TidbCluster 对象来描述 TiDB 集群定义，假设我们这里描述说“集群有3个PD节点、3个TiDB节点和3个TiKV节点”，这是我们的意图。而TiDB Operator中的自定义控制器则会进行一系列的 Kubernetes 集群操作，比如分别创建3个TiKV、TiDB、PD Pod，来让真实的集群符合我们的意图。
具体来说，用户只需要描述集群规格，TiDB Operator就会不断调整 Kubernetes 中的资源，驱动实际集群满足该描述。在这种模式下，TiDB集群会自动完成服务的健康检查、故障转移，而部署、升级、扩缩容等操作则能通过修改集群的规格定义“一键”完成，极大简化了TiDB集群的运维管理。TiDB Operator的工作原理可以概括为下图：
02
效果
首先我们来看看一键建库：这里的前提是要先在物理机上部署完成k8s集群和TiDB operator。Helm 是一个 Kubernetes 的包管理工具，它类似于 CentOS 的 YUM 包管理，Ubuntu 的 APT 包管理。它能够把创建一个应用所需的所有 Kubernetes API 对象声明文件组合并打包在一起。并提供了仓库的机制便于分发共享，还支持模版变量替换，同时还有版本的概念，使之能够对一个应用进行版本的管理。由于TiDB集群有很多组件，这就需要很多docker镜像，而这些镜像在公司内网又下载不到怎么办？我们可以先在外网环境下载好需要用到的docker镜像，然后上传到公司内网服务器。但是集群这么多机器，一台台上传麻烦、浪费时间还占用空间。我们可以先在内网搭建一个 Harbor 镜像仓库，只需要将docker镜像上传一次至harbor镜像仓库，每次创建集群需要用到镜像时，设置镜像库为harbor就能自动拉取了。
这些前置条件都准备好之后，我们只需要在配置文件中设置好集群的节点信息和资源分配，执行一下helm install命令就能一键完成一个TiDB集群的部署了。等所有组件的pod状态都变成Running代表着大功告成，我们就能访问TiDB数据库了。部署一个TiDB集群的时间从原来的1天，减少为10分钟甚至更少！
基于Docker的硬件隔离，限制每个集群的可使用资源，例如CPU、内存等，我们可以实现TiDB数据库比较完美的多租户架构。目前我们的测试环境共有22套Cloud TiDB集群在一个k8s集群上运行：
故障自动转移是指在 TiDB 集群的某些节点出现故障时，TiDB Operator 会自动添加一个节点，保证 TiDB 集群的高可用，类似于 K8s 的 Deployment 行为。
举一个生产上经常遇到的例子，tikv节点所在机器故障，需要进行节点替换，传统的流程是这样的：1、将leader从故障节点迁移走。2、将故障节点剔除出集群。3、将TiKV部署到新增节点。4、启动新节点上的TiKV服务。5、更新监控信息并重启。这些步骤繁琐而耗时，而使用Cloud TiDB后完全不需要人工干预，得益于TiDB operator事先编配好的任务，在监控到有节点故障后会自动完成以上的步骤。
03
测试
针对Cloud TiDB的高可用性，我们在测试环境进行了故障模拟测试，主要是模拟生产上常见的机器故障对Cloud TiDB的影响。使用脚本向一个Cloud TiDB数据库循环插入数据，比较故障发生前后的耗时变化情况。针对pd-server，如果是主节点故障，集群保持可用，虽然耗时会增加，如果是从节点故障，耗时不变。针对TiDB-server，如果正好是当前session连接的TiDB-server故障，应用报错，重启后恢复。如果不是当前session连接的TiDB-server，无影响。对于TiKV-server，故障发生后集群保持可用，耗时增加。
故障时间如果超过一定的时限（具体时长可配置），TiDB operator会根据事先编排好的任务，自动增加pod，并剔除故障节点，保持整个Cloud TiDB集群的高可用。
总结
以上是对Cloud TiDB的简单介绍，不难看出，相比传统的TiDB，Cloud TiDB在TiDBoperator的作用下借助了k8s强大的任务编排功能以及docker的资源隔离功能，极大的简化了运维操作，实现了小集群多租户架构。
