Kubernetes(k8s) pod 重启策略

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3

没有定义重启策略时，默认的就是always

kubectl apply -f always.yaml
kubectl get pod -o wide -w

注：证明重启策略默认是always，总是自动拉取

3、Never

apiVersion: v1
kind: Pod
metadata:
  name: foo01
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
  restartPolicy: Never

4、OnFailure

4.1、非0状态

apiVersion: v1
kind: Pod
metadata:
  name: foo02
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 20; exit 3
  restartPolicy: OnFailure

kubectl apply -f onfailure.yaml 
kubectl get pod -o wide -w

==当容器异常退出（退出状态码非0）时，重启容器 ==

4.2、为0状态

我们在创建pod时，有时使用的为一次性pod，正常执行完退出后，不需要对其进行重启，这时就需要设置PnFailure

apiVersion: v1
kind: Pod
metadata:
  name: foo03
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 20; exit 0
  restartPolicy: OnFailure

kubectl apply -f infailure.yaml
kubectl get pod -o wide -w

退出后显示的完成，说明正常退出，只是完成了这个动作，并不是错误。

退出状态码为0时包含两种状态，一种是正常完成后返回值0，（complated）；第二种手动指定 exit 0

二、Pod状态

常见异常状态：

1、Pod 一直处于Pending状态

Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl describe pod命令查看到当前Pod的事件，进而判断为什么没有调度)。

可能原因

资源不足（集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源); HostPort 已被占用(通常推荐使用Service对外开放服务端口)。

2、Pod一直处于Waiting 或 ContainerCreating状态

首先还是通过 kubectl describe pod命令查看当前Pod的事件。

可能的原因有:

1、镜像拉取失败，比如镜像地址配置错误、拉取不了国外镜像源（gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时 (可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。

2、CNI网络错误，一般需要检查CNI网络插件的配置，比如:无法配置Pod 网络、无法分配IP地址。

3、容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数

4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盘坏道（input/output error)。

3、Pod 一直处于ImagePullBackOff状态

通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。

4、Pod 一直处于CrashLoopBackOff状态

此状态说明容器曾经启动了，但又异常退出。这时可以先查看一下容器的日志。

通过命令kubectl logs 和kubectl logs --previous 可以发下一些容器退出的原因，

比如:容器进程退出、健康检查失败退出;此时如果还未发现线索，还而已到容器内执行命令(kubectl exec cassandra - cat /var.log/cassandra/system.loq)来进一步查看退出原因;如果还是没有线索，那就需要SSH登录该Pod所在的Node上，查看Kubelet或者Docker的日志进一步排查。

5、Pod处于Error状态

通常处于Error状态说明Pod启动过程中发生了错误。

常见的原因:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制，

比如超过了LimitRange等;违反集群的安全策略，比如违反了PodSecurityPolicy.等;容器无法操作集群内的资源，比如开启RDAC后，需要为ServiceAccount配置角色绑定。

6、Pod 处于Terminating或 Unknown状态

从v1.5开始，Kubernetes不会因为Node失联而删除其上正在运行的Pod，而是将其标记为Terminating 或 Unknown 状态。

想要删除这些状态的Pod有三种方法：

1、从集群中删除Node。使用公有云时，kube-controller-manager会在VM删除后自动删除对应的Node。而在物理机部署的集群中，需要管理员手动删除Node（kubectl delete node）。

2、Node恢复正常。kubelet会重新跟kube-apiserver通信确认这些Pod的期待状态，进而再决定删除或者继续运行这些Pod。用户强制删除，用户可以执行（kubectl delete pods pod-name --grace-period=0 --force）强制删除Pod。除非明确知道Pod的确处于停止状态（比如Node所在VM或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的Pod，强制删除容易导致脑裂或数据丢失等问题。

