起因或现状

公司准备上线 k8s 集群，目前在云上有微软 azure 托管的 aks，aks 上面的用来部署一些对外的业务，数据中心（有两个 - 移动和电信）是我自建的，主要是对内网服务

现在的问题是我们构使用的是 jenkins，构建方式和传统虚拟机发布没什么区别，只是换成了容器，简单来说就是:

传统发布（所有环境流程一致）： 拉代码 - 构建 - 可执行文件上传服务器
现在发布（所有环境流程一致）： 拉容器镜像（基础环境） - 拉代码 - 构建 - 上传镜像仓库

所有环境的发布都需要准备一套环境，也就是说容器并没有解决我们的环境标准化的问题，比如：

我们的 jenkins 的 node 节点在数据中心、办公室内网、azure 云上都有，因为这些环境都需要构建一遍镜像
围绕构建需要提供一些基础设施，比如我们 apt、maven、pypi 等的缓存服务（用的 nexus），容器镜像仓库（用的 jfrog）这些都需要在每个环境准备一套，每个服务还需要做高可用，简单算下来也有 6 个 nexus 和 4 个 jfrog

如果我们换成办公室构建完成，上传到公网的 jfrog 仓库，后面所有的操作都以容器镜像为单位进行（比如测试测试的就是镜像、发布发布的也是镜像而不是代码），nexus 缓存和 jfrog 只需要 1 个就可以了，而且可以保证测试环境和生产环境一致。

为什么会这样

我觉得还是公司在把容器当作虚拟机在用，并没有发挥容器的优势，反而增加了很多维护成本。
和领导提过这个方案，被否定了。原因如下：
建议

反思

首先第一点：我们为什么要用容器（k8s），它解决了我们什么问题

我觉得容器的好处有：

  • 一个是标准化，运行环境在测试环境和生产环境完全一致（除了内核层），标准化的另一个好处是 CICD 或者说运维、开发的效率更高
  • 另一个好处是节省资源，包括 k8s 的容器调度不会像虚拟机那样很多跑了一两个服务，很多资源都浪费掉了。