起因或现状

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

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

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

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

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

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

为什么会这样

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

反思

首先第一点:我们为什么要用容器(k8s),它解决了我们什么问题

我觉得容器的好处有:

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