EKS环境下Kaniko执行GitLab CI构建任务卡在step_script阶段问题

• Kubernetes执行器Attach策略兼容问题：你使用的GitLab Runner 14.4.0版本默认启用Kubernetes attach策略执行脚本，而Kaniko v1.7.0-debug镜像存在已知的attach交互适配缺陷，会导致Runner无法将脚本传入容器执行，直接卡在脚本执行入口环节。
• 资源配额不足：Kaniko构建镜像需要至少1核2G的运行资源，若Runner调度的Pod资源配额不足，会被EKS的Kubelet节流阻塞，无日志输出。
• 安全策略限制：EKS 1.21版本若启用了Pod安全策略（PSP），未授权Kaniko容器运行所需的文件系统写入、进程调用权限，也会导致脚本初始化阶段卡住。

方案1：调整Runner执行策略（最优先验证） #

在GitLab CI的构建任务中新增Feature Flag变量，强制关闭Attach策略，使用传统Exec方式执行脚本，修改配置如下：

build:
  stage: build
  variables:
    FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY: "true"
  image:
    name: gcr.io/kaniko-project/executor:v1.7.0-debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf \"%s:%s\" \"${CI_REGISTRY_USER}\" \"${CI_REGISTRY_PASSWORD}\" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - >-
      /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"

若要全局生效，可在GitLab Runner Helm Chart的values.yaml中添加配置，关闭Attach策略：

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        attach = false

方案2：更换Kaniko镜像版本 #

Kaniko v1.7.0的attach兼容问题已在后续版本修复，可直接将镜像标签替换为v1.8.1-debug及以上版本，无需修改其他配置。

方案3：补充Pod资源配额 #

在构建任务中明确声明运行资源需求，避免因资源不足导致阻塞：

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.7.0-debug
    entrypoint: [""]
  # 新增资源配置
  resources:
    requests:
      cpu: "1"
      memory: "2Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  script:
    # 原有脚本内容不变

方案4：调整安全策略 #

若EKS集群启用了Pod安全策略，为Kaniko任务对应的ServiceAccount授予runAsUser: 0、文件系统读写权限，避免权限不足导致初始化失败。

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