近日，由 TiDB 社区重磅策划的「能量钛」圆桌论坛活动圆满落幕。本次论坛特邀云原生社区创始人宋净超老师担任主持，与来自支流科技、360、58 集团、汽车之家、PingCAP 的五位资深技术大咖，围绕 “当数据库遇上 Kubernetes” 主题，探讨了他们对数据库容器化部署及运维的实践与思考。

视频回顾：https://www.bilibili.com/video/BV16q4y1j7UZ

嘉宾介绍：

• 主持：宋净超，Tetrate 布道师，云原生社区创始人。
• 特邀嘉宾：
  • 张晋涛，支流科技云原生技术专家。Kubernetes 及 Docker 等众多开源项目贡献者，专注于 Apache APISIX Ingress 及 Service Mesh 等领域。
  • 代晓磊，360 数据库运维高级专家。10 年数据库运维开发经验，开源爱好者，TUG MVA / 顾问，TiDB in action 作者之一。热爱总结和分享，喜欢挑战新技术。
  • 刘春雷，58 集团高级 DBA。负责 58 同城 MySQL、TiDB 数据库、DorisDB 运维，TUG MOA、内容组 leader，拥有丰富的数据库开发与运维经验，热衷于数据库的自动化、平台化的建设。
  • 李欣，汽车之家 DBA，主要负责汽车之家的数据库运维和开发工作。
  • 王鹏飞，资深专家，从事分布式系统、分布式关系型计算、云服务构建多年，目前在 PingCAP 负责 TiDB Cloud 的研发工作。

在圆桌讨论开始前，支流科技的张晋涛老师先跟大家分享了 K8s 的发展历程。

众所周知，K8s 是 Google 在 2014 年开源出来的用于解决生产环境中大规模容器编排的组件，回看 K8s 的发展史，可以了解到 2017 年左右 K8s 几乎已成为云原生技术的事实标准，并受到越来越多的公司的青睐。K8s 能成为云原生的基石与其三大特性密切相关。首先，K8s 自带便捷性，包括故障自愈、容器编排、服务发现，使应用更便捷。其次，K8s 在数据库、Serverless、边缘计算、微服务等多种技术领域的应用，扩展了其使用场景的边界。第三，K8s 具备的稳定性与安全性为其生产应用提供了强有力的支持。除此之外，周边生态的持续完善也为 K8s 迎来长足的发展奠定了不可磨灭的基础。

近年来，数据库的上云之路备受关注。作为企业数据资产的基础设施，数据库能否与云原生技术结合，又将碰撞出怎样的火花？本文将五位嘉宾对于数据库容器化是否可行、数据库迁移到 K8s 的过程、成功案例、踩坑经验等精华内容进行整理，希望对大家有所参考和借鉴。

探讨：把数据库放在 K8s 上可行吗？

对于这个问题，360 的代晓磊老师给出了肯定的回答。将数据库放在 K8s 上虽然可行，但前提是需要一定的技术积累，这件事情有难度。数据库是一个有状态的服务，一个有状态的服务去上 K8s，其成本是不容忽视的。另外，从可行性的角度而言，需要解决部分的技术上的难题。

既然可行，那么数据库容器化部署究竟有何优势？

晓磊老师认为数据库容器化的优势有两点，一是降本增效，我们现在有一些集群的资源利用率可能不是太充分，CPU 浪费或者内存浪费，而如果利用一个 K8s 集群，将这些资源收集起来作为一个资源池，通过 TiDB Operator 将 TiDB 部署上去，再分配相应的资源，能够实现更合理的资源分配和集中性的管理，节省资源成本。二是资源隔离，K8s 提供了非常好的做资源隔离的模式，如果能够利用上 K8s 的这种集群管理模式来实现资源隔离，也是一个很好的使用条件。

针对这两点，58 集团的刘春雷老师结合 58 集团数据库在 K8s 上的应用提出了一些日常的痛点问题。除了资源隔离、降本增效的需求外，节约机器，提高资源的使用率也是 K8s 的优势之一。现在 58 同城所有的 TiDB 数据库中，TiDB 和 PD节点 是使用虚拟机 KVM 实现的，TiKV 是放在物理机上去部署的，也就是说单机多实例也会有资源相互争用的情况，会影响到业务。如果这些集群都上云，相同资源的情况下，可以再多部署一倍的集群数量，这是最好的体验之一。另外，K8s 的资源隔离模式能减少业务的相互影响，带来一个更稳定的体验。

