K8s部署GitLab Runner CI报等待ServiceAccount超时问题咨询

问题现象 #

通过Helm Charts将GitLab Runner部署到Kubernetes集群，期望CI任务触发创建的构建Pod使用自定义ServiceAccount而非默认账号，已提前完成Role、ClusterRole创建及对应RoleBinding绑定配置，但CI任务运行时抛出系统故障报错。

CI任务报错日志 #

Running with gitlab-runner 15.0.0 (cetx4b)
  on initial-runner -P-d1RhT
Preparing the "kubernetes" executor
00:00
Using Kubernetes namespace: namespace_test
Using Kubernetes executor with image registry.gitlab.com/docker-images/ubuntu-base:latest ...
Using attach strategy to execute scripts...
Preparing environment
00:05
ERROR: Job failed (system failure): prepare environment: setting up build pod: Timed out while waiting for ServiceAccount/gitlab-runner to be present in the cluster. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information

资源核查结果 #

执行命令查询目标命名空间下的角色绑定：

kubectl get rolebindings,clusterrolebindings -n namespace_test | grep gitlab-runner

输出如下，确认绑定关系存在：

rolebinding.rbac.authorization.k8s.io/gitlab-runner             Role/gitlab-runner
clusterrolebinding.rbac.authorization.k8s.io/gitlab-runner      ClusterRole/gitlab-runner

执行命令查询目标命名空间下的ServiceAccount：

kubectl get serviceaccounts -n namespace_test

输出如下，确认gitlab-runner ServiceAccount已存在：

NAME                   SECRETS   AGE
default                1         6h50m
gitlab-runner          1         24m
kubernetes-dashboard   1         6h50m
mysql                  2         6h49m

当前Helm Values配置 #

runners:
  concurrent: 8
  name: initial-runner
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "namespace_test"
        image = "registry.gitlab.com/docker-images/ubuntu-base:latest"
        service_account = "gitlab-runner"
  tags: base

rbac:
  create: false
  serviceAccountName: gitlab-runner

根因分析 #

报错的核心原因是GitLab Runner自身使用的ServiceAccount缺少目标命名空间下ServiceAccount资源的读取权限：
GitLab Runner的Kubernetes执行器在创建构建Pod前，会主动调用Kubernetes API轮询检查配置的构建Pod所用ServiceAccount是否存在。由于配置中关闭了Helm自动创建RBAC规则的能力（rbac.create: false），手动创建的Role/ClusterRole未给gitlab-runner ServiceAccount授予serviceaccounts资源的get/list/watch权限，所有查询ServiceAccount的API请求都会被Kubernetes鉴权模块拒绝。Runner无法获取ServiceAccount存在的响应，会持续轮询直到触发超时，最终抛出对应报错，该问题与ServiceAccount本身是否已创建无关。

修复方案 #

• 补全RBAC权限规则：在namespace_test命名空间下绑定给gitlab-runner的Role中增加如下权限规则，如果GitLab Runner部署在其他命名空间，还需要同步在绑定的ClusterRole中添加相同规则：

rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get", "list", "watch"]
# 保留原有其他权限规则

• 应用更新后的RBAC配置，重启GitLab Runner Pod使新权限生效。
• 权限校验：执行如下命令验证权限配置是否正确，返回yes即为配置生效：

# 替换<runner-namespace>为GitLab Runner实际部署的命名空间
kubectl auth can-i get serviceaccounts -n namespace_test --as=system:serviceaccount:<runner-namespace>:gitlab-runner

内容的提问来源于stack exchange，提问作者Kingindanord