commandDeis 应用程序中工作进程的部署中有一个无效参数。现在，每当我deis pull为新图像运行时，这个损坏的参数都会传递给部署，因此工作人员不会成功启动。
如果我进入 kubectl，我可以看到在部署中为工作人员设置了以下参数（路径/spec/template/spec/containers/0）
"command": [
"/bin/bash",
"-c"
],
这会导致 pod 无法正常启动：
Error: failed to start container "worker": Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"/bin/bash\": stat /bin/bash: no such file or directory"
Error syncing pod
Back-off restarting failed container
这意味着对于每次发布/拉取，我都会手动从工作人员部署设置中删除该参数。我已经kubectl delete deployment使用有效的 json ( ) 运行并重新创建了它kubectl create -f deployment.json。这会修复问题，直到我deis pull再次运行，此时损坏的参数又回来了。
我的想法是，那个损坏command的参数被保存在 deis 数据库等的某个地方，并且在我运行时它正在被重置deis pull。
我已经尝试了故障排除指南并在其中进行了挖掘，deis-database但我找不到工作进程的部署是在哪里创建的，或者当你运行 a 时传递给 kubernetes 的部署参数deis pull来自哪里。
在 Google Cloud 上运行 deis v2.10.0