TiDB on Kubernetes 最佳实践

做者介绍：吴叶磊 PingCAP Cloud 工程师。

随着 Kubernetes（K8s） 的全面成熟，愈来愈多的组织开始大规模地基于 K8s 构建基础设施层。然而，考虑到数据库在架构中的核心地位与 K8s 在有状态应用编排上的短板，仍有很多组织认为在 K8s 上运行核心数据库会带来颇高的风险。事实上，在 K8s 上运行 TiDB 不只能实现企业技术栈的统一，下降维护成本，还能带来更高的可用性与安全性。本次分享将介绍 TiDB 在 K8s 上的运维管理系统 TiDB Operator，再从各种故障场景入手剖析 TiDB on K8s 如何实现高效的故障自愈并保障数据安全。最后，咱们会分享来自国内外一线公司的 TiDB Operator 生产环境案例，并总结出一套 TiDB on K8s 最佳实践。

要不要在 Kubernetes 上运行 TiDB ？

这个问题其实一直以来也有不少的争议。你们都知道，Kubernetes 的不少概念是为无状态应用（好比微服务）所设计的。因为云原生技术的不断普及，Kubernetes 目前在国内外的不少技术领域都获得大规模的落地，有一种全盘上 Kubernetes 的趋势。但在这期间也有很多人提出了质疑，好比：是否是全部的业务场景都适合 Kubernetes ？咱们的组织是否是真的须要 Kubernetes？这样的争议，其实这背后的各类声音都有各自的出发点。

首先 Kubernetes 有没有价值？确定有价值，它的普及度就是很好的证实。那 Kubernetes 有没有问题？固然也有问题，好比， Kubernetes 会增上技术上的复杂度，此外它还有有比较大的迁移成本。

回到 TiDB 要不要在 Kubernetes 上面运行这个问题。答案其实每每来自于你当前的技术栈和技术团队。

举个例子，假如你的大部分应用已经上了 Kubernetes，并且你的工程师也对 Kubernetes 很熟悉，在 Kubernetes 上去作一些业务，他感受很是舒服，那么 TiDB 就不应成为一个例外。换句话说，若是当前整个组织的业务都已经上 Kubernetes 了，但还须要专门招一个运维团队在虚拟机上运维 TiDB 的话，不只会增长额外的维护成本，也没办法发挥出技术栈投资的规模优点。

那么，在 K8s 运行 TiDB，咱们想要什么呢？一般，咱们想要的是 TiDB 能够和咱们在 K8s 上运行的微服务同样，能够作到声明式管理，经过 K8s 实现 TiDB 的自动化运维以及弹性资源配置。我想扩容的时候，并不须要去专门开新的物理机，专门购买一批机器，而是直接从整个的 K8s 资源池中，弹性的给 TiDB 分配一些资源进行扩容，而后再缩容以后又把这些资源还回去。

但是，如今的状况是，即便不少公司已经上了 K8s，但对于把数据库放在 K8s 上运行仍是有必定的担心，这个担心主要在哪儿呢？

从我我的了解到的信息来讲，核心是稳定性，稳定性，最后仍是稳定性，由于毕竟咱们要上的是数据库。几年前，你们刚开始上 K8s 的时候，会以为个人业务上在 K8s 上用的很爽，那要不要把数据库也搞上去？那总会有一种声音是，数据库怎么能上 K8s 呢？咱们数据库的稳定性要求比 K8s 还要高啊！假如 K8s 挂了，那可能只是线上的微服务没法提供服务，可是假如数据库挂了，咱们不只没法提供服务，还有可能面临数据丢失的风险。因此一般来讲，在组织中，数据库可靠性是处于一个核心地位的，也所以在数据库上 K8s 时，一个核心的担心就是可靠性。

那么，咱们在部署传统数据库应用的时候，是怎么保证稳定性的？通常来讲，是开几台固定的物理机，而后咱们会把数据库的 Binary 传上去运行起来，这时候要点就是，运行起来以后只要不出问题就不要再动它（If it works don't touch it）。即便要动它，也须要通过一个很是严苛的审计流程和预演，保证它最佳的稳定性。听起来，对于传统的关系型数据库而言，高度动态化的 K8s 环境并非一个很好的解决方案。

那为何还会推荐你们把 TiDB 放在 K8S 上运行呢？

第一点，TiDB 自己可以适应动态化的 K8S 环境。

• TiDB 能够多副本作容错，当挂掉一个集群当中的小数节点并不会对整个集群的运行产生影响；
• TiDB 可以很好的借助 K8s 环境作水平伸缩；
• TiDB 提供了开箱自用的可观测性，你们基本上把 TiDB 部署起来，就能够看到 TiDB 的全部指标，即便是在一个动态化混部的环境里面，也能很清楚的明白 TiDB 如今的状态是什么，即便有副本挂掉，也没有问题。

