共计 8007 个字符，预计需要花费 21 分钟才能阅读完成。
近日，由 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、引入可观测性（包含监控、日志、追踪）等，缓缓往上到中间件，以及有状态服务的容器化。再往上一步一步实现整个公司的云原生落地。这个过程中大家必定会踩坑的，然而很多问题也曾经在社区跟大家分享过，所以大家也要常常参加到开源社区，置信你能够从外面学到很多常识。
