一种基于Kubernetes的持续集成持续交付的方法

摘要

本申请公开了一种基于Kubernetes的持续集成持续交付的方法，包括以下步骤：交付CI/CD‑Master到Kubernetes中；CI/CD‑Slave镜像定制构建；交付CI/CD‑Slave到Kubernetes中；同质slaves添加相同Label，同类型jobs使用Label进行构建；增大slave的executor数目；定时扫描清理slaves上的废弃jobs的遗留workspace；业务jobs配置workspace清理规则。本方案，并发能力增强，Master存活率强来自于使用Kubernetes集群管理CI/CD Master POD，用Lable去管理了CI/CD集群Slave POD，本身Lable关联了多个Slave，构成了一个资源池，并发能力就提高了。Slave整体的空间利用率有效提高，空间不足造成的构建失败大大减少。整个集群，通过Lable管理，综合利用率提高了，反应到Disk和CPU上使用均衡，保持相对合理水平。

说明书

技术领域

本申请涉及网络技术领域，具体而言，涉及一种基于Kubernetes的持续集成持续交付的方法。

背景技术

CI/CD是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD主要针对在集成新代码时所引发的问题。CI/CD可让持续自动化和持续监控贯穿于应用的整个生命周期(从集成和测试阶段，到交付和部署)。基于Kubernetes更加稳定的为软件开发提供服务。

Kubernetes对于开发者来说是一个惊人的开源容器编排引擎。Kubernetes是由Google发起的，这使Kubernetes在使用多个开源容器项目方面有一个惊人的优势。默认情况下，Docker更受Kubernetes的使用者支持和青睐。

持续集成与持续部署是我们日常工作中必不可少的一个步骤，目前大多企业单位采用传统的CI/CD一主多从方式会存在一些痛点，比如：主Master发生单点故障时，整个流程都不可用了；每个Slave的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲；资源分配不均衡，有的Slave要运行的job出现排队等待，而有的Slave处于空闲状态；资源有浪费，每台Slave可能是实体机或者VM，当Slave处于空闲状态时，也不会完全释放掉资源。

发明内容

本申请的主要目的在于提供一种基于Kubernetes的持续集成持续交付的方法，以改善相关技术中的问题。

为了实现上述目的，本申请提供了一种基于Kubernetes的持续集成持续交付的方法，包括以下步骤：

S1、交付CI/CD-Master到Kubernetes中；

S2、CI/CD-Slave镜像定制构建；

S3、交付CI/CD-Slave到Kubernetes中；

S4、同质slaves添加相同Label，同类型jobs使用Label进行构建；

S5、增大slave的executor数目；

S6、定时扫描清理slaves上的废弃jobs的遗留workspace；

S7、业务jobs配置workspace清理规则。

在本申请的一种实施例中，S1的步骤如下：

第一步，设计Dockerfile：

根据所在公司的业务流程，定制一个实例，这样可以将一些插件打包在自定义的实质，在数据存储服务器中开辟一个新的空间，通过NFS的技术手段存储配置数据；

第二步，Dockerlmage制作：

根据第一步中设计的Dookerfile构建自定义镜像；

第三步，搭建Docker私有仓库：：

Docker镜像仓库默认为开放云平台的DockerHub，因自己公司所打包的自定义Dockerlmage中包含自定义应用或则机密信息，所以要搭建自己的私有仓库来存储自定义镜像以及应用镜像，以便于安全快速的拉取镜像至服务器中启动相应应用程序；

第四步，设置ENV(镜像环境变量)

配置镜像环境变量，例如时区环境变量；

第五步，启动参数；

Linux下内核参数的优化；

第六步，构建CI/CD Master Deployment：

Master镜像自定义构建完成，将Master服务以Deployment的方式部署至kubernetes集群中，利用Kubernetes集群特性，当Master所在POD发生异常导致不可用，集群中会再次立即自动启动一个Master来支撑CI/CD的可用性。

在本申请的一种实施例中，S2的步骤如下：

第一步，Baselmage：

根据所在公司业务系统运行环境，选择CI/CD基础镜像版本；

第二步，Maven Plugin：

将项目启动所用到的Maven工具添加到Baselmage中，并添加环境变量以供编译调用；

第三步，Node Plugin：

将项目启动所用到的Node工具添加到Baselmage中，并添加环境变量以供编译调用；

第四步，Python Plugin：

将项目启动所用到的Python工具添加到Baselmage中，并添加环境变量以供编译调用；

