GitLab Runner拉取Nexus镜像时流水线报错“unable to upgrade connection: container not found ('build')”，是否为配置缺失问题？

我在Nexus仓库中有2个镜像，希望通过GitLab Runner逐个拉取并扫描，但第一条流水线执行时出现报错，怀疑是GitLab配置缺失导致。

错误信息 #

Created fresh repository.
Checking out 0190bbde as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script 30:01
Cleaning up file based variables 30:00
ERROR: Job failed (system failure): unable to upgrade connection: container not found ("build")

当前.gitlab-ci.yml配置 #

stages:
  - build
  - test
scan-image:
  stage: build
  image: $CI_REGISTRY/devops/grype/grype:0.23
  # name: $CI_REGISTRY/grype:0.23
  # entrypoint: [""]
  variables:
    DOCKER_TLS_CERTDIR: ""
    DOCKER_HOST: tcp://localhost:2375
  services:
    - $CI_REGISTRY/devops/docker:dind-nx1.0
  tags:
    - k8s
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker pull $CI_REGISTRY/devops/grype/grype:0.23
    #- grype $CI_REGISTRY/devops/docker:latest
    #- grype $CI_REGISTRY/trivy-db:v1-2021101500
download-image:
  stage: test
  image: $CI_REGISTRY/devops/docker:latest
  variables:
    DOCKER_TLS_CERTDIR: ""
    DOCKER_HOST: tcp://localhost:2375
  services:
    - $CI_REGISTRY/devops/docker:dind-nx1.0
  tags:
    - k8s
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker pull $CI_REGISTRY/trivy-db:v1-2021101500
    - grype $CI_REGISTRY/trivy-db:v1-2021101500

这个报错unable to upgrade connection: container not found ("build")在K8s环境的GitLab Runner中很常见，大概率和配置缺失或容器生命周期问题有关，以下是具体排查方向：

1. 检查K8s Runner的容器命名配置 #

当使用K8s executor时，GitLab Runner默认会用build作为主作业容器的名称，但如果你的runner配置中修改了container_name参数，或者镜像本身的entrypoint导致容器提前退出，就会出现找不到容器的情况：

• 登录GitLab查看该K8s runner的配置，确认是否有自定义container_name，如果有，需要确保和作业中引用的名称一致；
• 取消注释entrypoint: [""]试试，有些镜像的默认entrypoint会导致容器启动后直接退出，无法维持会话。

2. 修正DIND服务的配置 #

在K8s环境中使用Docker-in-Docker（DIND），需要确保服务配置正确：

• 给DIND服务添加特权模式：在services里补充privileged: true，因为DIND需要特权才能正常运行，示例如下：

  services:
    - name: $CI_REGISTRY/devops/docker:dind-nx1.0
      privileged: true
  

• 确认DOCKER_TLS_CERTDIR和DOCKER_HOST的设置匹配，虽然你已经设置了DOCKER_TLS_CERTDIR: ""禁用TLS，但要确保DIND镜像启动时没有强制启用TLS。

3. 验证镜像的可访问性与权限 #

• 检查$CI_REGISTRY/devops/grype/grype:0.23这个镜像是否存在，并且GitLab Runner使用的CI_REGISTRY_USER账号有拉取该镜像的权限；
• 可以在本地环境先尝试拉取该镜像，确认镜像本身没有损坏，启动后能正常进入bash会话。

4. 检查GitLab Runner的K8s权限 #

如果Runner绑定的K8s服务账号没有足够的权限操作容器（比如查看、连接容器），也会触发这个错误：

• 确认Runner所在命名空间的ServiceAccount拥有pods/exec、pods/get等相关权限；
• 查看该命名空间下的Role和RoleBinding配置，确保权限覆盖了作业所需的容器操作。

5. 简化作业配置定位问题 #

先把scan-image作业简化，去掉不必要的步骤，确认容器能正常运行：

scan-image:
  stage: build
  image: $CI_REGISTRY/devops/grype/grype:0.23
  entrypoint: [""]
  tags:
    - k8s
  script:
    - echo "Hello World"

如果这个简化后的作业能成功执行，再逐步添加before_script、services等配置，定位具体是哪部分配置出现了问题。

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