kubernetes(k8s)Gitlab CI转轮的安装
乔布斯-& gt；阶段->；管道
一个管道其实相当于一个构造任务，可以包含很多流程，比如安装依赖项、运行测试、编译、部署测试服务器、部署生产服务器等等。mergerrequest的任何提交或合并都会触发管道构建，如下图所示:
Stages代表一个构建阶段，也就是上面提到的过程。您可以在管道中定义多个阶段，这些阶段将具有以下特征:
阶段和管道之间的关系如下:
Jobs代表建筑工作，意思是在一个阶段中完成的工作。您可以分阶段定义多个作业，这些作业将具有以下特征:
作业和阶段之间的关系如下:
如果我们理解了上面的基本概念，我们可能会发现一个问题，我们的建设任务在哪里？在过去，Jenkins可以用于在主节点和从节点运行构建任务，并且是Gitlab Runner执行我们的Gitlab CI构建任务。
我们知道，在大多数情况下，构建任务会占用大量系统资源。如果构建任务直接由Gitlab自己运行，显然Gitlab的性能会大打折扣。GitLab CI最大的作用就是管理每个项目的施工状态。所以把跑构造任务等资源浪费的事情留给独立的Gitlab跑者会好很多。更重要的是，Gitlab Runner可以安装在不同的机器上，甚至是我们自己的机器上，完全不会影响Gitlab本身。
安装Gitlab Runner非常简单。我们完全可以安装官方文档:/runner/install/。比如我们可以直接用binary，Docker等。同样，我们这里还是把Gitlab Runner安装到Kubernetes集群中，让我们的集群统一管理Gitlab相关的服务。
1.验证Kubernetes集群
执行以下命令来验证Kubernetes集群:
cluster-info命令显示当前链路的集群状态和可用集群服务的列表。
2.获取Gitlab CI注册令牌
Gitlab在上一节已经安装成功。在浏览器中打开hwzxgit.sinoing.net页面，然后登录管理页面/admin，再点击导航栏中的Runner。可以看到这个页面有两个通用参数，一个是URL，一个是Register Token。以下步骤需要这两个参数值。
图1，
类似地，与Runner相关的所有资源对象都安装在名称空间kube-ops下。首先，环境变量(Runner-cm。Yaml)通过ConfigMap资源传递:
需要注意的是，CI_SERVER_URL对应的值需要指向Gitlab实例的URL(可以是外部网络地址，也可以是Kubernetes集群内部的服务DNS地址，因为Runner也运行在Kubernetes集群中)，并加上/ci (/ci)。此外，还增加了一些构建容器操作的资源限制，可以根据需要进行更改。
除了上述与一些环境变量相关的配置，您还需要一个小脚本来注册、运行和注销Gitlab CI Runner。只有当Pod被Kubernetes(TERM信号)正常终止时，才会触发车轮取消注册。如果Pod(SIGKILL信号)被强制终止，跑步者不会自行注销。你必须手动清理这个被杀死的跑步者。配置列表文件如下:(runner-scripts-cm.yaml)
可以看到需要一个GITLAB_CI_TOKEN，然后复制下图中的Gitlab CI runner token来创建一个Kubernetes secret对象。Base64编码标记:
然后，您可以使用Statefulset为实际运行的Runner编写一个控制器对象。第一，在运行初期，尝试注销所有同名的Runner，这在节点丢失(即NodeLost事件)时特别有用。然后尝试自己重新注册，开始跑步。正常停止Pod时，Runner会运行unregister命令试图取消自己，所以Gitlab不能再使用这个Runner，这是在Kubernetes Pod的生命周期中通过钩子完成的。
另外，通过使用envFrom将Secrets和ConfigMaps指定为环境变量，对应的资源列表文件如下:(runner-statefulset.yaml)。
可以看到我们使用了一个名为gitlab-ci的serviceAccount创建了一个新的rbac资源列表文件:(runner-rbac.yaml)。
4.创建一个Runner资源对象
准备好资源列表文件后，直接创建上面的资源对象:
创建完成后，您可以通过查看Pod状态来判断跑步者是否成功跑步:
可以看到Runner的两个实例已经成功运行(取决于StatefulSet列表中的副本数量)，然后切换到Gitlab管理页面下面的Runner页面:
至此，Gitlab CI Runner在kubernetes的安装结束。当然，Runner的一些配置可以根据需要进行更改，比如添加tag标签。