基于 Kubernetes 的发布系统设计

 人工智能技术     |      2020-04-10 12:06

导读:背景:在我们将服务迁移部署到Kubernetes集群之前,我们主要通过描述。gitlab-ci.yml文件。通过这个过程,我们可以在代码更新后完成单元测试、lint、编译、图像打包和发布。但是

背景:在我们将服务迁移部署到Kubernetes集群之前,我们主要通过描述。gitlab-ci.yml文件。通过这个过程,我们可以在代码更新后完成单元测试、lint、编译、图像打包和发布。

但是,在将服务部署到Kubernetes集群之后,每个服务都需要在GitLab仓库中维护一个部署模板来启动新版本的服务。每个部署过程都是将一些发布参数与部署模板结合起来,生成发布所需的deployment.yml文件,然后通过kubectl命令将其发布到Kubernetes集群。然而,该方案具有以下缺点:

每个服务都维护一个部署模板,该模板具有一定的管理复杂性,并且缺乏统一的发布历史管理。这不利于问题调查和回溯。它缺乏有效的权威控制。有一定的风险。为了解决上述问题,我们提取了CI/CD流程发布工作,设计了一个基于Kubernetes的发布系统来完成服务发布工作。

出版系统的基本功能我们设计的出版系统具有以下基本功能:

基于服务的粒度用于完成发布功能。发布记录显示了每个发布记录可以查询和发布的详细过程。对于每个发布记录,可以执行快速回滚操作来发布结果通知。一些服务支持通过邮件和钉钉通知。灰度发布流程概述发布系统需要在发布前完成预配置项流程。具体操作如下:

当GitLab中有代码更新时,我们可以设置一个特定的配置项规则来触发管道Gitlab-ci来提取代码并完成单元测试、lint、代码编译和映像构建。图像构建完成后,将带有版本信息的码头工人图像上传到码头工人港口。发布系统输入Docker映像的版本信息,上述工作就绪后,发布系统可以根据每个服务选择相应的版本,生成每个发布所需的部署文件,然后调用Kubernetes API服务器实现服务的滚动升级。

发布过程详述了基本的发布操作

在发布系统中,每个发布操作都被视为一个发布任务。因此,如果需要升级服务,需要为此服务创建一个新的发布任务。以下操作是特别需要的:

选择要发布的环境(测试环境或正式环境),根据服务名称获取镜像列表,选择版本确认发布参数,填写发布描述提交信息,启动版本发布任务

完成发布任务的创建后,可以显示每个发布任务的信息。除以上填写的信息外,还包括发布任务的开始时间、发布持续时间、操作用户、发布描述、发布状态等信息,从而完成每次发布操作的记录,有助于故障排除和问题回溯。


  • 共3页:
  • 上一页
  • 1
  • 2
  • 3
  • 下一页