本分分享 GitLab CI/CD Job 不工作的的故障排查方法：当 GitLab Runner 不接受 Job，Job 一直处于等待状态，如何解决此问题。
极狐GitLab 为 GitLab 在中国的发行版，中文版本对中国用户更友好。极狐GitLab 支持一键私有化部署，可以在 ubuntu、centos、Debian、Docker、Kubernetes 上灵活安装。安装详情可以查看极狐GitLab 官网。
故障背景
使用 Helm 安装了一个极狐GitLab Runner，从 Runner 的管理界面看 Runner 处于工作状态
在 Kubernetes 后台查看，Runner 的运行也正常
kubectl -n jh-gitlab-runner get pods
NAME READY STATUS RESTARTS AGE
jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm 1/1 Running 0 157m
在项目中添加 .gitlab-ci.yml文件后，自动触发了 CI/CD 流水线，但是 Job 却一直处在等待状态
故障排查
起初没有在意这个状态，因为自部署的 runner，有时候刚开始是会出现等待中的状态，但是等了一会儿发现不对劲，一直在等待，查看 kubernetes 后台，也没见运行 Job 的动态 pod 生成。于是查看 Runner 的 pod 日志，也没发现异常：
kubectl -n jh-gitlab-runner logs -f jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm
Added job to processing list builds=1 job=7 max_builds=10 project=2 repo_url=http://jhma.jihulab.net/root/kubernetes-agent.git time_in_queue_seconds=15
Appending trace to coordinator...ok code=202 job=7 job-log=0-805 job-status=running runner=xRnstJB7U sent-log=0-804 status=202 Accepted update-interval=1m0s
Job succeeded duration_s=9.472339120000001 job=7 project=2 runner=xRnstJB7U
Appending trace to coordinator...ok code=202 job=7 job-log=0-2737 job-status=running runner=xRnstJB7U sent-log=805-2736 status=202 Accepted update-interval=1m0s
Updating job... bytesize=2737 checksum=crc32:2043b475 job=7 runner=xRnstJB7U
Submitting job to coordinator...ok bytesize=2737 checksum=crc32:2043b475 code=200 job=7 job-status=success runner=xRnstJB7U update-interval=0s
Removed job from processing list builds=0 job=7 max_builds=10 project=2 repo_url=http://jhma.jihulab.net/root/kubernetes-agent.git time_in_queue_seconds=15
然后怀疑是 Runner 突然“卡壳”，用 SRE 的行为准则对 Runner 进行了重启，重启之后还是一样的效果。这时候突然，脑子里灵光一现 Runner 是否接受 Job，是有一个标签选项的。标签选项是 Runner 的一个重要功能，主要是方便用户自行分配 Runner 的使用，这样就能让 Runner 的使用效率变得更高。
于是点击查看了 Runner 的配置，一看配置还真是：
有一个选项运行未打标签的作业，这个选项并未勾选。根据字面意思就能理解这个选项的重要性了：如果这个选项未勾选，那么 Runner 就不会运行没有打标签的 Job，说直白点就是，如果你的 .gitlab-ci.yml文件中用到了 tag 这个关键字，那么就意味着你的 CI/CD 使用了标签。这个标签要和 Runner 严格匹配，Runner 才会执行此作业。
我查看了一下 .gitlab-ci.yml文件中的描述，并没有使用 tag，也就是说没有使用标签。这个时候就确定了，该问题就是由于此选项没有勾线所致，因此立马勾选了此选项，然后进行了配置保存。
然后就看到 Job 开始运行了，并且运行成功
在 Kubernetes 后台也看到了动态生成了 pod，然后执行完 Job 之后，pod 自动被删除
kubectl -n jh-gitlab-runner get pods
NAME READY STATUS RESTARTS AGE
jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm 1/1 Running 0 20m
runner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 0/2 Init:0/1 0 1s
root@xiaomage:/home/xiaomage/runner# kubectl -n jh-gitlab-runner get pods
NAME READY STATUS RESTARTS AGE
jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm 1/1 Running 0 20m
runner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 0/2 PodInitializing 0 2s
root@xiaomage:/home/xiaomage/runner# kubectl -n jh-gitlab-runner get pods
NAME READY STATUS RESTARTS AGE
jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm 1/1 Running 0 20m
runner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 0/2 PodInitializing 0 3s
root@xiaomage:/home/xiaomage/runner# kubectl -n jh-gitlab-runner get pods -w
NAME READY STATUS RESTARTS AGE
jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm 1/1 Running 0 20m
runner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 0/2 PodInitializing 0 4s
runner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 2/2 Running 0 4srunner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 2/2 Terminating 0 9s
^Croot@xiaomage:/home/xiaomage/runner# kubectl -n jh-gitlab-runner get pods
NAME READY STATUS RESTARTS AGE
jh-gitlab-runner-gitlab-runner-5c558fb88b-lnfxm 1/1 Running 0 21m
runner-xrnstjb7u-project-2-concurrent-0-y0idxyf2 2/2 Terminating 0 25s
故障总结
Runner 对于极狐GitLab CI/CD 来讲是非常重要的，很多时候自建的 Runner 能够有更大的灵活性来运行流水线，但是往往一个小小的配置就能够阻塞整个工作，排查的过程还是要有章法，首先应该从配置入手，查看有些配置是否正确，其次要多看日志，从日志中发现问题，最后也是最重要的多看官网文档、多练习，只有对 GitLab 懂的越多，故障排查也才越快。
