kubectl delete做了什么,而Crashloop Backoff重启做不了什么?

• CrashLoopBackOff
  • 重新启动相同的pod和pod中的容器
  • 如果pod持续崩溃或运行状况检查失败,则重启pod所需的时间会随着每次重启而不断增加。
• kubectl delete
  • 删除pod
  • 如果pod由一个更高的抽象来管理:守护程序集、部署、StatefulSet等等,那么就会创建一个新的pod。请注意,在statefolset中,序号保持不变,因此pod将具有相同的名称,但对于其他抽象,pod名称将更改。

我的第一个想法是挂载一个文件,等等。我看到一些问题在删除后得到了解决,尽管一个Crashloop是有效的。

是的,当您删除时,卷将卸载,然后重新装载到新的Pod上。当 紧急回退 重新启动容器。

From the docs :

当Pod运行时,kubelet能够重启容器来处理某些故障。在一个吊舱内,Kubernetes跟踪不同的容器状态和句柄

✌️

两者之间的主要区别是crashloop退避会重新启动容器,但是删除一个pod会重新启动整个pod。

在pod启动时发生的一些操作在容器启动时不会发生。从故障排除的角度来看,需要注意的问题如下:

• 卷装载
• 从Configmaps/Secrets加载值

卷装载通常不是问题,因为pod只是尝试装载它们,直到它工作为止。很少看到只有删除pod才能修复的卷装载问题。

然而,配置地图和秘密可能是一个巨大的问题。pod只在启动时加载configmaps和secrets中的值。一旦pod启动,它将永远忽略对它正在使用的configmaps和secrets的任何更改。

因此,如果您更改pod使用的configmap或secret,您将看到删除pod和crashloop backoff重启之间的区别。