Kubernetes pod在成功完成后在CrashLoopBackOff状态下

Question

我在Kubernetes 1.0中运行集群，并且我有一些容器，我想定期作为pod中的边车容器运行 - 通常是推或拉备份。我通过建立一个带有我想备份的数据的容器的吊舱，以及用于支撑它的边车容器来完成此任务。 sidecar容器是一个基本的bash脚本，它可以执行备份命令，然后休眠很长时间（比如15分钟），我想在备份之间等待，最后以0状态码退出。

在1.0中，这个功能很有魅力。我的备份容器非常简单，并且不受作为守护进程运行的限制;他们几乎可以作为一个独立的命令执行，并按预期工作，但监视器使它们保持活动状态，并将它们保持在一个循环中。

升级到1.1之后，我注意到这些豆荚全部不断放入CrashLoopBackOff状态，这意味着它们的重新启动延迟了。对于边车集装箱来说这样可能没问题，但是在这段时间里，生产数据的集装箱也无法使用，这让我很吃惊。

有没有什么方法可以表明定期重新启动的吊舱不是碰撞循环，而是通过设计发生的？或者，解决这个问题的唯一办法是将边车容器变成一个永不退出的守护进程？

Answer 1

有没有什么方法可以指示定期重启的吊舱不是碰撞循环，而是通过设计发生的？

不，我知道的。

或者是解决这个问题的唯一方法是将边车容器变成一个永不退出的守护进程吗？

这将是我建议的解决方案。