各位佬讨论下，各种中间件部署到底是直接宿主机还是K8S好

部署到 k8s 主要是图一个集中管理和横向扩展吧？主要还是看需求

原来我们除了数据库集群都是上的K8S，后来因为经常K8S网络抖动，又基本全下到宿主机了，想问问各位佬友有没有什么成熟的经验

我也想知道,蹲一个好回答,佬友们给点力啊

加一，有同样的疑问，有没有佬出来帮忙解答下

按百万用户，十万日活计算的话

无脑k8s

运维能力如何？运维跟不上尽量去用第三方。必要的自有服务多的话可以上k8s，中间件能用第三方就用第三方，到时候回滚、备份、还有状态故障等等都得考虑

第三方确实方便，但是目前来看我们还是倾向于自己维护

运维能力只能说还行，主要业务最近处于快速增长，依赖第三方的话后续变动麻烦

百万用户，十万日活

严格来说这个量已经需要稳定性保障了,不然P0让整个团队停摆

相对于节约的成本和可维护性来说基本不值得

出于实际的生产环境来说, 个人建议这样

选择各家的托管中间件,尤其是serverless可扩展版本

后续随着项目成长可不断无缝扩容, 前期成本也相对可控

大多数公有云都提供数据冷热分片控制放到对象存储上, 可以按需使用

K8S托管中间件一般仅限在测试和开发环境出于节约成本考虑

其带来了多重隐患: 数据安全 集群安全 集群脱敏都实现不了

鸡蛋放在一个篮子里, 那如果Node失联或ETCD抖动导致数据脑裂呢?

有状态中间件

例如数据库,缓存服务, 前端应用数据代理, 使用域名连接

后续升级只需切指向, ttl过了自动切换

可以把具体P0问题抛来聊聊, 10年老SRE法师现场作答 哈哈

目前，在k8s里面，有状态服务（比如各种数据库），

想要使用集群版本的话，基本上需要数据库自己本来做集群维护。

k8s本身或者说etcd本身，并不负责具体应用的“分布式集群”相关逻辑。

所以其实node失联，etcd抖动都跟应用层（数据库）无关。

至于楼主说的各种中间件，目前用到的，主要是pg、mysql、redis、minio。

目前全部使用pod来部署。

应用层内部的分布式管理，交给各个中间件的operator。

严格来说这个量已经需要稳定性保障了,不然P0让整个团队停摆

相对于节约的成本和可维护性来说基本不值得

相当认可。

我们一开始基本都是k8s，后来是因为某次redis其中几个pod未知原因挂了，k8s自动拉起新pod之后，内部service解析的ip地址还是老ip，导致redis集群一直有问题。后来就决定把基本所有中间件（除了某些应用类型的中间件）都给干到了宿主机上。

所以如果不考虑维护成本等，稳定性为第一保障的话是怎么比较好（PS：现在确实也有考虑把数据库集群和Redis集群上云，其他还是自己搞）