之前我们都是在物理机或者虚拟机上部署jenkins，但是这种部署方式会有一些难点，如下：
主 master 发生单点故障时，整个流程都不可用了
每个 slave 的配置环境不一样，来完成不同语言的编译打包等操作，但是这些差异化的配置导致管理起来非常不方便，维护起来也是比较费劲
资源分配不均衡，有的 slave 要运行的 job 出现排队等待，而有的 slave 处于空闲状态
资源有浪费，每台 slave 可能是物理机或者虚拟机，当 slave 处于空闲状态时，也不会完全释放掉资源。
正因为上面的这些种种痛点，我们渴望一种更高效更可靠的方式来完成这个 ci/cd 流程，而 docker 虚拟化容器技术能很好的解决这个痛点，又特别是在 kubernetes 集群环境下面能够更好来解决上面的问题，下图是基于 kubernetes 搭建 jenkins 集群的简单示意图：
从图上可以看到 jenkins master 和 jenkins slave 以 pod 形式运行在 kubernetes 集群的 node 上，master 运行在其中一个节点，并且将其配置数据存储到一个 volume 上去，slave 运行在各个节点上，并且它不是一直处于运行状态，它会按照需求动态的创建并自动删除。
这种方式的工作流程大致为：当 jenkins master 接受到 build 请求时，会根据配置的 label 动态创建一个运行在 pod 中的 jenkins slave 并注册到 master 上，当运行完 job 后，这个 slave 会被注销并且这个 pod 也会自动删除，恢复到最初状态。
这种方式部署给我们带来如下好处：
服务高可用，当 jenkins master 出现故障时，kubernetes 会自动创建一个新的 jenkins master 容器，并且将 volume 分配给新创建的容器，保证数据不丢失，从而达到集群服务高可用。
动态伸缩，合理使用资源，每次运行 job 时，会自动创建一个 jenkins slave，job 完成后，slave 自动注销并删除容器，资源自动释放，而且 kubernetes 会根据每个资源的使用情况，动态分配 slave 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。
扩展性好，当 kubernetes 集群的资源严重不足而导致 job 排队等待时，可以很容易的添加一个 kubernetes node 到集群中，从而实现扩展。
1、创建pv、pvc，为jenkins提供数据持久化：
2、创建角色授权
1、在kubernetes中部署jenkins，新建deployment，jenkins-deploy.yaml
5、创建上面的资源清单
启动如果报如下错误（因为我们容器里是以jenkins用户启动，而我们nfs服务器上是root启动，所以没有权限）：
然后给我们nfs服务器上的目录授权即可：
然后登录网站，因为我们service是采用nodeport类型，其端口为30002，我们直接在浏览器用这个端口访问：
密码可以通过如下命令获得：
然后安装插件到安装完成。
1、安装插件kubernetes
2、填写kubernetes和jenkins的配置信息
配置管理->系统配置->新增cloud。
按照图中红色框中填写，其中kubernetes命名空间填写我们jenkins所在的命名空间。
备注：
如果连接测试失败，很可能是权限问题，我们就需要把serviceaccount的凭证jenkins-sa添加进来。
3、配置pod模板
另外需要挂载两个主机目录：
/var/run/docker.sock：该文件是用于 pod 中的容器能够共享宿主机的 docker；
/root/.kube：这个目录挂载到容器的/root/.kube目录下面这是为了让我们能够在 pod 的容器中能够使用 kubectl 工具来访问我们的 kubernetes 集群，方便我们后面在 slave pod 部署 kubernetes 应用；
避免一些权限不足，需要配置serviceaccount
1、创建一个项目
2、在标签位置填写我们前面模板中定义的label
3、直接在构建处执行shell进行测试
然后点击构建，在终端可以看到整个过程：
也可以在jenkins里看日志如下：
pipeline，简单来说，就是一套运行在 jenkins 上的工作流框架，将原来独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排和可视化的工作。
jenkins pipeline 有几个核心概念：
node：节点，一个 node 就是一个 jenkins 节点，master 或者 agent，是执行 step 的具体运行环境，比如我们之前动态运行的 jenkins slave 就是一个 node 节点
stage：阶段，一个 pipeline 可以划分为若干个 stage，每个 stage 代表一组操作，比如：build、test、deploy，stage 是一个逻辑分组的概念，可以跨多个 node
step：步骤，step 是最基本的操作单元，可以是打印一句话，也可以是构建一个 docker 镜像，由各类 jenkins 插件提供，比如命令：sh 'make'，就相当于我们平时 shell 终端中执行 make 命令一样。
pipeline的使用：
pipeline 脚本是由 groovy 语言实现的
pipeline 支持两种语法：declarative(声明式)和 scripted pipeline(脚本式)语法
pipeline 也有两种创建方法：可以直接在 jenkins 的 web ui 界面中输入脚本；也可以通过创建一个 jenkinsfile 脚本文件放入项目源码库中
一般我们都推荐在 jenkins 中直接从源代码控制(scmd)中直接载入 jenkinsfile pipeline 这种方法
2.2.1、简单的pipeline
直接 在jenkins的web ui上输入脚本。
脚本内容：
然后保存--> 点击构建--> 观察日志
输出符合我们脚本内容。
2.2.2、在slave中运行pipeline
上面对jenkins的pipeline做了简单的测试，但是其并未在我们的slave中运行，如果要在slave中运行，其就要使用我们前面添加的label，如下：
然后我们保存并点击构建，观察pod的变化：
我们可以看到其依据我们定义的模板动态生成了jenkins-slave的pod，我们在jenkins的日志中查看：
可以看到两个的名字是一样的。
部署应用的流程如下：
编写代码
测试
编写 dockerfile
构建打包 docker 镜像
推送 docker 镜像到仓库
编写 kubernetes yaml 文件
更改 yaml 文件中 docker 镜像 tag
利用 kubectl 工具部署应用
所以基本的pipeline脚本框架应该如下：
第一步：克隆代码
我们这里采用和git commit的记录为镜像的 tag，这里有一个好处就是镜像的 tag 可以和 git 提交记录对应起来，也方便日后对应查看。但是由于这个 tag 不只是我们这一个 stage 需要使用，下一个推送镜像是不是也需要，所以这里我们把这个 tag 编写成一个公共的参数，把它放在 clone 这个 stage 中。
第二步：测试
测试可以是单测，也可以是工具，我们这里就简单存在这个步骤。
第三步：构建镜像
这一步我们就使用到上面定义的build_tag变量。
第四步：推送镜像
配置jenkins，隐藏用户名密码信息：
其中id：aliregistry 是我们后面要用的值。
这样我们上面的脚本就可以定义如下：
注意我们这里在 stage 中使用了一个新的函数withcredentials，其中有一个 credentialsid 值就是我们刚刚创建的 id 值，而对应的用户名变量就是 id 值加上 user，密码变量就是 id 值加上 password，然后我们就可以在脚本中直接使用这里两个变量值来直接替换掉之前的登录 docker hub 的用户名和密码，现在是不是就很安全了，我只是传递进去了两个变量而已，别人并不知道我的真正用户名和密码，只有我们自己的 jenkins 平台上添加的才知道。
第五步：更改yaml文件
其yaml文件为（yaml文件放在项目根目录）：
第六步：部署
部署阶段我们增加人工干预，可能需要将该版本先发布到测试环境、qa 环境、或者预览环境之类的，总之直接就发布到线上环境去还是挺少见的，所以我们需要增加人工确认的环节，一般都是在 cd 的环节才需要人工干预，比如我们这里的最后两步，我们就可以在前面加上确认，比如：
我们将yaml这一步改为：
然后再部署阶段：
由于这一步也属于部署的范畴，所以我们可以将最后两步都合并成一步,我们最终的pipeline脚本如下：
然后构建面板如下：
然后查看pod日志如下：
2.2.4、jenkinsfile
万里长征，貌似我们的任务完成了，其实不然，我们这里只是完成了一次手动的添加任务的构建过程，在实际的工作实践中，我们更多的是将 pipeline 脚本写入到 jenkinsfile 文件中，然后和代码一起提交到代码仓库中进行版本管理。现在我们将上面的 pipeline 脚本拷贝到一个 jenkinsfile 中，将该文件放入上面的 git 仓库中，但是要注意的是，现在既然我们已经在 git 仓库中了，是不是就不需要 git clone 这一步骤了，所以我们需要将第一步 clone 操作中的 git clone 这一步去掉。
如下：
然后我们更改上面的 jenkins-demo 这个任务，点击 configure -> 最下方的 pipeline 区域 -> 将之前的 pipeline script 更改成 pipeline script from scm，然后根据我们的实际情况填写上对应
的仓库配置，要注意 jenkinsfile 脚本路径。
在实际的项目中，往往一个代码仓库都会有很多分支的，比如开发、测试、线上这些分支都是分开的，一般情况下开发或者测试的分支我们希望提交代码后就直接进行 ci/cd 操作，而线上的话最好增加一个人工干预的步骤，这就需要 jenkins 对代码仓库有多分支的支持，当然这个特性是被 jenkins 支持的。
然后新建一个 jenkinsfile 文件，配置如下：
在第一步中我们增加了checkout scm命令，用来检出代码仓库中当前分支的代码，为了避免各个环境的镜像 tag 产生冲突，我们为非 master 分支的代码构建的镜像增加了一个分支的前缀，在第五步中如果是 master 分支的话我们才增加一个确认部署的流程，其他分支都自动部署，并且还需要替换 k8s.yaml 文件中的环境变量的值。
我们这里使用 blueocean 这种方式来完成此处 ci/cd 的工作，blueocean 是 jenkins 团队从用户体验角度出发，专为 jenkins pipeline 重新设计的一套 ui 界面，仍然兼容以前的 fressstyle 类型的 job，blueocean 具有以下的一些特性：
连续交付（cd）pipeline 的复杂可视化，允许快速直观的了解 pipeline 的状态
可以通过 pipeline 编辑器直观的创建 pipeline
需要干预或者出现问题时快速定位，blueocean 显示了 pipeline 需要注意的地方，便于异常处理和提高生产力
用于分支和拉取请求的本地集成可以在 github 或者 bitbucket 中与其他人进行代码协作时最大限度提高开发人员的生产力。
blueocean 可以安装在现有的 jenkins 环境中，也可以使用 docker 镜像的方式直接运行，我们这里直接在现有的 jenkins 环境中安装 blueocean 插件：登录 jenkins web ui -> 点击左侧的 manage jenkins -> manage plugins -> available -> 搜索查找 blueocean -> 点击下载安装并重启
点击创建：
获取token的步骤：
然后获取token：
创建完成如下所示：
完