第二点，反回来，K8s 也能很高效的去撬动 TiDB 的潜力。

• 声明式 API 简化集群管理，做为一个分布式数据库，TiDB 的管理会比传统的单机数据库相对复杂一点，而在 K8s 上，它的声明是 API，就能把这一点多出来的复杂度很好的消化掉；
• 弹性资源池简化扩容缩与故障转移， TiDB 的故障容忍和无限的水平伸缩都须要额外的资源，好比说，咱们去横向扩张 TiDB 集群时，须要申请一部分新的资源进来，在故障容错以后，要作故障转移把故障副本数补齐。那么 K8s 的弹性资源池就能很好的把 TiDB 在水平伸缩和故障容忍上的潜力发挥出来。

所以， TiDB 和 K8S 可以很是好的进行一个结合，而且释放出更大的潜力达成 1+1 大于 2 的效果的。这固然不是一个巧合，这背后的缘由是，TiDB 和 K8s 都遵循一样的云原生最佳实践原则。那么假如说咱们已经熟悉 TiDB 和 K8s 的知识，只要稍微花费一些工夫，用 K8s 的云原生对象就能够部署一个 TiDB 集群，并且能运行的不错。

可是，TiDB 和 Kuberentes 都有大量的最佳实践，基本上你想快速看完是有点困难的。 那么，咱们在 K8s 上部署 TiDB 的时候，应该怎样去遵照最佳实践呢？一个基本的办法就是把这些坑都了解清楚，而且写很是多的 run book 来告诉 SRE team，怎么去运维好它们。 run book 须要口口相传，须要不断的进行知识的交互、交流。但其实你们都知道，程序员通常不喜欢作这个。

咱们更喜欢把这些知识写成代码，作自动化。那么，咱们怎么样把这些东西写成代码自动化呢？

你的 TiDB on Kubernetes 运维专家：TiDB Operator

答案就是 TiDB Operator 。 TiDB Operator 是什么？本质就是利用 K8s 自己的扩展机制，把领域性的运维知识编写成代码，你们能够把 TiDB Operator 理解为在 K8s 上运行 TiDB 的运维专家，把一个专家型人物对 TiDB 和 K8s 的全部知识都编写成了代码。

TiDB Operator 首先添加了一组自定义类型，好比说 TiDB Cluster，表明一个 TiDB 集群，能够在这些类型里描述你想要的 TiDB 长什么样；第二，TiDB Operator 添加了一组自定义控制器，这组自定义控制器就是这些运维知识的集合，它会用这些代码化的知识帮助你自动化的运维 K8s 上的 TiDB 集群。

看一个例子：首先是自定义类型，当 TiDB Operator 把自定义类型添加到 K8s 中后，做为用户就能够提交资源定义到 K8s 里面，好比咱们须要一个 TiDB 集群，这个集群要的版本是什么，要多少 PD，要多少 KV。以及咱们能够定义一个 TiDBMonitor 对象，用来监控 TiDB，在对象定义里则只须要定义咱们要监控哪个 TiDB 就能够了。

那么，你们能够发现，咱们在作这些资源定义时是遵循 K8s 自己的声明式定义的。那这些的理想状态由谁来实现呢？——由自定义控制器。自定义控制器会把全部的需求和 K8s 集群里的实际状态作一个对比，对比以后就能发现二者的不一样，就须要把实际状态向指望状态转移。好比说咱们把刚刚的 TiDB 集群对象和 TiDB 监控对象提交到 K8s ，那么 TiDB Operator 的控制器就会帮助咱们建立不少的容器以及监控。

固然，仅仅只有建立是不够的，TiDB Operator 中还集成了 TiDB 运维专家的全部的领域知识，下面我分享几个运维知识。

运维知识：部署

1. TiDB Operator 会为每一个组件选择最佳的 K8s 原生对象；
2. 会自动地引导 PD 作 Peer Discovery，无需手工配置；
3. 最重要的，还会打散 TiKV 容器并自动添加 store-label ，辅助 PD 实现 Region 高可用拓扑。

运维知识：升级

滚动升级 TiKV 的时候，给每一个 TiKV 实例发个SIGTEM，这时 TiKV 其实只会作一些基本的 Graceful Shutdown 操做。那就有一个问题，TiKV 退出时并不会主动的把全部的 Raft Leader 都迁移出去。假设咱们有比较大的流量，滚动升级时让没有受影响的 Raft Group 被动地去作一个 leader 超时从新选举，那极可能会致使咱们的数据库延迟会有必定的抖动。