除此之外，汽车之家的李欣老师还提到一个很多业务使用中的的快速部署问题，K8s 能帮助业务实现实例节点的自动管理。从开发成本的角度而言，自己做一套数据库实例的周期管理也是个问题，而 K8s 有一套管理流程，相对来说，只需要做一些 K8s 的扩展 API 开发，对效率提高非常有帮助，也有助于数据库稳定性的提高。

当然，技术选型是严谨的，我们在选择技术方案的时候，要全面考量。尽管有上述诸多优势，但数据库上云，也必然跟线下业务有所不同。

数据库是一个非常大的领域，除了像 TiDB、MongoDB、ElaticSearch 这种部件，实际上还有 RDBMS。PingCAP 的王鹏飞老师认为它与 NewSQL 或者 NoSQL 的不同之处在于，NewSQL 或 NoSQL 基本上是以分布式的方式实现的，即使坏了一部分，大部分情况下不影响使用。K8s 有一个很重要的特点是 Pod 有可能经常挂，在 failover 的时候，那些有 replicate 的部件坏就坏了，应用不感知。但是在 MySQL、PostgreSQL 中发现如果 replicate 挂了，就会很麻烦。所以我们在选择技术方案的时候，要看业务能不能接受在跑的时候链接断掉了。如果从降本的角度去看，大概率需要去考虑几方面的东西，比如说要把一堆不太忙的 Pod 放到一起，将机器省出来给更忙的业务去用。然后在转移 Pod 的过程中，也会涉及到更频繁的应用面链接的断掉。类似的情况我们就需要考虑，应用是否需要加一个中间件去处理上述问题。

TiDB Operator 架构图

MySQL 的一些中间件能够解决掉这种问题，换句话说，主服进程在迁移的过程当中，能够保证客户的链接不断，并且自动帮助客户完成重试操作，这样的话应用层的代码一行都不改，此时迁移可能会给技术方向的选择上带来比较大的不确定性。

此外，还需要看一看真正的成本，除了上云节省的成本，是否也增加了研发成本，所以这是一个综合性成本的考量。

任何事物都不可单一论之，数据库部署在 K8s 上的优势依然明朗，但其中潜存的隐患也不容忽视。晋涛老师针对其中不太好的地方进行了补充。

• 第一，潜在的性能损耗，当我们把数据库上到 K8s 当中，首先要面临的就是增加了一层虚拟网络，尽管可以通过 underlay 的方式减少网络的影响，但不可避免的会产生一定的性能损耗。
• 第二，核心服务的质量难以保证。K8s 的 Pod 随时可能销毁，还有资源的抢占问题，此时数据库这个核心服务的质量就难以得到保证。
• 第三，业务的相互影响。每个机器上的资源总量是固定的，在做调度的时候，需要考虑数据库的内存问题，当出现跨节点调度时，想要提升资源利用率，就不得不混布，难免会造成业务互相之间的影响。
• 第四，监控。K8s 原生的一些特性无法完全满足业务的监控需求，往往需要二次开发来补充完善。

关于数据库部署到 K8s 是否可行以及其中利弊五位老师已介绍得非常详尽，还是需要实际应用选型中结合自身业务需求充分、全面考虑各项相关指标。

迁移前，我们需要准备什么？

基础测试

针对这个问题，晓磊老师认为以下两个方面需要考虑：

• 首先，性能测试，用一台物理机或者压测一下看相关数据，比如 QPS 能够达到多少，资源使用到底是什么样子。同时需要及时关注一些监控指标，看看性能上是否能够满足业务需求。
• 其次，破坏性测试。通过做混沌工程的一些工具，把 MySQL 干掉，或者把 TiDB 的 TiKV Server 干掉，看看会发生什么，整个 failover 机制是否真的能够做到及时拉起。对于有状态的服务，做破坏性测试主要是为了做到心里有底，看数据库的可用性是否还可以。

如果以上两个方面测试都通过，再推一些边缘业务进行尝试，稳定后上核心业务。

不过春雷老师则认为，从现状上来看，性能损失是肯定的。更重要的是关注性能损失后是否影响使用以及如何通过其他措施进行弥补。另外，从功能性上来看，最紧急的高可用切换或者日常的读网络是否能正常地达到数据库，以及底层的工具到底能不能用也是需要关注的。

