技术编程|TiDB on Kubernetes 最佳实践( 三 )


运维知识:性能
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 之旅保驾护航 。


推荐阅读