在Deis应用程序中，无效command参数进入部署中的工作进程。现在每当我为新图像运行deis pull时，这个损坏的参数就会传递给部署，因此工作人员不会成功启动。
如果我进入kubectl，我可以看到在工作人员的部署中设置了以下参数（路径/spec/template/spec/containers/0）
"command": [
"/bin/bash",
"-c"
],
导致播放机无法正常启动：
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时会被重置。
我已尝试the troubleshooting guide并在deis-database中挖掘但我无法找到正在创建工作进程的部署位置或已通过的部署参数的位置当你运行deis pull来自kubernetes时。
在Google Cloud上运行deis v2.10.0