分析Kubernetes 的发布系统设计

在我们之前将服务迁移部署到 Kubernetes 集群的工作中，主要是通过描述 .gitlab-ci.yml 文件来实现 CI/CD 的流程。通过这个流程，我们可以完成代码更新之后的单元测试、lint、编译、镜像打包以及发布等工作。

但是，当服务部署到 Kubernetes 集群之后，每个服务都需要在 GitLab 仓库维护一份 deployment 模板来进行服务新版本的发布上线，每次的 deploy 过程是将一些发布参数结合 deployment 模板生成发布所需的deployment.yml 文件，然后通过 kubectl 命令发布到 Kubernetes 集群中。但是该种方案存在以下缺点：

每个服务各自维护一份 deployment 模板，具有一定的管理复杂度

缺少统一的发布历史记录管理，不利于问题排查和回溯

缺少有效的权限控制，存在一定风险

为了解决以上问题，我们将 CI/CD 的流程发布工作抽取出来，设计了一套基于 Kubernetes 的发布系统来完成服务发布发布工作。

我们设计的发布系统具有以下基本功能：

以服务为粒度完成发布功能

发布记录展示

每条发布记录可以查询发布的详细过程

针对每条发布记录可以进行快速回滚操作

发布结果通知，支持邮件和钉钉进行通知

部分服务支持灰度发布

发布系统在进行发布操作之前，需要完成前置的 CI 流程，具体操作为：

在 GitLab 中有代码更新时，我们可以设置一定的 CI 规则触发流水线

Gitlab-ci 会进行代码的拉取，并完成单元测试、lint、代码编译和镜像构建等操作

完成镜像构建后，将带有版本信息的 Docker 镜像上传到 Docker Harbor 中

在发布系统进行 Docker 镜像版本信息的录入

在上述工作准备就绪之后，发布系统可以基于每个服务选择对应的版本，生成每一次发布需要的 deployment 文件，然后调用 Kubernetes API server 实现服务的滚动升级。

基本发布操作

在发布系统中，每一次发布操作都视为一个发布任务，所以需要对某个服务进行升级就需要对这个服务新建一次发布任务，具体需要进行如下操作：

选择需要发布的环境(测试环境或正式环境)

根据服务名获取镜像列表，并进行版本选取

确认发布参数，并填写发布描述

提交信息，开始版本的发布任务

（编辑：焦作站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!