Kubernetes中CMD不直接执行，其行为由Pod的command和args字段覆盖：command替换ENTRYPOINT，args替换CMD；两者均未设置时才使用Dockerfile定义的ENTRYPOINT+CMD。
在 Kubernetes 环境下，Dockerfile 中的 CMD 指令不会直接执行，而是作为容器启动时的默认命令被 K8S 的配置覆盖或继承，具体行为取决于 Pod 或容器级别的 command 和 args 字段是否显式设置。
CMD 与 ENTRYPOINT 的协作关系是基础
Docker 容器启动命令由 ENTRYPOINT 和 CMD 共同决定：
- 若只定义
CMD（无ENTRYPOINT），CMD 内容作为完整命令执行，例如CMD ["nginx", "-g", "daemon off;"]→ 直接运行 nginx。 - 若定义了
ENTRYPOINT（如ENTRYPOINT ["sh", "-c"]），则CMD会作为参数传给 ENTRYPOINT，例如CMD ["echo hello"]→ 实际执行sh -c "echo hello"。 - K8S 中的覆盖逻辑始终遵循这一 Docker 原生机制，不改变底层语义。
K8S 中 command 和 args 的覆盖优先级
Kubernetes 通过 Pod spec 中的 container.command 和 container.args 控制最终执行命令，覆盖规则如下：
-
command完全替换 Dockerfile 中的ENTRYPOINT（无论是否存在）； -
args完全替换 Dockerfile 中的CMD； - 只设
command：忽略 Dockerfile 中的 ENTRYPOINT 和 CMD，仅执行该 command； - 只设
args：保留 Dockerfile 的 ENTRYPOINT，但用 args 替换 CMD 作为其参数； - 两者都不设：完全使用 Dockerfile 中定义的 ENTRYPOINT + CMD。
常见误用与调试建议
实际部署中容易因理解偏差导致容器启动失败或行为异常：
- 误以为
args是“追加”到 CMD 后面 —— 实际是“完全替换”，原 CMD 被丢弃； - 使用 shell 形式 CMD（如
CMD nginx -g "daemon off;"）时，若 K8S 只设args，可能因缺少 shell 解析器而报错；建议统一用 exec 格式（["nginx", "-g", "daemon off;"]）； - 调试时可用
kubectl describe pod <name></name>查看 Events 和 Container Details，确认最终解析出的 Command 和 Args； - 临时覆盖测试：用
kubectl run --command --image=xxx -- sh -c 'echo test'快速验证 command/args 行为。
推荐实践：明确职责、避免隐式依赖
为提升可维护性和环境一致性：
- Dockerfile 中尽量用 exec 格式定义
ENTRYPOINT（如启动脚本入口），把可变参数留给CMD； - K8S 清单中显式声明
command和args，不依赖镜像默认值，便于审计和复用； - 若需多环境差异化启动（如 dev/staging/prod），可通过 ConfigMap 或环境变量注入 args，而非修改镜像；
- 对无 ENTRYPOINT 的镜像（如 busybox、alpine），K8S 的
command等价于 Docker 的ENTRYPOINT，args等价于CMD，需特别注意兼容性。
