@johnniang 这个原来也考虑过，后来考虑到这个只是换一种部署方式，并没有实现动态扩容也就没有想法了

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

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

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

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

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

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

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

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

如何界定需不需要，我不知道，但吞吐量绝对不是指标性要求。 我这边有一个智慧工地系统，业务场景边界比较清晰，模块比较多； 完全不能忍受升级一个模块全部重启； 恰好有个人会 K8S 。 然后就上了，甚至运行在现场的本地服务器上（客户一直看云视频，流量遭不住）——偶尔断个电，重启可方便了。