现在去交付微服务到k8s中举个demo仅供参考
一、发布流程设计 二、准备基础环境 三、在Kubernetes中部署jenkins 四、jenkins pipeline及参数化构建 五、jenkins在k8s中动态创建代理 六、自定义构建jenkins-slave镜像 七、基于kubernetes构建jenkins ci系统 八、pipeline集成helm发布spring cloud微服务
一、传统的发布流程是怎么样的？
现在的这个发布流程设计还是要和自己的项目中去考量，布置一个大体的拓扑图，那么比如没有这样的场景jenkins去发布微服务，它是一个怎么样的流程，作为运维来讲首先要去拉代码，开发已经将这个项目开发好了，并推送到git仓库中或者部署的私有的gitlab代码仓库中，第一步做的就是将这个代码拉下来，拉完代码，一般代码都是Java应用，会设计到一个编译，编译出来一个可部署的包，一般微服务是jar包，或者直接启动的应用程序，然后就开始去封装这个服务了，一般就是将这个jar包或者应用程序，通过dockerfile去达成一个可部署的镜像，这个镜像一般会自己制作jdk环境，或者就是jre环境，就是基础镜像能够运行这个镜像的底包，最后一步就是部署到k8s中，这里就会写一些yaml文件了去把这个镜像部署到k8s中，也就是容器的编排，另外还要考虑怎么将这个应用暴露出去，让用户访问到。
使用jenkins自动话发布的流程是这么样的？
显然这种方式发布多个微服务很不高效，所以就需要ci/cd，这么一说，那么有jenkins了，怎么将这种方式自动化起来，减少人工的干预。
上面那张图，首先是这样的，开发将代码推送到git仓库中，通过commit提交上去，然后再到jenkins了，它负责的任务就是checkout代码的拉取，code compile代码的编译，docker build &push ，镜像的构建与推送到harbor仓库中，然后deploy，将应用部署到k8s中，这里呢由于可能是很多的微服务，那么我们就需要模版的代替，去发布微服务，这里我们就会需要用到它原生的helm微服务发布工具来到k8s当中去deploy，发布到测试环境中去，然后通过slb提供一个统一的出口，发布出去，中间产生的镜像也都会存放到harbor仓库中，当QA测试没有问题，这个镜像也就可以去发布生产环境中。
为什么需要jenkins slave架构
另外这里还提到了一个jenkins，slave的一个架构，主要的是可以动态的可以完成这些任务，动态的去调度一个机器和一个pod来完成这几步的任务，因为当任务很多时，也就是都在jenkins master去做，显然任务多了负载就高了，所以就需要引入这个slave去解决这个问题。
二、准备基础环境，所需的组件来完成我们流程的发布
1、k8s——（ingress controller、coredns、pv自动供给） 2、harbor,并启用chart存储功能，将我们的helm打成chart并存放到harbor中 3、helm-v3 工具，主要来实现模版化，动态的将应用渲染安装与卸载，更好的去管理微服务 4、gitlab代码仓库，docker-compose实现 5、MySQL，微服务数据库 6、在k8s中部署eureka（注册中心）1、检查k8s基础组件的环境是否安装：
1、默认我的这个基础的组件都是安装好的，ingress 和coredns