用 busybox 来对比，恰好能揭示与 nginx 最核心的一个差异：busybox 官方镜像默认没有设置 ENTRYPOINT，只设置了 CMD ["sh"]。

这就导致 args（对应 CMD）的行为发生了根本性变化——在 nginx 中它只能是“参数”，但在 busybox 中它可以直接变成“完整的可执行命令”。

下面我通过 4 个 kubectl run 命令，让你直观感受这种差异。

场景一：默认运行（CMD ["sh"] 生效）

1

kubectl run bbox-default --image=busybox --restart=Never

• K8s 字段：command 未设，args 未设。
• 实际执行：sh
• 运行结果：由于没有交互终端（-it），sh 启动后立即退出，Pod 状态很快变成 Completed。
• 差异说明：这是镜像自带的默认行为，但一般不适合作为常驻服务。

场景二：只设置 args（覆盖 CMD，因为没有 ENTRYPOINT，所以直接替换了主程序）

1

kubectl run bbox-args --image=busybox --restart=Never -- sleep 30

注意：这里没用 --command，所以 sleep 30 全被解析为 args。

• K8s 字段：command 未设，args: [“sleep”, “30”]。
• 实际执行：sleep 30
• 运行结果：容器内 1 号进程是 sleep，持续运行 30 秒后退出。
• 🔥 与 nginx 的核心差异： 在 nginx 中，args 只能追加参数（变成 nginx -g daemon off; worker_processes 4），无法把 nginx 换成 sleep。 但在 busybox 中，因为缺少 ENTRYPOINT 这个“骨架”，args 直接覆盖了整条命令，相当于把 sh 换成了 sleep。

场景三：只设置 command（显式指定主程序，语义最清晰）

1

kubectl run bbox-command --image=busybox --restart=Never --command -- top

使用 --command，表示后面的 top 属于 command 字段。

• K8s 字段：command: [“top”]，args 未设。
• 实际执行：top
• 运行结果：top 进程持续运行（默认刷新间隔 5 秒），容器不会退出。
• 差异说明：虽然在最终效果上，它跟场景二（args: ["top"]）都能运行 top，但在 K8s API 语义上完全不同：
  • 场景二（仅 args）是“覆盖默认参数”，只是因为没 ENTRYPOINT 才碰巧变成了主程序；
  • 场景三（仅 command）是“显式指定可执行文件”，明确告诉 K8s 我要运行什么。

场景四：同时设置 command 和 args（完全自定义，最标准）

1

kubectl run bbox-both --image=busybox --restart=Never --command -- ping 127.0.0.1 -- -c 3

--command 后的 ping 127.0.0.1 是 command，-- 后面的 -c 3 是 args。

• K8s 字段：command: [“ping”, “127.0.0.1”]，args: ["-c", “3”]
• 实际执行：ping 127.0.0.1 -c 3
• 运行结果：向本机发 3 个 ping 包，输出结果后容器正常退出。
• 差异说明：这是最彻底的覆盖，镜像里定义的所有启动逻辑都被忽略，完全由用户掌控。

核心结论对比表（nginx vs busybox）

如何快速验证它们的不同？

用 kubectl get pods 看状态，再用 kubectl logs 或 kubectl exec 看进程：

1
2
3
4
5

# 查看 bbox-args 的 1 号进程（会是 sleep，而不是 sh）
kubectl exec bbox-args -- ps aux

# 查看 bbox-command 的 1 号进程（会是 top）
kubectl exec bbox-command -- ps aux

一句话总结

busybox 因为缺少 ENTRYPOINT，使得 args 拥有了“变身”能力（可直接换程序），而 nginx 因为有 ENTRYPOINT，args 只能“微调”参数。这提醒我们：写 YAML 时，不能想当然认为 args 永远只是参数，一定要看镜像本身的 ENTRYPOINT 是否存在。