江苏龙网

  1. 首页 > 资讯 > 科技 > >

技术编程|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 环境并不是一个很好的解决方案 。


推荐阅读


上一篇：新机发布,Android系统|一文读懂ColorOS 11海外发布会，5大领域持续领跑

下一篇：行业互联网|“光领制造，智创未来”——2020年光电子产业博览会11月在京召开