Back-off restarting failed container 怎么办？

问题原因

Back-off restarting failed container的原因，通常是因为，容器内PID为1的进程退出导致（通常用户在构建镜像执行CMD时，启动的程序，均是PID为1）。一般遇到此问题，使用者需自行排查原因，可从如下几个方向入手：

1. 镜像封装是否有问题，如是否有PID为1的常驻进程
   1. 举例1：在容器dockerfile中，最后的CMD执行的是nginx start，执行后，nginx服务一直在前台打印日志，服务常驻，进程持续存在，则不会有问题
   2. 举例2：在容器dockerfile中，最后的CMD执行的是nohup nginx start &，执行后，该命令就结束了，对应的进程也就没了，容器back-off重启
2. 常驻进程是否异常退出
   1. 这也是使用者经常遇到的问题，使用者常见反馈：我在我本地运行都是好好的，本地docker，k8s环境都正常，但是换了个k8s环境，就失败了。
      1. 举例：服务启动后，会尝试连接一个第三方服务，重试10次连接失败，则程序终止退出，本地环境和这个三方环境通，换了个k8s之后，这个服务不通了，则会出现服务退出，进程结束，容器back-off
3. 镜像使用方式不对
   1. 例如镜像封装的时候，并没有指定启动参数，需要使用者在使用该镜像的时候，自己添加启动命令及参数（command，args），如果不添加，容器内可能没有正确的执行命令，运行即退出

如何处理

方式一：

此方式仅针对于镜像是正确构建和使用，并且可能在其他环境有做过测试也是正常的。（也就是上述描述的第二种问题原因）

如果镜像有应用的标准输出，可以直接取查看容器的日志，在web控制台或者使用kubectl logs命令皆可，如果日志足够丰富，应该就可以找到问题所在。

方式二：

没日志，甚至可能镜像本身就有问题

此种方式，推荐使用sleep方式，对容器先行临时启动，然后进入容器具体排查，具体方式：

1、 修改容器启动命令和参数，使用sleep命令先将该容器启动

tke的web页面书写方式见下

yaml方式参考如下

2、步骤1会执行sleep命令，并会覆盖掉容器原本的启动命令，如果您的容器有sh环境和sleep命令，上述命令就会执行成功并让容器running

3、进入容器，然后手工启动下容器本该执行的启动命令或脚本，然后观察相关日志输出，分析定位问题原因

4、解决问题后重新构建镜像，然后使用新镜像启动，启动时，请注意，去掉步骤1中所使用的sleep命令，回归workload本身应有的启动命令和参数