kubernetes liveness probe重新启动以CrashLoopback结尾的pod

时间:2017-12-26 13:11:59

标签: nginx kubernetes openconnect

我有一个带有2个nginx副本的部署,带有openconnect vpn代理容器(一个pod只有一个容器)。

它们启动时没有任何问题,一切正常,但一旦连接崩溃且我的活动探测失败,nginx容器重新启动,最终在CrashLoopbackoff中,因为openconnect和nginx重启失败,

nginx的:

host not found in upstream "example.server.org" in /etc/nginx/nginx.conf:11

openconnect:

getaddrinfo failed for host 'vpn.server.com': Temporary failure in name resolution

似乎/etc/resolv.conf是由openconnect编辑的,并且在pod重新启动它保持不变(尽管它不是持久卷的一部分)并且我相信整个容器应该从干净运行docker image,其中未修改/etc/resolv.conf,对吗?

如何修复CrashLoopback的唯一方法是删除pod,部署rc运行一个有效的新pod。

创建新pod与使用liveness probe restartPolicy重新启动pod中容器的情况有何不同?总是?是否使用干净的图像重新启动容器?

1 个答案:

答案 0 :(得分:1)

restartPolicy适用于Pod中的所有容器,而不适用于pod本身。通常只有当explicitly deletes人使用时,才会重新创建窗格。

我认为这解释了为什么带有错误resolv.conf的重新启动的容器失败但新的pod工作。

“重新启动的容器”就是这样,它不会从下载的docker映像中生成新的容器。这就像杀死进程并启动它一样 - 新进程的文件系统与旧进程更新的文件系统相同。但是一个新的pod将创建一个新的容器,其本地文件系统视图与下载的docker镜像中打包的相同 - 重新开始。