第五步，其他开发工具添加至基础景象中，已满足所有业务编译打包部署需求；

第六步，CI/CD Slave Dockerfile：

整合业务中所使用到的所有开发插件至Dockerfile中，构建镜像并将镜像上传至私有Docker仓库中以供集群化部署应用程序快速拉取镜像启动CI/CD Slave节点。

在本申请的一种实施例中，在S3中将CI/CD Dockerfile构建的景象结合deployment，配置到CI/CD集群中，根据部署需要将自动调用JNLP的连接方式与Master连接通讯，极大的提高集群的灵活性与发布效率。

在本申请的一种实施例中，在S4中同质Slaves添加相同Lable，用Lable来管理Slaves，同一套产品，把同质Slaves通过Lable使用，同类型jobs可以使用Lable进行构建。

在本申请的一种实施例中，在S5中，增大executor数目，会增大并发量。根据不同的业务的场景，增加不同数量的并发量。

在本申请的一种实施例中，在S6中，要解决Slaves上遗留的编译workspace的问题，需要定时扫描Slave上的workspace。

在本申请的一种实施例中，在使用过程中，有一定几率会出现频繁的重命名job，如果把job重命名了，原来的编译空间就留下来了，出现了闲置，在扫描Slave上的workspace时，重点扫描重命名job，把workspace清理掉。

在本申请的一种实施例中，从业务job配置上，一定要配置相应的workspace清理规则；编译结束了，传到版本服务器或者制品仓库，workspace出现了闲置，可以在构建结束后就配置相应的清理规则，在扫描Slave上的workspace时，重点扫描配置相应的workspace，把workspace清理掉，这样Slave上的空间就被及时释放了，而不会等到下一次构建的时候由于空间不足导致的失败。

在本申请的一种实施例中，在S7中，考虑到特殊的业务场景和编译的时间特别长，中间有一些编译缓存，保留的话对下次构建的编译速度上是有很大提高的，在配置清理规则的时候，没有完全清理，而是保留了需要的，其它的都被清理掉。

与现有技术相比，本申请的有益效果是：通过上述设计的一种基于Kubernetes的持续集成持续交付的方法，使用时，定时扫描Slave上的workspace，解决Slaves上遗留的闲置编译workspace的问题，减少了空间不足造成的构建失败减少；

通过上述设计的一种基于Kubernetes的持续集成持续交付的方法，并发能力增强，Master存活率强来自于使用Kubernetes集群管理CI/CD Master POD，用Lable去管理了CI/CD集群Slave POD，本身Lable关联了多个Slave，这个就相当于Slave构成了一个资源池，并发能力就提高了。带来的直接效果，并发能力强，队列中构建任务等待的数目就下降了。Slave整体的空间利用率有效提高，这方面做了一些清理，空间不足造成的构建失败大大减少。整个集群，通过Lable管理，综合利用率提高了，反应到Disk和CPU上使用均衡，保持相对合理水平。

附图说明

图1为根据本申请实施例提供的基于Kubernetes的持续集成持续交付的方法的流程框图；

图2为根据本申请实施例提供的基于Kubernetes的持续集成持续交付的方法的交付CI/CD-Master到Kubernetes中的流程框图；

图3为根据本申请实施例提供的基于Kubernetes的持续集成持续交付的方法的CI/CD-Slave镜像定制构建的流程框图；

图4为根据本申请实施例提供的基于Kubernetes的持续集成持续交付的方法的交付CI/CD-Slave到Kubernetes中的流程框图；

图5为根据本申请实施例提供的基于Kubernetes的持续集成持续交付的方法的实施例1中清理workspace的流程框图；

图6为根据本申请实施例提供的基于Kubernetes的持续集成持续交付的方法的实施例2中清理workspace的流程框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、的方法、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。

另外，术语“多个”的含义应为两个以及两个以上。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

实施例1

请参阅图1-图5，本申请提供了一种基于Kubernetes的持续集成持续交付的方法，包括以下步骤：

S1、交付CI/CD-Master到Kubernetes中；

第一步，设计Dockerfile：

根据所在公司的业务流程，定制一个实例，这样可以将一些插件打包在自定义的实质，在数据存储服务器中开辟一个新的空间，通过NFS的技术手段存储配置数据；

第二步，Dockerlmage制作：

根据第一步中设计的Dockerfile构建自定义镜像；

第三步，搭建Docker私有仓库：：

