社区中经常看到 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搞不定的故障，再也不用半夜爬起来搞运维了（虽说我是个开发，以前也没爬起来过 
）
问题2：
如果就3台机器，用k8s也行，但是cpu会浪费一些，不值当的。
问题3：
就是上面说的就3台机器，不能上外网（因为镜像都在外网，不能上的话还得自己搭建一个镜像仓库）。额外的，如果对k8s不熟悉，也不想了解，那就不推荐了。
想了解k8s的，推荐一个网站：https://jimmysong.io/kubernetes-handbook/
1 个赞
若应用业务已跑在 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 个赞
我是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跑本地盘没问题的，挂了再拉起来，挂一个节点不影响。