EKS部署的GitLab Runner执行docker build时构建环境无网络连接

你当前用的是Docker out of Docker (DooD) 构建模式：把节点上的/var/run/docker.sock挂载到Runner Pod里，让Pod内的docker客户端直接调用节点上的docker daemon跑构建。
之前做的连通性验证完全不覆盖build场景：

• docker login 只需要Runner Pod本身和镜像仓库建立连接、写入认证凭证，全程不会让节点上的docker daemon启动任何临时容器，所以这个命令成功只能证明Runner Pod自己网络正常，和build阶段的网络没有关联。
• 执行Dockerfile里的RUN指令时，节点上的docker daemon会拉起独立的临时构建容器跑命令，你看到容器里只有lo回环接口，说明这个临时容器根本没被分配虚拟网卡、没接入任何可用网络，问题出在节点侧docker的网络配置和EKS运行时环境不匹配。

最常见的触发原因：

• EKS 1.24及以上版本默认用containerd作为集群CRI运行时，节点上装的docker只是独立的边缘服务，默认没初始化docker0网桥、没配置容器转发的iptables规则，启动的容器默认只会带lo网卡，连不上外部网络
• 节点上的dockerd启动参数带了--bridge=none或者--iptables=false，禁止给容器创建veth网卡、配置流量转发规则
• 节点侧的安全组、VPC CNI/Calico网络策略拦截了docker bridge网段的流量，导致网卡创建流程失败

按顺序操作即可快速定位根因：

1. 登录出问题的EKS工作节点，直接执行docker run --rm ubuntu:16.04 ifconfig，如果返回结果同样只有lo接口，可确认是节点侧docker服务的网络配置问题，和Runner、GitLab配置无关。
2. 检查dockerd启动参数：执行ps aux | grep dockerd，看启动命令里有没有--bridge=none、--iptables=false这两个参数。
3. 检查docker0网桥状态：执行ip a show docker0，确认网桥是否存在、是否处于UP状态、有没有分配172.17.0.0/16段的IP。
4. 检查iptables转发规则：执行iptables -t nat -L POSTROUTING -n，确认有没有针对docker0网桥的MASQUERADE源地址转换规则。

按推荐优先级排序：

方案1：切换为Docker in Docker (DinD) 构建模式（最推荐，适配EKS环境无额外节点配置） #

直接弃用挂载宿主机docker.sock的DooD模式，用GitLab官方推荐的DinD侧车模式，docker daemon和构建容器都跑在Runner Pod的网络命名空间里，直接复用Pod的网络配置，完全不需要适配节点侧的docker网络，稳定性最高。
修改Runner Helm values配置：

runners:
  config: |
    [[runners]]
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:16.04"
        privileged = true # DinD模式必须开启特权权限
      [[runners.kubernetes.volumes.empty_dir]]
        name = "docker-certs"
        mount_path = "/certs"
        medium = "Memory"

同时在项目的.gitlab-ci.yml里调整构建任务配置：

build:
  stage: build
  image: docker:24.0.6-git
  services:
    - name: docker:24.0.6-dind
      command: ["--mtu=1500"] # MTU和EKS VPC CNI保持一致，避免大包传输异常
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_DRIVER: overlay2
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

方案2：修复节点侧docker网络配置（不推荐，需要逐节点维护） #

如果必须保留DooD模式，需要逐个修改EKS节点的docker配置：

1. 编辑/etc/docker/daemon.json，删除bridge: none、iptables: false配置项，添加以下配置：

{
  "iptables": true,
  "bridge": "docker0",
  "mtu": 1500
}

2. 重启docker服务：systemctl restart docker
3. 验证网桥状态：执行ip a show docker0，确认网桥处于UP状态且绑定了172.17.0.1/16的IP
4. 执行docker run --rm ubuntu:16.04 apt update确认容器可以正常访问外网

方案3：构建时指定host网络模式（临时验证用，不推荐生产使用） #

不需要修改Runner和节点配置，临时在docker build命令里加--network=host参数，让构建容器直接复用节点宿主机的网络命名空间，跳过docker网桥的配置逻辑：

script:
  - docker build --network=host -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .

注意：该模式下构建容器拥有节点宿主机的全部网络访问权限，安全风险较高，仅适合临时排查问题使用，不要在生产环境长期配置。

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