Docker镜像仓库默认为开放云平台的DockerHub，因自己公司所打包的自定义Dockerlmage中包含自定义应用或则机密信息，所以要搭建自己的私有仓库来存储自定义镜像以及应用镜像，以便于安全快速的拉取镜像至服务器中启动相应应用程序；

第四步，设置ENV(镜像环境变量)

配置镜像环境变量，例如时区环境变量；

第五步，启动参数；

Linux下内核参数的优化；

第六步，构建CI/CD Master Deployment：

Master镜像自定义构建完成，将Master服务以Deployment的方式部署至kubernetes集群中，利用Kubernetes集群特性，当Master所在POD发生异常导致不可用，集群中会再次立即自动启动一个Master来支撑CI/CD的可用性。

S2、CI/CD-Slave镜像定制构建；

第一步，Baselmage：

根据所在公司业务系统运行环境，选择CI/CD基础镜像版本；

第二步，Maven Plugin：

将项目启动所用到的Maven工具添加到Baselmage中，并添加环境变量以供编译调用；

第三步，Node Plugin：

将项目启动所用到的Node工具添加到Baselmage中，并添加环境变量以供编译调用；

第四步，Python Plugin：

将项目启动所用到的Python工具添加到Baselmage中，并添加环境变量以供编译调用；

第五步，其他开发工具添加至基础景象中，已满足所有业务编译打包部署需求；

第六步，CI/CD Slave Dockerfile：

整合业务中所使用到的所有开发插件至Dockerfile中，构建镜像并将镜像上传至私有Docker仓库中以供集群化部署应用程序快速拉取镜像启动CI/CD Slave节点。

S3、交付CI/CD-Slave到Kubernetes中；

将CI/CD Dockerfile构建的景象结合deployment，配置到CI/CD集群中，根据部署需要将自动调用JNLP的连接方式与Master连接通讯，极大的提高集群的灵活性与发布效率。

S4、同质slaves添加相同Label，同类型jobs使用Label进行构建；

同质Slaves添加相同Lable，用Lable来管理Slaves，同一套产品，把同质Slaves通过Lable使用，同类型jobs可以使用Lable进行构建。

S5、增大slave的executor数目；

增大executor数目，会增大并发量。编译相当于我们用物理机24线程并发去跑，根据不同的业务的场景，增加不同数量的并发量。

比如原来一个物理机只配一个，根据有的产品线的job没有消耗那么多的CPU、memory，编译时间要求不高，有一些Slave从一个executor增加到两个，就能解决job并发量的问题。

S6、定时扫描清理slaves上的废弃jobs的遗留workspace；

要解决Slaves上遗留的编译workspace的问题，需要定时扫描Slave上的workspace。

在使用过程中，有一定几率会出现频繁的重命名job，如果把job重命名了，原来的编译空间就留下来了，出现了闲置，在扫描Slave上的workspace时，重点扫描重命名job，把workspace清理掉。

S7、业务jobs配置workspace清理规则；

考虑到特殊的业务场景和编译的时间特别长，中间有一些编译缓存，如ccache，保留的话对下次构建的编译速度上是有很大提高的，在配置清理规则的时候，没有完全清理，而是保留了需要的，其它的都被清理掉。

实施例2

请参阅图1、图2、图3、图4和图6，本申请提供了一种基于Kubernetes的持续集成持续交付的方法，包括以下步骤：

S1、交付CI/CD-Master到Kubernetes中；

第一步，设计Dockerfile：

根据所在公司的业务流程，定制一个实例，这样可以将一些插件打包在自定义的实质，在数据存储服务器中开辟一个新的空间，通过NFS的技术手段存储配置数据；

第二步，Dockerlmage制作：

根据第一步中设计的Dockerfile构建自定义镜像；

第三步，搭建Docker私有仓库：：

Docker镜像仓库默认为开放云平台的DockerHub，因自己公司所打包的自定义Dockerlmage中包含自定义应用或则机密信息，所以要搭建自己的私有仓库来存储自定义镜像以及应用镜像，以便于安全快速的拉取镜像至服务器中启动相应应用程序；

第四步，设置ENV(镜像环境变量)

配置镜像环境变量，例如时区环境变量；

第五步，启动参数；

Linux下内核参数的优化；

第六步，构建CI/CD Master Deployment：

Master镜像自定义构建完成，将Master服务以Deployment的方式部署至kubernetes集群中，利用Kubernetes集群特性，当Master所在POD发生异常导致不可用，集群中会再次立即自动启动一个Master来支撑CI/CD的可用性。