关于性能测试，毋庸置疑是迁移前的必要步骤，但对于性能测试李欣老师认为无论是否将数据库放在 K8s 上，核心目标都是为业务服务。因此测试最主要的是结合业务真正的需求，比如一个是基础的性能测试，另一个是针对业务的模型测试，可能基础的测试性能其实损失还好，但是真正结合我们业务模型的时候，性能损失可能会比较多，这个是提前测试中必须要关注的部分。

而高可用，李欣老师认为是重中之重，怎么解决、怎么适配，之前的运维系统上到容器之后，是否能够改造，改造能否被兼容，成本如何等问题，也要考虑进来。

架构及管理

对于 K8s 的部署架构，李欣老师分享了汽车之家当前的架构现状。汽车之家当前有一些 MySQL 部署在了 K8s 上，用的是自建的 K8s 集群，没有放在云上，基本上是由专门的运维团队来运维 K8s 集群，用的是 MyQSL Operator 来开发的。当然，Operator 的开发是由 DBA 和 K8s 运维团队以及云开发团队来开发的相关接口，管理上有专门的 K8s 运维团队在管理，DBA 只是去管理 MySQL 的实例，没有 K8s 的权限。

晋涛老师也有 K8s 的管理经验，曾使用过自建的集群、也使用过托管的集群。也有 node节点通过云上资源去做扩容的模式，这种模式下控制面是自建的，node 节点则是通过跟其他的云厂商拉专线的方式直接扩容。

这几种方式各有优劣。

自建 K8s 集群

自建的集群优势在于全都自己控制，但是大家也都知道，整个的物理机的采购周期比较长。相应的会面临如下问题：

• 业务马上要搞大促和活动了，但物理资源可能来不及调配。
• 如果从某个地方挪一些机器到 K8s 集群，对操作系统及其内核都有一定的要求。可能需要经过装机初始化操作，然后这一系列流程下来，不仅耗费人力成本，还有时间成本。

云上拉专线

另外一种方式是直接在云上拉个专线，达到随时扩容，十分便捷。比如活动结束了，可以直接将资源释放掉，而且可以在云上提前创建好虚拟机的镜像，整个云上虚拟机都可以直接用镜像拉起来，不需要再去做什么额外的配置。

全托管

全托管方式最简单，但是它也面临着一个问题，有些云厂商的控制面不开放，比如搭了三个节点的高可用的控制面，然后三个节点都会是收费的，但这三个节点却是不可见的，无法直接利用到。当然，除了成本之外，安全性也存在一定的风险，毕竟控制面不在自己手里。

对此，净超老师认为上述架构也类似于混合云架构，关于如何管理 K8s 上的集群，净超老师也提到了一些开源的软件，比如 Rancher、KubeSphere 等，大家也可以自己部署来管理不同的空间平台。

多了一层技术栈，在运维层面带来了哪些困扰？

日常运维需要注意什么？

如何兼容现有的系统、通过什么方式改造现有的系统、高可用在容器中要怎么做等，这些问题上面李欣老师已经提到。对此春雷老师也表示赞同，除此之外他还补充了一些可能遇到的问题，如：

• 自动化工具，物理机上的自动化工具在 K8s 上需要做定向的自动化开发
• 日常的管理，是再拉起一个集群还是保持日常的一些操作
• 问题排查，多一层多一个考虑，不像之前物理机可以快速定位

相比较之下，容器日常运维有一定难度。从运维人员本身来看，晓磊老师认为技术栈的增加对于 DB 来说，需要去学习一门新的技术，而如果 K8s 有单独的容器化团队在管理，交互成本也必然随之增加。

除此之外，K8s 运维经验丰富的晋涛老师分享了一些重要关注点以及具体的建议。

• 第一，K8s 层，K8s 的所有的组件都有可能出问题，所以在排查问题时，首先需要关注集群是否健康，如果集群健康，再确定网络是否健康，然后具体到业务侧上。
• 第二，业务侧，需要先检查配置是否正确，如若配置都正确，然后再确认具体的业务是否受到影响。
• 第三，数据库，每一个数据库都会有一个存储，当机器挂掉了，首先需要考虑到 Pod 能否漂移，如果是共享存储，则还要考虑性能。

数据的安全及完整性如何保障？

