如何强制gitlab-runner仅使用kubernetes执行器

同机部署的Runner出现不同项目调度到不同执行器的问题，核心原因是机器上注册了多个绑定不同执行器的Runner实例，且这些实例的标签和项目CI配置的调度规则匹配，GitLab CI会在符合标签的Runner池里随机分配任务，和.gitlab-ci.yml的其他配置无关，可通过以下三层配置彻底锁定执行器：

1. 清理冗余的非Kubernetes执行器Runner实例 #

• 登录Runner所在宿主机，执行sudo gitlab-runner list查看所有已注册的Runner条目，逐条核对Executor字段
• 先执行sudo gitlab-runner verify --delete清理所有失联、无效的Runner注册记录
• 对所有Executor字段为docker+machine、docker、shell等非Kubernetes类型的Runner，执行sudo gitlab-runner unregister --name <目标Runner的名称>逐个注销
• 确认列表剩余的所有Runner条目Executor均为kubernetes后，执行sudo systemctl restart gitlab-runner重启服务生效

这是该问题最高发的诱因：多数运维会在同一台宿主机上多次注册Runner时选择不同执行器，只要标签重合就会被随机调度，和项目CI脚本本身无关。

2. 通过标签+权限规则强制调度到K8s Runner #

如果暂时不方便注销其他执行器的Runner，可通过标签规则强制任务只分配给K8s执行器的Runner：

• 编辑Runner配置文件/etc/gitlab-runner/config.toml，找到K8s执行器对应的Runner配置段，在tag_list字段添加专属唯一标签，比如k8s-only，确保其他非K8s Runner没有配置这个标签
• 两种方式强制任务匹配该标签：
  • 项目侧：在两个项目的.gitlab-ci.yml全局配置中指定标签，所有Job默认继承该调度规则：

    default:
      tags:
        - k8s-only
    

  • 平台侧：登录GitLab管理后台，找到所有非K8s执行器的Runner，直接设置为「暂停」状态，或者取消这些Runner对目标项目的访问授权，从调度入口阻断其承接任务的可能。

3. 配置文件层面锁定仅保留K8s执行器能力 #

• 打开/etc/gitlab-runner/config.toml，逐段检查所有Runner的配置块，删除所有非K8s执行器对应的配置段，包括[runners.docker]、[runners.machine]这类和docker+machine执行器相关的配置，仅保留[runners.kubernetes]配置块
• 在[runners.kubernetes]段内固定好你需要的集群配置、镜像拉取策略、资源限制等参数，避免配置缺省导致的调度 fallback
• 执行sudo gitlab-runner config check校验配置合法性，无报错后重启GitLab Runner服务即可。

效果验证 #

配置完成后分别在两个项目触发测试CI任务，进入任务详情页查看Runner信息，确认执行器显示为kubernetes；也可在Runner宿主机执行sudo journalctl -u gitlab-runner -f查看实时日志，确认任务触发时走的是K8s Pod创建逻辑，没有调用docker-machine相关的创建流程。

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