Jenkins Kubernetes代理运行curl脚本提示命令不存在如何解决

问题现象 #

在Jenkins Kubernetes类型代理上运行包含curl的脚本时，抛出如下错误：

/home/jenkins/agent/ng-cleaner@tmp/durable-0d154ecf/script.sh: 2: curl: not found

原始代理Pod配置如下：

pipeline {
    agent {
    kubernetes {
        customWorkspace 'ng-cleaner'
        yaml """
kind: Pod
metadata:
spec:
  imagePullSecrets:
    - name: jenkins-docker
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: agentpool
                operator: In
                values:
                  - build
  schedulerName: default-scheduler
  tolerations:
    - key: type
      operator: Equal
      value: jenkins
      effect: NoSchedule
  containers:
    - name: jnlp
      env:
        - name: CONTAINER_ENV_VAR
          value: jnlp
    - name: build
      image: tixartifactory-docker.jfrog.io/baseimages/helm:helm3.2.1-helm2.16.2-kubectl.0
      ttyEnabled: true
      command:
        - cat
      tty: true
"""
    }
}

已尝试两种方案均失效：

• 在build容器中执行apk add --no-cache curl或apt install curl装包
• 新增使用curlimages/curl:7.83.1镜像的独立curl容器

失效原因 #

• 容器内直接装包失败：你使用的helm基础镜像为精简版，要么未内置apk/apt包管理器，要么容器默认以非root用户运行，无系统级装包权限，导致装包命令执行失败。
• 新增curl容器无效：Jenkins Kubernetes插件默认所有未指定容器的shell步骤，都会运行在名为jnlp的默认代理容器中，你虽然新增了curl容器，但没有将curl相关步骤调度到该容器内执行，步骤依然运行在无curl的jnlp/build容器中，自然找不到命令。

可落地方案 #

方案1：指定步骤运行在curl容器（最快生效，无需修改镜像） #

首先补全Pod配置中的curl容器段，确保容器能正常驻留、工作目录和其他容器对齐：

containers:
  - name: jnlp
    env:
      - name: CONTAINER_ENV_VAR
        value: jnlp
  - name: build
    image: tixartifactory-docker.jfrog.io/baseimages/helm:helm3.2.1-helm2.16.2-kubectl.0
    ttyEnabled: true
    command:
      - cat
    tty: true
  # 新增curl容器配置
  - name: curl
    image: curlimages/curl:7.83.1
    ttyEnabled: true
    command:
      - cat
    tty: true
    workingDir: /home/jenkins/agent

执行curl相关脚本时，用container('curl')块明确指定步骤运行在curl容器内：

stage('执行curl请求') {
  steps {
    container('curl') {
      sh 'curl 你的请求地址和参数'
    }
  }
}

提示：如果需要在curl步骤和build步骤之间共享工作区文件，必须保证所有容器的workingDir配置一致，否则会出现文件找不到的问题。

方案2：预构建内置curl的自定义build镜像（最稳定，长期使用推荐） #

基于现有helm基础镜像提前打包curl，构建完成后推到私有镜像仓库，替换原build容器的镜像地址即可，无需多容器切换。Dockerfile参考：

FROM tixartifactory-docker.jfrog.io/baseimages/helm:helm3.2.1-helm2.16.2-kubectl.0
USER root
# 自动适配alpine/debian系基础镜像的包管理器
RUN if command -v apk >/dev/null; then \
      apk add --no-cache curl; \
    elif command -v apt >/dev/null; then \
      apt update && apt install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/*; \
    fi
USER jenkins

替换镜像后，所有步骤默认运行在build容器中即可直接调用curl，不需要额外加container块。

方案3：临时提权装包（仅调试用） #

如果只是临时调试不想改镜像，可以给build容器配置root运行权限，再执行装包：
修改build容器配置，添加安全上下文：

- name: build
  image: tixartifactory-docker.jfrog.io/baseimages/helm:helm3.2.1-helm2.16.2-kubectl.0
  ttyEnabled: true
  command:
    - cat
  tty: true
  securityContext:
    runAsUser: 0

流水线步骤中先装curl再执行请求：

stage('临时执行curl') {
  steps {
    container('build') {
      sh '''
        if command -v apk >/dev/null; then
          apk add --no-cache curl
        elif command -v apt >/dev/null; then
          apt update && apt install -y --no-install-recommends curl
        fi
        curl 你的请求参数
      '''
    }
  }
}

提示：该方案每次启动代理Pod都要重新下载安装curl，执行效率低，不建议生产流水线长期使用。

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