command 与 args 是什么
镜像用 ENTRYPOINT 定义入口程序、用 CMD 定义默认参数；Pod 清单里的 command 对应 ENTRYPOINT，args 对应 CMD，两者都写就完全接管容器的启动行为。容器运行时不做命令拼接，只做替换，所以可执行文件必须真实存在于镜像里，相对路径还依赖镜像的 PATH 与 WORKDIR。它是复用同一个镜像适配不同环境的常用手段。
基本信息
| 字段位置 | spec.containers[].command 与 spec.containers[].args |
|---|---|
| 对应关系 | command 覆盖 ENTRYPOINT，args 覆盖 CMD |
| 数据类型 | 字符串数组，每个元素是一个独立参数，不是一整条命令行 |
| 都不写时 | 沿用镜像自带的 ENTRYPOINT 与 CMD |
| 平台归属 | Kubernetes 各类工作负载；Docker 侧对应 --entrypoint 与命令行参数 |
覆盖规则
| command | args | 最终执行 |
|---|---|---|
| 未设 | 未设 | 镜像 ENTRYPOINT + 镜像 CMD |
| 未设 | 设置了 | 镜像 ENTRYPOINT + 清单里的 args |
| 设置了 | 未设 | 只执行清单 command，镜像 CMD 被丢弃 |
| 设置了 | 设置了 | 清单 command 加清单 args，镜像默认值全部失效 |
完整写法
完整写法
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
template:
spec:
containers:
- name: app
image: registry.example.com/app:1.26.0
command: ["/bin/sh", "-c"] # 覆盖 ENTRYPOINT
args: ["exec /app/server --config=/etc/app/config.yaml"] # 覆盖 CMD
env:
- name: APP_ENV
value: prod只换参数不动入口
只换参数不动入口
# 镜像入口是 /app/server，这里只覆盖它的参数，最省事也最不容易出错
args: ["--config=/etc/app/config.yaml", "--log-level=info"]
# 不需要 shell 时优先写成这种形式，避免多一层 sh 带来的信号传递问题典型使用场景
- 同镜像跑不同参数：测试与生产用不同启动开关，不必为每套配置构建镜像
- 注入启动外壳：用 /bin/sh -c 包一层做环境变量展开或等待依赖就绪
- 临时排障：把 command 换成常驻空转命令让容器保持运行，便于进入查看（此时探针会失败，属预期）
- 精简镜像适配：镜像里没有 shell 时直接执行二进制绝对路径，args 逐个列参数
- 接管旧应用：镜像 CMD 里写死了参数，用 args 覆盖即可，不必重新打包
数组元素的边界就是参数的边界：写成 command: ["sh -c echo hi"] 时运行时会把整串当成一个可执行文件名去找，必然失败，正确写法是拆成 ["sh", "-c", "echo hi"]。
不确定镜像默认入口时，先用 kubectl get pod <pod> -o jsonpath='{.spec.containers[*].command}{"|"}{.spec.containers[*].args}' 看清单侧，再用 docker inspect 或镜像文档确认镜像侧的 ENTRYPOINT 与 CMD。启动失败通常表现为 CrashLoopBackOff，日志里出现 not found 字样。