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

@monkeyWie 如果再上一套 CI/CD ，又占用了更多的硬件资源，不知道这个会不会得不偿失

k8s 最大的优势在自动扩缩容，也就是流量大时能够自动启动新节点，流量减小时自动关闭一些节点以节省资源
其它的功能基本都有更好的替代，或者它本身也是用的其它组件
为什么说需要一些规模才上 k8s ，因为如果你就一个 replication 就足够了根本用不着扩缩容，引入 k8s 也许反而会让服务不稳定，规模再小一点你业务的资源消耗还赶不上 k8s 的消耗，这种就更搞笑了

1.云公司
2.集团公司计划从公有云迁移。集团子公司太多，集团公司子公司业务杂乱（比如物流、工厂、物联，销售前端、售后端，内网的报销、物料流转、即时通讯、员工管理，海外各国分公司也都有这些业务）。

可以先容器化，完了之后再考虑要不要用 k8s ，如果服务变更少，没有扩缩容需求可以先不上

@linxuan716 额这不算啥新思路 这属于常规操作 正常来说 CPU 密集型的后台任务都是需要用单独的设备部署的. 绝对绝对不可以与核心业务共享硬件资源的.

@testcgd 是的，我们现在领导也想实现容器化，因为有一些客户想独立部署，我们也可以节省部署时间

@litchinn 是的，这也正是我担心的

@lujiaxing 以前为了方便，开发都是直接在主项目中直接开发代码，后来慢慢的就堆在一起，想拆出来不容易

如何界定需不需要，我不知道，但吞吐量绝对不是指标性要求。

我这边有一个智慧工地系统，业务场景边界比较清晰，模块比较多；
完全不能忍受升级一个模块全部重启；
恰好有个人会 K8S 。

然后就上了，甚至运行在现场的本地服务器上（客户一直看云视频，流量遭不住）——偶尔断个电，重启可方便了。

@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 来锐评一下

我们公司在用，我发现这东西包含了注册中心、配置中心的功能，而且自动将异常 pod 重新拉起，都很适合现网的情况

k8s 对小公司来说比较重，但是降低了维护成本，当机器多起来的时候，现网有几千个 pod 在运行，维护成本会比较高。虽然你可以搭建管理平台来维护，但是在这之前你用 kubectl 就能处理多数问题，确实很方便

我们公司就我一个开发，现在是一个负载均衡+2 台服务器最传统的布局，也想搞这种 k8s 容器化之类的，但是对比了下成本，阿里云的 eci 容器什么的费用比单独自己买 ecs+负载均衡贵啊。