对此，鹏飞老师分享了以下几个要点：

• 持久性，一般是靠多份（>= 3）拷贝实现，完整性可以认为是通过事务去保证不同的参与者之间数据是一致的。
• 安全性，如果不考虑 TiDB 自身对于数据安全的控制，可以认为它就是 MySQL 的控制机制。

在此单说用了 K8s 之后的数据安全，因为 TiDB 支持在 TiKV 指定一个密钥，如果密钥是安全的，那么 TiKV 写下来的数据是加密的。所以透过 K8s 机制直接去读磁盘上的数据，拿的数据是加密数据，正常来讲是没办法解码的，因此安全性就得到了保障。

集群的权限部分，TiDB 社区在进行中，据鹏飞老师透露，后面 TiDB 社区第一步会先处理“只有一个 namespace 的资源权限就可以把 TiDB 处理掉”的问题。这件事情正在做，做完后会直接开源到社区。

以 TiDB 为例，放在 K8s 上是否可行？

论可行性

针对这个问题，TiDB Clould 负责人鹏飞老师率先分享了他的看法。他认为TiDB 是一个分布式的数据库，天生适应云原生的部署。

云原生提供了一层很好的抽象，能够解决这层抽象背后不同的部署环境问题，为业务的运行环境提供了很大的灵活性。再加上云原生可以提供很好的弹性，在真正运营的时候能带来很多的方便，可以选择更好的速度，也可以选择更好的数据持久性。

不过，TiDB 并不能简单地部署到 K8s上，原因是 TiDB 是一个分布式系统，运维一个分布式系统最麻烦的部分在于处理 failover。如果要将 TiDB 迁移到 K8s 上，重点需要关注以下几个问题：

• 首先，需要关注很多控制逻辑，当前这些控制逻辑已经做到了 TiDB Operator 里面。TiDB Operator 目前有 10w 行代码，据此可以猜到其背后的控制逻辑有多复杂。TiDB 的最终目标是通过 TiDB Operator 自动解决大部分过去需要运维才能解决的问题，这样才能降低使用者的运维成本。
• 其次，对于写逻辑的人要求很高，需要对 TiDB 有非常深度的了解，才能处理 corner case。但在生产的时候尤其是 OLTP 系统，遇到一个 corner case 掉到坑里了，有可能就是一个 P1 事故。所以鹏飞老师建议首先尽可能的把 TiDB 放到 K8s 上，然后尽可能的用 TiDB Operator 来去解决问题。
• 第三，标准化和自动化问题的解决晋涛老师认为也很重要。

TiDB 集群部署到 K8s 后，性能方面需要注意什么？

• 硬隔离：春雷老师认为首先是从资源上进行硬隔离，比如 CPU、内存、网络、磁盘等的隔离。如果隔离做的比较到位，就不会有特别大的相互影响。除此之外，晓磊老师认为还应该降低业务之间的相互干扰，如资源调度上的优化，最后如果能够从业务层面把 K8s集群隔离开，也能避免相互影响。
• 软隔离：鹏飞老师从软隔离层面进行了补充，他提到硬隔离指专门的机器给专门的 TiDB 集群使用，实际上很多公司会面临运营成本，对此还有软隔离的方式可以考虑，比如典型的离线在线互补的场景。软隔离用好了，也能够大幅降低运营成本，对于很多的公司来讲尤为重要。
• 智能化开发：后端的一些智能化开发也是可以考虑的方向，比如可以看物理机的负载了解大概的波动情况，以便更充分的利用资源，同时可以考虑一些自动化的开发，比如自动化调度等，实现节点的迁移，达到资源使用率提升的效果。

数据库容器化部署后，下一步做什么？

自动化和智能化

自动化与智能化是常见两个需要考量的问题，当处于多套集群的运维和监控时，机器人如果按照业务进行拆分，那么机器人管理是一个问题。晓磊老师认为在这种情况下可以考虑自动化来解决这个问题。不过，自动化也算是一个基本的要求，春雷老师认为平台化、报表信息展示也是一个方向，另外就是智能化，比如自动地故障治愈、智能化地扩缩容、通过自动化和智能化来给数据库运维减负。

对此，李欣老师表示赞同，他认为主要需要考虑如何跟现有的工具结合起来，把整个系统做得更完善，实现用户可以直接操作集群，进行扩缩容等。尤其是弹性扩缩容的问题，缩容的规则一定要严谨，因为一旦出了问题，带来的后果是灾难性的。

