Kubernetes中--dry-run=client与--command参数为何受命令顺序影响？

这是kubectl的预期设计行为，核心原因和标准命令行参数解析规则有关。 #

kubectl遵循通用的GNU命令行参数解析约定：-- 是参数解析终止符，所有出现在--之后的内容，都会被直接认定为要传递给Pod内部容器的启动命令/参数，不会再被kubectl本身识别为自身的命令参数。

你给出的两个命令的差异就在于--dry-run、-o yaml这两个kubectl原生参数的位置：

• 可正常执行的命令中，--dry-run=client、-o yaml均位于--之前，会被kubectl正常识别为自身参数，完成yaml生成逻辑；--之后的env会被作为容器启动命令传入，符合预期。

k run nginx --image=nginx --restart=Never --dry-run=client -o yaml --command -- env > nginx.yaml

• 无法正常执行的命令中，--dry-run=client、-o yaml被放在了--之后，kubectl会直接将这两个字符串和env一起当做容器的启动命令处理，不会触发生成yaml的逻辑，自然得不到预期结果。

k run nginx --image=nginx --restart=Never --command -- env --dry-run=client -o yaml > nginx.yaml

这个规则并非Kubernetes特有，绝大多数类Unix环境下的命令行工具都遵循该约定，目的是解决参数冲突问题：比如你需要给容器传递一个和kubectl参数重名的参数（例如--image）时，通过--分割就可以避免kubectl误识别。

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