@raydied 我们的服务现在是在云服务器，打算迁移到机房，以前不用考虑意外问题，但现在也确实考虑这个问题

当你需要练手的时候 当你需要 KPI 的时候 无论规模，哪怕整个公司就你一个开发，就可以用 K8S

如果部署的服务比较多，k8s 带来的收益会高一些；架构切换，一定要想清楚收益啊

@qiangmin 业务重复度高，需要整合，降低维护成本（就是那个大中台，大后端啥的）。业务有弹性需求，类似双 11 有巨量访问需求，其他时间都是少量访问（扩缩容）。业务需要降本增效，公有云太贵，VMware 也太贵。业务需要国产化，需要完全的安全可控。

@salmon5 听君一席话，胜读十年书

所有公司都适合 k8s ，维护成本直线降低，小型服务直线降低运维难度，大型服务很多轮子就不用重复造了

我觉得再小都可以，除非你们一直就一台服务器一个服务。 我这边有个项目最开始就只有 3 个服务，两台 4c8g 服务器。我嫌麻烦就只弄了个 docker-compose, 后面就发现需要一堆 k8s 的能力。 1 、某个服务有假死的情况，需要健康检查，能自愈。docker 虽然有健康检查，但是无法自己重启。 2 、每次更新需要两台服务器都操作一遍，k8s 只需要改一次 yaml 3 、两台服务器的 docker-compose.yaml 需要保持一致，但是某些环境变量又不能完全一致。维护麻烦，易出错。 4 、新增服务麻烦，原本的 3 服务，增加了到了 6 个服务，还有个 elastic 集群了。 如果你们有专门的运维岗， 真不如 k8s 一把梭。

这玩意管理应用和资源好用，不是微服务啥的也好用阿。

这帖这么久了，期待 defunct9 来锐评一下 https://i.imgur.com/Ue1kikn.png

我们公司在用，我发现这东西包含了注册中心、配置中心的功能，而且自动将异常 pod 重新拉起，都很适合现网的情况 k8s 对小公司来说比较重，但是降低了维护成本，当机器多起来的时候，现网有几千个 pod 在运行，维护成本会比较高。虽然你可以搭建管理平台来维护，但是在这之前你用 kubectl 就能处理多数问题，确实很方便