另外，可能某些业务真的非常重要，在物理机上可以不采用多机房或者是跨机两地三中心的方案，但是后面需要更关心在 K8s 上如何做到集群级别的高可用，比如多机房或是多集群的部署，亦或是结合使用，来更好地提高数据库的稳定性。

两地三中心的容灾方案

对于两地三中心的部署、容灾，鹏飞老师表示可以展开说明。

首先 TiDB cluster 从架构上天生支持这样部署，不过对于基础设施也有要求，比如果业务允许的 latency 只有 1ms，那就意味着跨多地多中心同步调用时候，时间要满足要求，因为这是一整套的 OLTP online 系统，它对于底层的基础设施会要求比较高。

然后在云上，相关实践是在三个不同的 AZ 里面去部署 TiKV 的实例。换句话说，在云上，一般能够保证整个的 zone 挂掉后，TiDB cluster 仍然是可用的，但推倒到线下，实际上也适用于两地三中心的情况。

但是云上跟线下不同之处在于，云上在同一个 region 里面跨 AZ 的通信很稳定，而且带宽相对来说很夸张。但是线下部署并不是所有的场景之下都有这么好的基础设施，甚至两地三中心当跨地域的时候，带宽和 latency 都会有比较大的影响，这个时候部署形态就需要做微调。比如 raft 的基本原理是要保证多数派写完，以及 leader 尽可能的落在一地的两个中心上，只有最坏的情况下， leader 的选举才会到单独的中心上去。这些都是在线下部署的时候需要考量的问题。

如何更好地实现性能与安全的平衡

春雷老师认为其实两地三中心多数是出于安全性的考虑。但安全与性能本来就是相互或者相反的，如果更注重安全，可能会有一定的性能损失，如果更注重性能，则安全上没法完美保证。但是正常情况下，性能上也一定有可以解决的方案。

晋涛老师认为除了上述提到的集群、pod 健康状况外，还需要考虑到网络的时延。另外对于网络策略上，鹏飞老师认为 TiDB Operator 实际上是个 controller，其主要目的是透过 K8s 脚手架来维护 TiDB cluster 的状态。比如少了一个TiDB 节点，TiDB Operator 会知道，并且去通过调用 K8s 的能力来把这个节点补回来。

所以对于 TiDB Operator 自身来讲， 并不依赖于网络，它是用来维护 TiDB cluster 状态的，并不是 TiDB cluster 自身。实际上在不同部署的情况下，不同的用户场景会有不同的规范，或者是选择了特定的网络插件，这些都会直接左右 TiDB cluster 对网络的使用。为了尽可能适应广泛的情况，唯一能做的就是不要让 TiDB cluster 的部署依赖于特定的网络插件，而是做到能够适应全球所有的情况。

给新手的建议以及踩坑经验分享

• 鹏飞老师：最大的建议就是 K8s 是神器，花时间把 K8s 掌握好，并且能够有能力做到将数据库搬到 K8s 上来，这样对于个人能力的提升会非常夸张，所以这件事情难归难，但是一定是值得的。
• 晋涛老师：首先，建议大家先对 K8s 最起码有一个大概的了解。其次，我们可能无法决策 K8s 集群本身的架构或者技术选型，但可以做到对应用拓扑部署的掌控。另外，使用时需要合理地设置应用在 K8s 当中的资源占用。最后，请谨记监控一定要先行。
• 晓磊老师：我就是一个新手，新手的话首先是输入，多学习相关知识，关注云原生社区的技术趋势，尝试去了解。然后再自己去折腾一个测试机群，逐渐地上手。这是我给新手的一些我自己在学习方面的建议。
• 净超老师：其实我觉得学习最重要还是得实践，然后跟大家交流分享，不能自己一个人捯饬，不知道外界的变化。CNCF 给出了云原生落地的一个具体路线图，从容器化、镜像化、做 CICD、引入可观测性（包括监控、日志、追踪）等，慢慢往上到中间件，以及有状态服务的容器化。再往上一步一步实现整个公司的云原生落地。这个过程中大家肯定会踩坑的，但是很多问题也已经在社区跟大家分享过，所以大家也要经常参与到开源社区，相信你可以从里面学到很多知识。