一、Jenkins是一个比较流行的持续集成工具
GitLab是管理代码创库
由客户端将代码push推送到git仓库，gitlab上配置了一个webHook的东西可以触发Jenkins的构建。进入到Jenkins虚线范围内，它所做的事情非常多，从mvn构建代码，对代码进行静态分析，做单元测试，测试通过之后就可以build镜像，镜像构建成功后就把镜像push推送到Harbor镜像仓库中，镜像push推送到镜像仓库后，我们就可以调用kubernetes集群的restAPI更新服务，而后kubernetes接收到了更新的指令，从Harbor镜像仓库pull拉取镜像，从而完成服务的更新与重启，最后我们从客户端来访问kubernetes集群的服务。
二、实现流程
1.开发从镜像库里获取基础镜像，对应用进行容器化开发；
2.开发提交代码到Gitlab（在Kubernetes中实现Gitlab服务，并通过持久化存储保存用户数据）；
3.Gitlab收到代码提交请求后通过webhook触发Jenkins master（Jenkins采用Master+Slave方式在Kubernetes平台上实现）；
4.Jenkins master收到请求后在Kubernetes平台上动态生成相应的业务节点（Jenkins通过配置的Kubernetes Plugin在Kubernetes平台上按需生成slave节点）；
5.Jenkins master在slave节点中对源码进行打包；
6.在源码打包完成后根据流水线，从Gitlab中获取dockerfile，在slave节点中生成docker images；
7.Docker镜像生成之后上传到Docker 私有仓库harbor；
8.通过Jenkins流水线在Kubernetes测试环境拉取镜像，部署应用；
9.测试成功之后，通过Jenkins流水线在Kubernetes生产环境进行应用的部署上线。
三、Jenkins采用Master+Slave方式在Kubernetes平台上实现
集群方式对比
传统的 Jenkins Slave 一主多从方式会存在一些痛点：
1.主 Master 发生单点故障时，整个流程都不可用了
2.每个 Slave 的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲
3.资源分配不均衡，有的 Slave 要运行的 job 出现排队等待，而有的 Slave 处于空闲状态
4.资源有浪费，每台 Slave 可能是物理机或者虚拟机，当 Slave 处于空闲状态时，也不会完全释放掉资源。
基于 Kubernetes 搭建 Jenkins 集群(Docker 虚拟化容器技术)
这种方式的工作流程大致为：当 Jenkins Master 接受到 Build 请求时，会根据配置的 Label 动态创建一个运行在 Docker Container 中的 Jenkins Slave 并注册到 Master 上，当运行完 Job 后，这个 Slave 会被注销并且 Docker Container 也会自动删除，恢复到最初状态。
1.服务高可用，当 Jenkins Master 出现故障时，Kubernetes 会自动创建一个新的 Jenkins Master 容器，并且将 Volume 分配给新创建的容器，保证数据不丢失，从而达到集群服务高可用。
2.动态伸缩，合理使用资源，每次运行 Job 时，会自动创建一个 Jenkins Slave，Job 完成后，Slave 自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个资源的使用情况，动态分配 Slave 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。
3.扩展性好，当 Kubernetes 集群的资源严重不足而导致 Job 排队等待时，可以很容易的添加一个 Kubernetes Node 到集群中，从而实现扩展。
缺点
1.jnlp-slave pod 无法删除
如果 jnlp-slave pod创建失败，它会不断的尝试创建新的pod，并试图连接jenkins，一段时间后，就会创造很多失败的jnlp-slave pod。如果遇到这种情况,需要尽早中断任务并删除失败的pod。（需要手动删除jnlp-slave pod）
