如何解决kubectl删除有什么作用，而Crashloop Backoff Restart不起作用？
也许有一些基本的知识，即Pod删除和重新创建会执行Pod重启不会做的事情（按照Crashloop重新启动）。我的第一个念头是装入文件等。我已经看到删除后在哪里解决了一些问题，即使Crashloop生效了。
kubectl删除会导致Crashloop Backoff Restart不起作用吗？不知道这是否特定于Daemonset，但这是我最后一次看到此行为的Daemonset。
解决方法
-
CrashLoopBackOff- 重新启动相同的容器和容器中的容器
- 如果Pod持续崩溃或运行状况检查失败，则每次重新启动Pod所需的时间都会不断增加。
-
kubectl delete- 删除豆荚
- 如果吊舱由更高的抽象管理：DaemonSet，Deployment，StatefulSet等，则会创建新的吊舱。请注意，在StatefulSet中，序数保持不变，因此pod的名称将相同，但是对于其他抽象，您的pod名称将发生变化。
我的第一个想法是挂载文件等。我已经看到删除后解决了一些问题的地方，即使Crashloop生效了。
是的，在删除时，技术上将先卸载卷，然后将其重新装载到新的Pod上。 CrashLoopBackOff后，容器将重新启动。
在运行Pod的同时，kubelet能够重新启动容器以处理某些类型的错误。在Pod中，Kubernetes跟踪不同的容器状态和句柄
✌️
,两者之间的主要区别是崩溃循环后退会重新启动容器，而删除容器会重新启动整个容器。
在容器启动上发生的一些动作在容器启动时没有发生。从故障排除的角度来看，要关注的问题如下：
- 卷式支架
- 从Configmaps / Secrets中加载值
卷挂不是经常出现的问题，因为吊舱只是重试挂载直到工作。很少见到只有通过删除Pod才能解决的卷安装问题。
但是，configmap和机密可能是一个巨大的问题。 Pod仅在启动时从configmap和秘密中加载值。吊舱启动后，它将永远忽略其正在使用的对configmap和秘密的任何更改。
因此，如果您更改Pod使用的配置映射或机密，则会看到删除Pod和崩溃循环退避重新启动之间的区别。