本文共 8417 字,大约阅读时间需要 28 分钟。
近日,由 TiDB 社区重磅策划的「能量钛」圆桌论坛活动圆满落幕。本次论坛特邀云原生社区创始人宋净超老师担任主持,与来自支流科技、360、58 集团、汽车之家、PingCAP 的五位资深技术大咖,围绕 “当数据库遇上 Kubernetes” 主题,探讨了他们对数据库容器化部署及运维的实践与思考。
视频回顾:
嘉宾介绍:
在圆桌讨论开始前,支流科技的张晋涛老师先跟大家分享了 K8s 的发展历程。
众所周知,K8s 是 Google 在 2014 年开源出来的用于解决生产环境中大规模容器编排的组件,回看 K8s 的发展史,可以了解到 2017 年左右 K8s 几乎已成为云原生技术的事实标准,并受到越来越多的公司的青睐。K8s 能成为云原生的基石与其三大特性密切相关。首先,K8s 自带便捷性,包括故障自愈、容器编排、服务发现,使应用更便捷。其次,K8s 在数据库、Serverless、边缘计算、微服务等多种技术领域的应用,扩展了其使用场景的边界。第三,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 是否可行以及其中利弊五位老师已介绍得非常详尽,还是需要实际应用选型中结合自身业务需求充分、全面考虑各项相关指标。
针对这个问题,晓磊老师认为以下两个方面需要考虑:
如果以上两个方面测试都通过,再推一些边缘业务进行尝试,稳定后上核心业务。
不过春雷老师则认为,从现状上来看,性能损失是肯定的。更重要的是关注性能损失后是否影响使用以及如何通过其他措施进行弥补。另外,从功能性上来看,最紧急的高可用切换或者日常的读网络是否能正常地达到数据库,以及底层的工具到底能不能用也是需要关注的。
关于性能测试,毋庸置疑是迁移前的必要步骤,但对于性能测试李欣老师认为无论是否将数据库放在 K8s 上,核心目标都是为业务服务。因此测试最主要的是结合业务真正的需求,比如一个是基础的性能测试,另一个是针对业务的模型测试,可能基础的测试性能其实损失还好,但是真正结合我们业务模型的时候,性能损失可能会比较多,这个是提前测试中必须要关注的部分。
而高可用,李欣老师认为是重中之重,怎么解决、怎么适配,之前的运维系统上到容器之后,是否能够改造,改造能否被兼容,成本如何等问题,也要考虑进来。
对于 K8s 的部署架构,李欣老师分享了汽车之家当前的架构现状。汽车之家当前有一些 MySQL 部署在了 K8s 上,用的是自建的 K8s 集群,没有放在云上,基本上是由专门的运维团队来运维 K8s 集群,用的是 MyQSL Operator 来开发的。当然,Operator 的开发是由 DBA 和 K8s 运维团队以及云开发团队来开发的相关接口,管理上有专门的 K8s 运维团队在管理,DBA 只是去管理 MySQL 的实例,没有 K8s 的权限。
晋涛老师也有 K8s 的管理经验,曾使用过自建的集群、也使用过托管的集群。也有 node节点通过云上资源去做扩容的模式,这种模式下控制面是自建的,node 节点则是通过跟其他的云厂商拉专线的方式直接扩容。
这几种方式各有优劣。
自建的集群优势在于全都自己控制,但是大家也都知道,整个的物理机的采购周期比较长。相应的会面临如下问题:
另外一种方式是直接在云上拉个专线,达到随时扩容,十分便捷。比如活动结束了,可以直接将资源释放掉,而且可以在云上提前创建好虚拟机的镜像,整个云上虚拟机都可以直接用镜像拉起来,不需要再去做什么额外的配置。
全托管方式最简单,但是它也面临着一个问题,有些云厂商的控制面不开放,比如搭了三个节点的高可用的控制面,然后三个节点都会是收费的,但这三个节点却是不可见的,无法直接利用到。当然,除了成本之外,安全性也存在一定的风险,毕竟控制面不在自己手里。
对此,净超老师认为上述架构也类似于混合云架构,关于如何管理 K8s 上的集群,净超老师也提到了一些开源的软件,比如 Rancher、KubeSphere 等,大家也可以自己部署来管理不同的空间平台。
如何兼容现有的系统、通过什么方式改造现有的系统、高可用在容器中要怎么做等,这些问题上面李欣老师已经提到。对此春雷老师也表示赞同,除此之外他还补充了一些可能遇到的问题,如:
相比较之下,容器日常运维有一定难度。从运维人员本身来看,晓磊老师认为技术栈的增加对于 DB 来说,需要去学习一门新的技术,而如果 K8s 有单独的容器化团队在管理,交互成本也必然随之增加。
除此之外,K8s 运维经验丰富的晋涛老师分享了一些重要关注点以及具体的建议。
对此,鹏飞老师分享了以下几个要点:
在此单说用了 K8s 之后的数据安全,因为 TiDB 支持在 TiKV 指定一个密钥,如果密钥是安全的,那么 TiKV 写下来的数据是加密的。所以透过 K8s 机制直接去读磁盘上的数据,拿的数据是加密数据,正常来讲是没办法解码的,因此安全性就得到了保障。
集群的权限部分,TiDB 社区在进行中,据鹏飞老师透露,后面 TiDB 社区第一步会先处理“只有一个 namespace 的资源权限就可以把 TiDB 处理掉”的问题。这件事情正在做,做完后会直接开源到社区。
针对这个问题,TiDB Clould 负责人鹏飞老师率先分享了他的看法。他认为TiDB 是一个分布式的数据库,天生适应云原生的部署。
云原生提供了一层很好的抽象,能够解决这层抽象背后不同的部署环境问题,为业务的运行环境提供了很大的灵活性。再加上云原生可以提供很好的弹性,在真正运营的时候能带来很多的方便,可以选择更好的速度,也可以选择更好的数据持久性。
不过,TiDB 并不能简单地部署到 K8s上,原因是 TiDB 是一个分布式系统,运维一个分布式系统最麻烦的部分在于处理 failover。如果要将 TiDB 迁移到 K8s 上,重点需要关注以下几个问题:
自动化与智能化是常见两个需要考量的问题,当处于多套集群的运维和监控时,机器人如果按照业务进行拆分,那么机器人管理是一个问题。晓磊老师认为在这种情况下可以考虑自动化来解决这个问题。不过,自动化也算是一个基本的要求,春雷老师认为平台化、报表信息展示也是一个方向,另外就是智能化,比如自动地故障治愈、智能化地扩缩容、通过自动化和智能化来给数据库运维减负。
对此,李欣老师表示赞同,他认为主要需要考虑如何跟现有的工具结合起来,把整个系统做得更完善,实现用户可以直接操作集群,进行扩缩容等。尤其是弹性扩缩容的问题,缩容的规则一定要严谨,因为一旦出了问题,带来的后果是灾难性的。
另外,可能某些业务真的非常重要,在物理机上可以不采用多机房或者是跨机两地三中心的方案,但是后面需要更关心在 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 的部署依赖于特定的网络插件,而是做到能够适应全球所有的情况。
转载地址:http://haxmi.baihongyu.com/