3、Pod行为异常，这里所说的行为异常是指Pod没有按预期的行为执行，比如没有运行podSpec 里面设置的命令行参数。这一般是podSpec yaml文件内容有误，可以尝试使用 --validate 参数重建容器，比如（kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml）；也可以查看创建后的podSpec是否是对的，比如（kubectl get pod mypod -o yaml）；修改静态Pod的Manifest后未自动重建，kubelet 使用inotify 机制检测 /etc/kubernetes/manifests 目录（可通过 kubelet 的 -pod-manifest-path 选项指定）中静态Pod的变化，并在文件发生变化后重新创建相应的 Pod。但有时也会发现修改静态Pod的 Manifest后未自动创建新 Pod的情景，此时已过简单的修复方法是重启 Kubelet。

Unknown 这个异常状态意味着Pod的状态不能持续地被 kubelet汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

其它pod状态

CrashLoopBackOff：    #容器退出，kubelet正在将它重启
InvalidImageName：    #无法解析镜像名称
ImageInspectError：   #无法校验镜像
ErrImageNeverPull：   #策略禁止拉取镜像
ImagePullBackOff：    #正在重试拉取
RegistryUnavailable： #连接不到镜像中心
ErrImagePull：        #通用的拉取镜像出错
CreateContainerConfigError： #不能创建kubelet使用的容器配置
CreateContainerError： #创建容器失败
m.internalLifecycle.PreStartContainer #执行hook报错
RunContainerError：   #启动容器失败
PostStartHookError：  #执行hook报错
ContainersNotInitialized： #容器没有初始化完毕
ContainersNotReady：   #容器没有准备完毕
ContainerCreating：    #容器创建中
PodInitializing：pod   #初始化中
DockerDaemonNotReady：  #docker还没有完全启动
NetworkPluginNotReady： #网络插件还没有完全启动
Evicte:     #pod被驱赶

原文链接：https://blog.csdn.net/weixin_56270746/article/details/126144791

最后修改：2023 年 10 月 26 日

如果觉得我的文章对你有用，请随意赞赏

此处评论已关闭

Kubernetes(k8s) pod 重启策略

Atigger • 2023 年 10 月 26 日

<div id="content_views" class="htmledit_views">目录<a href="#%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E7%BC%96%E8%BE%91%C2%A0"></a><a href="#%E4%B8%80%E3%80%81%E9%87%8D%E5%90%AF%E7%AD%96%E7%95%A5">一、重启策略</a><a href="#1%E3%80%81%E5%9C%A8k8s%E9%9B%86%E7%BE%A4%E4%B8%AD%E6%9C%89%E5%A6%82%E4%B8%8B%E4%B8%89%E7%A7%8D%E9%87%8D%E5%90%AF%E7%AD%96%E7%95%A5">1、在k8s集群中有如下三种重启策略</a><a href="#2%E3%80%81Always">2、Always</a><a href="#3%E3%80%81Never">3、Never</a><a href="#4%E3%80%81OnFailure">4、OnFailure</a><a href="#4.1%E3%80%81%E9%9D%9E0%E7%8A%B6%E6%80%81">4.1、非0状态</a><a href="#4.2%E3%80%81%E4%B8%BA0%E7%8A%B6%E6%80%81">4.2、为0状态</a><a href="#%E4%BA%8C%E3%80%81Pod%E7%8A%B6%E6%80%81">二、Pod状态</a><a href="#1%E3%80%81Pod%20%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8EPending%E7%8A%B6%E6%80%81">1、Pod 一直处于Pending状态</a><a href="#2%E3%80%81Pod%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8EWaiting%20%E6%88%96%20ContainerCreating%E7%8A%B6%E6%80%81">2、Pod一直处于Waiting 或 ContainerCreating状态</a><a href="#3%E3%80%81Pod%20%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8EImagePullBackOff%E7%8A%B6%E6%80%81">3、Pod 一直处于ImagePullBackOff状态</a><a href="#4%E3%80%81Pod%20%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8ECrashLoopBackOff%E7%8A%B6%E6%80%81">4、Pod 一直处于CrashLoopBackOff状态</a><a href="#5%E3%80%81Pod%E5%A4%84%E4%BA%8EError%E7%8A%B6%E6%80%81">5、Pod处于Error状态</a><a href="#6%E3%80%81Pod%20%E5%A4%84%E4%BA%8ETerminating%E6%88%96%20Unknown%E7%8A%B6%E6%80%81">6、Pod 处于Terminating或 Unknown状态</a><hr id="hr-toc"><img alt="" height="348" src="https://img-blog.csdnimg.cn/3fccc99f02094fe0a2c6b3a0f490d734.jpeg" width="651">&nbsp;<h2 id="%E4%B8%80%E3%80%81%E9%87%8D%E5%90%AF%E7%AD%96%E7%95%A5">一、重启策略</h2>在k8s集群中，当某个pod资源需要重启时，我们只会对其进行删除，由其pod控制器进行重新构建。k8s集群的自愈也是对资源的一个重新构建，&nbsp;在k8s中是没有重启一说的。我们&nbsp;常说的重启，其实就是对pod资源的重新构建，那么k8s集群在对资源进行管理时，其“重启”规则又是什么呢？<h3 id="1%E3%80%81%E5%9C%A8k8s%E9%9B%86%E7%BE%A4%E4%B8%AD%E6%9C%89%E5%A6%82%E4%B8%8B%E4%B8%89%E7%A7%8D%E9%87%8D%E5%90%AF%E7%AD%96%E7%95%A5">1、在k8s集群中有如下三种重启策略</h3><ol>
 <li>Always：当容器终止退出后，总是重启容器，默认策略</li>
 <li>OnFailure：当容器异常退出（退出状态码非0）时，重启容器</li>
 <li>Never：当容器终止退出，从不重启容器。</li>
 </ol>重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长为10s，20s，40s，80s，160s，300s，300s是最大延迟时长重启策略设置建议因为重启策略默认的是Always，这也是合理的，因此在一般情况下，重启策略不需要设置，这里仅仅是作为知识点拿出来展示一下，在实际使用中，在大多数情况下都不需要进行重启策略配置<h2 id="2%E3%80%81Always">2、Always</h2><pre><code>apiVersion: v1
