【交流贴】什么场景下需要使用 TiDB + k8s?

社区中经常看到 K8s + TiDB 的问题,

但是之前有听到一些社区小伙伴的声音,说不太推荐 K8s + TiDB

原因是:一旦遇到问题,排查起来比较困难,比如 K8s + TiDB 比较难玩(上手要求高),比较容易性能不符合预期。

问题1:

什么场景下需要使用 TiDB + K8s ?能解决什么问题?

问题2:

资源不够的情况下是不是不能考虑 TiDB + K8s ?

问题3:

什么情况下不推荐使用 TiDB + K8s?

推荐阅读:

TIDB+K8s比较难玩是因为对k8s了解太少,tidb这么复杂的东西都能运维起来,k8s还是问题吗?
问题1:
k8s+operator非常爽,官方的operator几乎可以自动驾驶了,几乎没遇到过operator搞不定的故障,再也不用半夜爬起来搞运维了(虽说我是个开发,以前也没爬起来过 :sweat_smile:
问题2:
如果就3台机器,用k8s也行,但是cpu会浪费一些,不值当的。
问题3:
就是上面说的就3台机器,不能上外网(因为镜像都在外网,不能上的话还得自己搭建一个镜像仓库)。额外的,如果对k8s不熟悉,也不想了解,那就不推荐了。

想了解k8s的,推荐一个网站:https://jimmysong.io/kubernetes-handbook/

1 Like

若应用业务已跑在 k8s 上,可考虑 tidb-operator 将 tidb 也部署在 k8s 上,解决技术栈统一问题。

在我经过测试和使用这段时间以来,我认为像电商这类有瞬时UV的,优先考虑TIDB+K8S,像稳定的可以考虑,tidb+物理,这种方式。其次考虑 硬件环境与网络环境处于高配的状态下也可以考虑tidb+K8S,在配置环境达不到要求的时候,用物理机尽可能的把性能发挥出来。至于难度自我感觉对于这种分布式的环境来说,完全是高可用,不用担心半夜爬起加班这种情况。

问题1:
有现成的k8s环境,且k8s剩余资源足够,业务有瞬间高峰有概率直接击穿数据库的场景下需要使用 TiDB + K8s,
可以解决业务高峰数据库无法承载压力的问题。

问题2:
资源不够的情况下尽量只用tidb吧,k8s也是要占用一定的资源的

问题3:

没有现成的k8s环境,且k8s一点不懂,需要重新学习的,资源也紧张,就别折腾了,安安生生物理机部署tidb吧

没用过tidb+k8s,弱弱问下,自己测试,能在mac上折腾吗?能跑起来吧

16G以上的应该是可以。

感觉不太能

可以试试 k3s + mac

1 Like

我是win10,16G内存,以前用vmware试过,跑起来以后,基本相当于死机了。。。

windows的16G不能和mac的比,性能上差太多,系统就要吃好几个G内存。

适合使用TiDB+K8s的场景:
1、为了统一技术栈。比如绝大多数应用都已经跑在K8s上了,K8s上的运维能力也很强,可以考虑将TiDB集群也放在K8s上去跑
2、使用了公有云及相关K8s服务

不推荐使用TiDB+K8s的场景:
1、没有很强的K8s运维排障能力
2、对数据库的计算/存储资源的弹性伸缩能力没有特别高的要求和依赖
3、对TiDB的QPS/TPS性能有极高要求

不认同这个,好像是说k8s有性能损耗似的,实际上k8s管物理机的话,并没有任何虚拟化,跑一层docker也是物理机跑的。怎么会影响性能呢?

我没有说性能损耗。K8s很多场景会使用网络存储和共享盘这种,比如云平台上,它和使用本地PCIE闪存卡比IO性能是有差距的。当然K8s上TiKV也可以使用本地盘,但这样的话灵活性就会打折,不如直接跑裸金属

k8s跑本地盘没问题的,挂了再拉起来,挂一个节点不影响。