你认为什么规模的公司适合使用 k8s?

@billzhuang 1.33 还没有稳定版的吧 生产上如果不是稳定版的真不敢用

90%以上的公司不适合微服务话，也不适合上 k8s ，搞一下 docker 就行了。
现在不是 2010s ，单机可以 64c256g ，3-5 台负载均衡能扛住很大流量。
一般业务服务数不超过 10 个，代码不超过 100 万行，没那么复杂。

有哪些适合引入 k8s 的特征？
流量波动很大，技术上不能简单削峰，经常需要快速扩容缩容；
服务数量很多，几十个上百个服务，且经常新增服务；
机器数量很多，且负载使用很不均匀，浪费和吃紧共存；
研发人员很多，几十个上百个，虚拟化分配资源不够灵活；
重复部署很多，比如 saas 私有化部署，有 k8s 批量部署容易。

多大都可以用，CI/CD 能简化不少，release 也方便，环境隔离也是重要的一点。
嫌管理麻烦，rancher+k3s 就解决了，配合 Prometheus ，grafana ，loki （日志），tracing （调用链追踪），研发都会感谢你的。
你也能省出很多麻烦重复的工作。

@songray #6 适合的，把大的拆成小的微服务。

@ksmiloLove #38 这哥们儿给 k8s 贡献过 pr 吗？

阿里云 sae 省心

看你有没有自动扩容的需求，有就上，没有的话简单容器化也是一样的。

有状态服务多不多？如果太多而且不好改造 。那建议不要上。

服务扩缩容方便，数据库怎么办？

不明白为啥跑批会影响主服务，跑批可以独立申请一台主机做，而且可以连接到数据库的 Slaver 服务上读取数据。

@fffq 我也遇到了这个问题，我们现在使用的是 mongo 数据库，存储空间已经达到了 1T ，现在查询优化单靠加索引，如果部署到 k8s 上面是不是有什么更好的解决方案？

@jimrok 跑批会用到主服务的环境变量及配置，开发为了方便，现在想拆也很难了

没专业运维不要上，维护成本高。

23 年的滴滴 k8s 升级事故就知道了，这东西上手容易精通难，半吊子碰到升级之类的，只会带了更多的问题。

@linxuan716
不需要，手动维护成本更低。
等到了 100 个服务，每个服务几十个实例，你自然就去学习 k8s 了。

先单机抗, 不够了先升级硬件, 目前 EPYC9755 支持 384C6T, 等这个也扛不住了, 就再加一台服务器, 手动部署. 当再次扛不住了, 再加一台服务器, 还是手动部署. 依次类推, 直到手动部署的人扛不住了, 加人. 当人加无可加的时候, 还是扛不住了, 就可以切换 K8S 了.

想用的 2 个服务 2 台机器都会用，机器就算少也有一定的好处。 不想用的上百台机器也会想用 Ansible 之类的批量命令通道去管，自然也有他们的理由。

这个就和你信什么宗教一样，不信教的觉得信教的愚蠢，反过来也一样。 云原生就是一套方法论，和宗教一样你信不信用不用都可以达到目的。至于适不适合自己，只有自己试试看才有感觉。

@qiangmin #23 哪为啥不用 SAP 呢

@coefuqin #85 这哥们会叫你开 ssh 给他上去看看

我就说一个事，公司曾经有一个项目被某人上了 K8S ，然后一次 deploy 要半个小时，某人还找不到原因……
所以最基本的，你得能解决 k8s 的运维问题，上船容易下船难