kind: Pod
metadata:
 name: foo
spec:
 containers:
 - name: busybox
 image: busybox
 args:
 - /bin/sh
 - -c
 - sleep 30; exit 3
</code></pre><img alt="" height="372" src="https://img-blog.csdnimg.cn/c1a0f5e3186649509d2a06d6ab4b5dd0.png" width="924">&nbsp;没有定义重启策略时，默认的就是always<pre><code>kubectl apply -f always.yaml
kubectl get pod -o wide -w
</code></pre><img alt="" height="271" src="https://img-blog.csdnimg.cn/6fbd26f9aa434b4fa4f1f4b324a008b3.png" width="1030">&nbsp;注：证明重启策略默认是always，总是自动拉取<h3 id="3%E3%80%81Never">3、Never</h3><pre><code>apiVersion: v1
kind: Pod
metadata:
 name: foo01
spec:
 containers:
 - name: busybox
 image: busybox
 args:
 - /bin/sh
 - -c
 - sleep 30; exit 3
 restartPolicy: Never
</code></pre><img alt="" height="366" src="https://img-blog.csdnimg.cn/ec8e121a401d425eaeb3f585c54b45d1.png" width="759"><img alt="" height="329" src="https://img-blog.csdnimg.cn/0625cb267e804648899a0a813c77effd.png" width="1006"><h3 id="4%E3%80%81OnFailure">4、OnFailure</h3><h4 id="4.1%E3%80%81%E9%9D%9E0%E7%8A%B6%E6%80%81">4.1、非0状态</h4><pre><code>apiVersion: v1
kind: Pod
metadata:
 name: foo02
spec:
 containers:
 - name: busybox
 image: busybox
 args:
 - /bin/sh
 - -c
 - sleep 20; exit 3
 restartPolicy: OnFailure
