Kubernetes配置command与args时参数被忽略、传参失效如何解决

1. 参数传递的拆分规则认知错误 #

Shell 环境下的命令行参数是按空格拆分为独立token的，程序接收到的参数列表是逐段独立的，不会自动把带空格的整串二次拆分。
你之前先后尝试的两种写法（把-db_server vwmazfassql01加引号作为单个args元素、去掉args元素的引号）本质是同一个问题：只要数组元素本身包含空格，K8s就会把整个字符串作为一个独立参数传给容器进程。ads_start脚本只会把以短横线开头、长度匹配参数名的短字符串识别为配置项标记，不会处理带空格的长串，因此最终抛出Unknown parameter value的报错。

2. 启动脚本的参数解析规则 #

ads_start脚本的配置项触发逻辑是必须识别到带短横线开头的参数名，才会读取紧随其后的独立参数值。你之前尝试去掉参数名前的短横线时，脚本完全识别不到配置项标记，会把传入的字符串当成普通业务位置参数直接忽略，因此所有配置项一直使用内置默认值（比如db_name默认值ads）。

3. Kubernetes与Docker Compose的字段映射认知偏差 #

原Docker Compose的配置逻辑是：

• ENTRYPOINT固定指定：可执行文件路径 + 固定入参ads
• command传入数据库连接的动态参数
  对应到Kubernetes的字段映射规则是：
• K8s的command字段会完全覆盖容器镜像内置的ENTRYPOINT
• K8s的args字段会完全覆盖容器镜像内置的CMD
  之前的配置混乱本质是没有对齐这个映射关系，要么把可执行程序、固定参数、动态参数的位置放错，要么没有遵守数组传参的拆分要求。

核心原则：严格按照完整Linux终端命令的空格拆分逻辑，将每个独立的命令行片段作为数组的单个元素，绝对不能把带空格的内容合并成一个数组项。
对照终端可正常执行的完整命令：
/opt/front/arena/sbin/ads_start ads -db_server vmazfassql01 -db_name Test1
拆分后得到6个独立的命令行片段，对应两种等价的配置写法：

写法一：对齐原Docker Compose的分层逻辑 #

• command字段只写可执行文件路径，对应原ENTRYPOINT中的可执行程序部分
• args字段按顺序放入固定入参、动态配置参数，每个参数名和参数值单独作为数组元素
  示例配置片段：

containers:
- name: ads-app
  image: 你的业务镜像地址
  command: ["/opt/front/arena/sbin/ads_start"]
  args:
  - "ads"
  - "-db_server"
  - "vmazfassql01"
  - "-db_name"
  - "Test1"

写法二：把固定入参合并到command字段 #

如果希望和原镜像的ENTRYPOINT行为完全一致，可以把固定入参ads直接放到command数组中，args只保留动态配置参数：

containers:
- name: ads-app
  image: 你的业务镜像地址
  command: ["/opt/front/arena/sbin/ads_start", "ads"]
  args:
  - "-db_server"
  - "vmazfassql01"
  - "-db_name"
  - "Test1"

• 禁止把参数名和参数值合并为单个数组元素，比如不要写"-db_server vmazfassql01"，这是最常见的传参失败原因
• 禁止去掉参数名前的短横线，否则会被脚本判定为非配置参数直接忽略
• 可以临时用["/bin/sh", "-c", "echo $@; sleep 60"]作为临时启动命令，在Pod日志中确认实际传入的参数列表和预期完全一致后，再换回真实的业务启动命令，减少反复试错的成本。

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