S2、CI/CD-Slave镜像定制构建；

第一步，Baselmage：

根据所在公司业务系统运行环境，选择CI/CD基础镜像版本；

第二步，Maven Plugin：

将项目启动所用到的Maven工具添加到Baselmage中，并添加环境变量以供编译调用；

第三步，Node Plugin：

将项目启动所用到的Node工具添加到Baselmage中，并添加环境变量以供编译调用；

第四步，Python Plugin：

将项目启动所用到的Python工具添加到Baselmage中，并添加环境变量以供编译调用；

第五步，其他开发工具添加至基础景象中，已满足所有业务编译打包部署需求；

第六步，CI/CD Slave Dockerfile：

整合业务中所使用到的所有开发插件至Dockerfile中，构建镜像并将镜像上传至私有Docker仓库中以供集群化部署应用程序快速拉取镜像启动CI/CD Slave节点。

S3、交付CI/CD-Slave到Kubernetes中；

将CI/CD Dockerfile构建的景象结合deployment，配置到CI/CD集群中，根据部署需要将自动调用JNLP的连接方式与Master连接通讯，极大的提高集群的灵活性与发布效率。

S4、同质slaves添加相同Label，同类型jobs使用Label进行构建；

同质Slaves添加相同Lable，用Lable来管理Slaves，同一套产品，把同质Slaves通过Lable使用，同类型jobs可以使用Lable进行构建。

S5、增大slave的executor数目；

增大executor数目，会增大并发量。编译相当于我们用物理机24线程并发去跑，根据不同的业务的场景，增加不同数量的并发量。

比如原来一个物理机只配一个，根据有的产品线的job没有消耗那么多的CPU、memory，编译时间要求不高，有一些Slave从一个executor增加到两个，就能解决job并发量的问题。

S6、定时扫描清理slaves上的废弃jobs的遗留workspace；

要解决Slaves上遗留的编译workspace的问题，需要定时扫描Slave上的workspace。

从业务job配置上，要配置相应的workspace清理规则；编译结束了，传到版本服务器或者制品仓库，workspace出现了闲置，可以在构建结束后就配置相应的清理规则，在扫描Slave上的workspace时，重点扫描配置相应的workspace，把workspace清理掉，这样Slave上的空间就被及时释放了，而不会等到下一次构建的时候由于空间不足导致的失败。

S7、业务jobs配置workspace清理规则；

考虑到特殊的业务场景和编译的时间特别长，中间有一些编译缓存，如ccache，保留的话对下次构建的编译速度上是有很大提高的，在配置清理规则的时候，没有完全清理，而是保留了需要的，其它的都被清理掉。

具体的，该一种基于Kubernetes的持续集成持续交付的方法的工作原理：使用时，定时扫描Slave上的workspace，解决Slaves上遗留的闲置编译workspace的问题，减少了空间不足造成的构建失败减少；

通过上述设计的一种基于Kubernetes的持续集成持续交付的方法，并发能力增强，Master存活率强来自于使用Kubernetes集群管理CI/CD Master POD，用Lable去管理了CI/CD集群Slave POD，本身Lable关联了多个Slave，这个就相当于Slave构成了一个资源池，并发能力就提高了。带来的直接效果，并发能力强，队列中构建任务等待的数目就下降了。Slave整体的空间利用率有效提高，这方面做了一些清理，空间不足造成的构建失败大大减少。整个集群，通过Lable管理，综合利用率提高了，反应到Disk和CPU上使用均衡，保持相对合理水平。

需要说明的是：Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器或Windows机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。

本发明中，采用Docker特性，将持续集成持续部署的应用程序打包到可移植的容器中，使用Kubernetes容器编排引擎管理。

CI/CD中的“CI”始终指持续集成，它属于开发人员的自动化流程。成功的CI意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。

CI/CD中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。

持续交付通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库(如GitHub或容器注册表)，然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。

持续部署(另一种“CD”)指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。持续部署以持续交付的优势为根基，实现了管道后续阶段的自动化。

CI/CD既可能仅指持续集成和持续交付构成的关联环节，也可以指持续集成、持续交付和持续部署这三项构成的关联环节。更为复杂的是，有时“持续交付”也包含了持续部署流程。

workspace：暂存器，是用来暂存由数据总线或通用寄存的东西；

Master：主机，有权优先访问或处理数据；

Slave：从机，围绕Master服务。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。