</code></pre><img alt="" height="358" src="https://img-blog.csdnimg.cn/a90db34922934414b2c3906e5ec346c9.png" width="772"><pre><code>kubectl apply -f onfailure.yaml 
kubectl get pod -o wide -w
</code></pre><img alt="" height="424" src="https://img-blog.csdnimg.cn/417fe533722f47d78526fa7320754994.png" width="1140">&nbsp;==当容器异常退出（退出状态码非0）时，重启容器&nbsp;==<h4 id="4.2%E3%80%81%E4%B8%BA0%E7%8A%B6%E6%80%81">4.2、为0状态</h4>我们在创建pod时，有时使用的为一次性pod，正常执行完退出后，不需要对其进行重启，这时就需要设置PnFailure<pre><code>apiVersion: v1
kind: Pod
metadata:
 name: foo03
spec:
 containers:
 - name: busybox
 image: busybox
 args:
 - /bin/sh
 - -c
 - sleep 20; exit 0
 restartPolicy: OnFailure
</code></pre><img alt="" height="346" src="https://img-blog.csdnimg.cn/ba8418a697464052aff2883f8c6c4fe7.png" width="787"><pre><code>kubectl apply -f infailure.yaml
kubectl get pod -o wide -w
</code></pre><img alt="" height="227" src="https://img-blog.csdnimg.cn/fa2223db02074b80b3d10ef44781380a.png" width="1135">&nbsp;退出后显示的完成，说明正常退出，只是完成了这个动作，并不是错误。退出状态码为0时包含两种状态，一种是正常完成后返回值0，（complated）；第二种 手动指定 exit 0<h2 id="%E4%BA%8C%E3%80%81Pod%E7%8A%B6%E6%80%81">二、Pod状态</h2>常见异常状态：<h4 id="1%E3%80%81Pod%20%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8EPending%E7%8A%B6%E6%80%81">1、Pod 一直处于Pending状态</h4>Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl describe pod命令查看到当前Pod的事件，进而判断为什么没有调度)。可能原因资源不足（集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源); HostPort 已被占用(通常推荐使用Service对外开放服务端口)。<h4 id="2%E3%80%81Pod%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8EWaiting%20%E6%88%96%20ContainerCreating%E7%8A%B6%E6%80%81">2、Pod一直处于Waiting 或 ContainerCreating状态</h4>首先还是通过 kubectl describe pod命令查看当前Pod的事件。可能的原因有:1、镜像拉取失败，比如镜像地址配置错误、拉取不了国外镜像源（gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时 (可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。2、CNI网络错误，一般需要检查CNI网络插件的配置，比如:无法配置Pod 网络、无法分配IP地址。3、容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盘坏道（input/output error)。<h4 id="3%E3%80%81Pod%20%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8EImagePullBackOff%E7%8A%B6%E6%80%81">3、Pod 一直处于ImagePullBackOff状态</h4>通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。<h4 id="4%E3%80%81Pod%20%E4%B8%80%E7%9B%B4%E5%A4%84%E4%BA%8ECrashLoopBackOff%E7%8A%B6%E6%80%81">4、Pod 一直处于CrashLoopBackOff状态</h4>此状态说明容器曾经启动了，但又异常退出。这时可以先查看一下容器的日志。通过命令kubectl logs 和kubectl logs --previous 可以发下一些容器退出的原因，比如:容器进程退出、健康检查失败退出;此时如果还未发现线索，还而已到容器内执行命令(kubectl exec cassandra - cat /var.log/cassandra/system.loq)来进一步查看退出原因;如果还是没有线索，那就需要SSH登录该Pod所在的Node上，查看Kubelet或者Docker的日志进一步排查。<h4 id="5%E3%80%81Pod%E5%A4%84%E4%BA%8EError%E7%8A%B6%E6%80%81">5、Pod处于Error状态</h4>通常处于Error状态说明Pod启动过程中发生了错误。常见的原因:依赖的ConfigMap、Secret或PV等不存在;请求的资源超过了管理员设置的限制，比如超过了LimitRange等;违反集群的安全策略，比如违反了PodSecurityPolicy.等;容器无法操作集群内的资源，比如开启RDAC后，需要为ServiceAccount配置角色绑定。<h4 id="6%E3%80%81Pod%20%E5%A4%84%E4%BA%8ETerminating%E6%88%96%20Unknown%E7%8A%B6%E6%80%81">6、Pod 处于Terminating或 Unknown状态</h4>从v1.5开始，Kubernetes不会因为Node失联而删除其上正在运行的Pod，而是将其标记为Terminating 或 Unknown 状态。想要删除这些状态的Pod有三种方法：1、从集群中删除Node。使用公有云时，kube-controller-manager会在VM删除后自动删除对应的Node。而在物理机部署的集群中，需要管理员手动删除Node（kubectl delete node）。2、Node恢复正常。kubelet会重新跟kube-apiserver通信确认这些Pod的期待状态，进而再决定删除或者继续运行这些Pod。用户强制删除，用户可以执行（kubectl delete pods pod-name --grace-period=0 --force）强制删除Pod。除非明确知道Pod的确处于停止状态（比如Node所在VM或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的Pod，强制删除容易导致脑裂或数据丢失等问题。3、Pod行为异常，这里所说的行为异常是指Pod没有按预期的行为执行，比如没有运行podSpec 里面设置的命令行参数。这一般是podSpec yaml文件内容有误，可以尝试使用 --validate 参数重建容器，比如（kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml）；也可以查看创建后的podSpec是否是对的，比如（kubectl get pod mypod -o yaml）；修改静态Pod的Manifest后未自动重建，kubelet 使用inotify 机制检测 /etc/kubernetes/manifests 目录（可通过 kubelet 的 -pod-manifest-path 选项指定）中静态Pod的变化，并在文件发生变化后重新创建相应的 Pod。但有时也会发现修改静态Pod的 Manifest后未自动创建新 Pod的情景，此时已过简单的修复方法是重启 Kubelet。Unknown 这个异常状态意味着Pod的状态不能持续地被 kubelet汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。其它pod状态<pre><code>CrashLoopBackOff： #容器退出，kubelet正在将它重启
InvalidImageName： #无法解析镜像名称
ImageInspectError： #无法校验镜像
ErrImageNeverPull： #策略禁止拉取镜像
ImagePullBackOff： #正在重试拉取
RegistryUnavailable： #连接不到镜像中心
ErrImagePull： #通用的拉取镜像出错
CreateContainerConfigError： #不能创建kubelet使用的容器配置
CreateContainerError： #创建容器失败
m.internalLifecycle.PreStartContainer #执行hook报错
RunContainerError： #启动容器失败
PostStartHookError： #执行hook报错
ContainersNotInitialized： #容器没有初始化完毕
ContainersNotReady： #容器没有准备完毕
ContainerCreating： #容器创建中
PodInitializing：pod #初始化中
DockerDaemonNotReady： #docker还没有完全启动
NetworkPluginNotReady： #网络插件还没有完全启动
Evicte: #pod被驱赶
</code></pre></div>原文链接：https://blog.csdn.net/weixin_56270746/article/details/126144791

Kubernetes(k8s) pod 重启策略

一、重启策略

1、在k8s集群中有如下三种重启策略

2、Always

3、Never

4、OnFailure

4.1、非0状态

4.2、为0状态

二、Pod状态

1、Pod 一直处于Pending状态

2、Pod一直处于Waiting 或 ContainerCreating状态

3、Pod 一直处于ImagePullBackOff状态

4、Pod 一直处于CrashLoopBackOff状态

5、Pod处于Error状态

6、Pod 处于Terminating或 Unknown状态

[原创]mangabz漫画网爬取

移动端适配

Vue3的侦听器

Vue3的toRaw()与markRaw()

Vue3的Teleport组件

kubernetes（k8s） pod（资源限制、基础概念）

Vue3的shallowReactive()和shallowRef()

数组中同组的数据，计算总额，并在同组的末尾添加总额项

Java学习笔记-04

Vue3的计算属性

Kubernetes(k8s) pod 重启策略