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

Question

我有一个带有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镜像运行，没有修改/etc/resolv.conf的地方吧？

解决CrashLoopback的唯一方法是删除pod，部署rc运行一个有效的新pod。

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

Answer 1

restartPolicy适用于Pod中的所有容器，而不适用于pod本身。当有人explicitly deletes他们时，荚通常只会重新创建。

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

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