本分分享 GitLab CI/CD Job 不工作的的故障排查方法：當 GitLab Runner 不接受 Job，Job 一直處於等待狀態，如何解決此問題。
極狐GitLab 為 GitLab在中國的發行版，中文版本對於中國開發者更友好，和 GitLab 一樣，極狐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 4s
runner-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 懂的越多，故障排查也才越快。