k8s jenkins pipeline 多分支发布_基于K8S的发布系统介绍

一、背景

在开发发布系统之前我们的CICD用的是某开源持续发布平台。整个流程大概是这样的，新项目首先要在流程系统录入应用、角色、构建参数、部署参数等基本信息；代码更新后，开发/测试会通过公司的流程系统或者jenkins进行线下环境的打包构建和发布(本质都是调用发布系统的api)，然后生产环境由SRE到发布系统上操作。但是这种方式其实存在很多问题，主要概括为以下几点：

• 没有权限管理：只要知道发布系统地址，就可以操作任何环境的发布；

• 发布入口多，存在多套CICD方案：流程系统、jenkins、开源发布系统都可以操作；

• 由于镜像版本名称设计问题，没有办法支持真正意义上的回滚，这样的回滚可能带来的是一次新的发布；

• 配置不够透明和清晰、入口很多，出现问题SRE排查困难；

• 开源发布系统的功能很少而且二次开发成本高，很难根据具体使用情况定制相应功能；

为了解决以上问题，我们重新设计了一套基于K8S的发布系统。

二、发布系统流程介绍

1、发布前配置

对于一个新的应用接入发布系统，SRE需要提前进行一些配置，这些配置只需要在应用接入的时候配置一次，后面可以进行修改。

绑定或者自定义pipeline，并配置CI参数

我们的CI过程是通过调用Jenkins完成的。Jenkins pipeline的配置在发布系统统一维护，由CI-admin进行管理，可以为每个应用制定个性化的Pipeline也可以使用通用Pipeline。

绑定Pipeline后，就可以执行构建操作了，一些经常修改的构建参数可以暴露给开发，例如分支、构建命令、sonarqube构建命令等。

配置CD参数：例如各个环境的存储、探针、资源限制、环境变量、副本数、边车版本等。

CD配置之后就可以交给开发进行部署

2、构建和发布

我们的CICD过程是解绑的，两者互不影响。因此可以更好的支持‘一次构建、多次发布’，也就是说每次的发布开发只要构建一次生成镜像，在部署各个环境的时候，都可以选择相应的版本。对于不同环境的一些差异化的配置，可以通过CD配置的环境变量传入。我们的发布系统还支持同一环境部署多个子环境，方便应用的多版本测试，并且支持滚动发布和蓝绿发布两种发布方式。

发布：

对于生产环境，我们给开发配置应用的发布权限，支持开发自助发布。但是要申请工单，在申请工单时候要填写镜像版本等信息，之后由测试、owner、sre层层确认审批完成后，就可以简单的通过点击工单部署了。

此外，发布到生产环境是有限制的，我们要求发布到生产的版本需要在test以及stage环境部署成功，否则在申请工单的时候根本不会显示该镜像版本，这样可以最大限度的减少生产发布出现问题。

每个应用都会拉一个企业微信群组，工单审批信息和部署结果等信息都会发到群组中，SRE可以通过群组中的消息跟踪发布过程，以便有问题时可以及时介入处理。

3、问题处理

发布出现问题怎么办？我们支持回滚策略，可以快速回滚到稳定版本；对于问题的排查我们也提供一些功能来支持，可以通过部署日志查定位出现问题的阶段，如果是应用报错可以通过应用日志和远程终端查看具体原因。

部署日志：

应用日志：

远程终端：

三、其他功能

除了持续发布的功能，还支持K8S管理功能：

• volume模版管理，可以设置glusterfs、pvc、nfs、emptydir多种类型。

• 证书管理，为发布系统添加多个集群以及集群证书。

• 域名管理功能，可以配置和修改ingress信息，避免在服务器上随意手动创建和修改，此功能也解决了之前域名配置混乱的问题，开发和SRE都可以一目了然的看到应用域名。

• 隔离配置功能，可以为重点应用和产线单独配置资源，与其他应用隔离，页面修改方便。

• 代码质量管理：增加了代码质量管理功能，配置和测试命令由发布系统维护，在CI构建过程中自动触发代码质量扫描，并回调扫描结果显示在每个应用界面，方便开发人员查看代码质量指标的具体数值和变化趋势，以便提升代码质量。

• node信息查看，可以查看各个集群node节点的资源信息、污点信息等，方便了解集群状态和调配资源。

四、总结

我们的发布系统不仅解决了之前的CICD系统遇到的问题，还增加了很多便利的功能。尤其是自助发布和终端等功能解放了SRE，减少了琐事的处理，可以让SRE把更多精力放到项目建设上。总结起来特点如下：

• CICD解绑：区分CI和CD，例如：如果仅仅是K8S问题影响部署失败不必重新构建镜像；支持“一镜像多环境部署”，节省时间和资源；

• 阶段化和自定义CI：Jenkins pipeline通过发布系统来管理，分为检查参数、编译、构建镜像等阶段，方便定位问题；支持个性化CI配置，不只是每个语言绑定一个pipeline，而是可以为每个应用设计不同的个性化pipeline。

• 权限管理：分为dev、qa、SRE、ci_admin、admin、k8s_admin、deployer等角色对应相应的权限；

• 发布记录和构建记录：每一次构建、发布和镜像的详细参数都有记录，出现问题容易回溯；

• 版本控制：镜像版本管理，每一次生成镜像的版本都是独一无二的；配置版本管理：资源配置、探针、环境变量、存储的每一次变更都有对应的版本记录；更好的支持回滚；

• 发布入口收口：所有CI、CD参数包括Jenkins Pipeline都是通过发布系统来配置，所有人员的发布相关操作也都通过发布系统完成；

• 自助发布：开发能够自助发布生产，解放SRE；

• 多种发布方式：支持滚动发布、蓝绿发布；

• 线下环境多版本管理：支持同一环境部署多个子环境，方便应用的多版本测试；

• 远程终端：进入容器排查问题；

• K8S管理

• 代码质量管理：构建过程触发代码质量检查，支持查看代码质量基本指标的数值和趋势；

注：本来是之前要写的【基于K8S的发布系统设计】，但是同事说我这不是设计思想是使用方法，所以我改标题了，来凑一下本周自己给自己定的任务。额.......我觉得从这个“使用方法上”还是可以看出来一丢丢的设计思想的。