那么 TiDB Operator 怎么作升级呢？在每次升级一个 TiKV 的容器以前，Operator 会先调用 PD 接口，把 TiKV 上边的 leader 所有迁移完，不接收读写请求后才会去重建 TiKV 的容器。依次往复，好比把 TiKV2 迁完了，就要把 TiKV2 重建， TiKV2 重建后，又能够把 leader 迁上去，接收请求，而后下一个就是把 TiKV1 的 leader 迁完，再往下。实现一个优雅的滚动升级。

运维知识：故障转移

好比，如今 TiKV1 运行的不正常，那么 Operator 的控制器就能够结合 PD 里的 TiKV1 对应的 store 状态信息和 K8s 里它所在容器的状态信息，来判断这一个 TiKV 的 store 是否异常。判断逻辑大体是 store 处于异常状态，而且持续超过必定时间。检测到异常后隔多久再作故障恢复以及怎么样判断是否发生异常，自己也是一种运维知识。

那 Operator 有了这些知识而且把它代码化以后，就能够在检测到异常后，过一段合理的时间后再补充新的 store ，把副本数补齐。这样即便咱们接下来 TiKV2 再挂，那集群就不会受影响，这就是 Operator 帮助咱们作的故障转移。

Operator 在最新版里还提供了 on to scaling 的功能，咱们去查看集群当中的全部的组件的监控信息，而且根据这些监控信息，作自动的扩缩容，可想而知就须要更多的支持了。

你们可能会想，尽管 Operator 带来了这么多好处，但我仍是担忧假如用 Operator 上了 K8s 以后会有一些问题。好比，上 K8s 会带来多少性能损耗？会影响个人稳定性吗？假如 K8s 挂了，个人数据库会不会受影响呢？一个 TiDB 和 K8s 的领域专家是能够解答这些问题的，所以，TiDB Operator 固然也能够。

运维知识：性能

1. TiDB Operator 支持独享节点与混部，能够按照优先级权衡性能与成本；
2. 自动化运维知识考虑了本地盘，使用本地盘就能够消除远程存储的损耗；
3. 支持 K8s 的 HostNetwork 部署集群，消除二层网络开销，因此说在必定的配置下，用 TiDB Operator 部署 TiDB 实际上是能够作到零 overhead 的。

运维知识：稳定性

1. K8s Master 故障不会影响集群，由于只是控制节点故障，跑 TiDB 的节点并无故障；
2. K8s Node 故障会帮咱们作自动故障转移；
3. 假如 K8s 的整个集群全部节点都故障了怎么办？Operator 自己有一个默认配置是在这种状况下会保留全部的存储，首先先保证数据不丢。
4. 假设真的是发生了灾难性的故障，整个机房好比说被水淹了怎么办？Operator 自己也会帮你作周期的备份，至少能够找回最近一次的备份，把你的数据先恢复到某个近期的时间点上。

Operator 开箱即用给咱们不少稳定性上的加强，也就是说在稳定性方面， Operator 给了咱们一个很好的基石，咱们能够继续在基石上再作一些加强，这能够省不少的工夫，而且得到更好的稳定性。

最佳实践案例：PayPay&立刻消费金融

最后再来看两个案例，第一个案例是 日本领先的在线支付公司 PayPay。PayPay 在日本就能够理解为中国的 AliPay 加微信支付。 PayPay 如今是用 Operator 部署了 100 多个数据库节点，生产环境有 30 多个由 Operator 管理的节点。PayPay 当时在作 PoC 时，作了至关详尽的故障演练，包括各类进程故障、节点故障、以及 AWS 整个可用区故障和还有灾难恢复。好比模拟 AWS 整个全挂了，还能不能经过周期性备份把集群恢复出来，当时也是这些全部的故障演练都很好的经过了 PayPay 的审核，PayPay 才得以放心把整套集群放到到 TiDB Operator 和 K8s 上来。

第二案例是咱们国内的立刻消费金融。上线的是系统归档和跑批业务，整个线上集群是有 60 多个物理节点，他们最显著的一点就是在用了 TiDB Kuberentes 以后，整个混部的硬件成本降低到原来物理机部署的 30% 左右。所以在总体的性价比上是一个巨大的提高。

最后总结一下，什么是 TiDB 在 K8s 上的最佳实践？其实只有一句话，Keep Calm and Use TiDB Operator。固然，用 TiDB Operator 自己仍是须要必定的上手成本的，这点咱们也在不断的作改进，你们能够参考咱们的官网，看一下 TiDB Operator 的 一系列文档，让这个运维专家来为你的 TiDB Kuberentes 之旅保驾护航。