【K8S系列】Pod重启策略及重启可能原因

目录

1 重启策略

1.1 Always

1.2  OnFailure

1.3 Nerver

1.4 yaml示例 

2 Pod常见异常状态

2.1  Pending状态

2.2 Waiting/ContainerCreating状态

2.3 CrashLoopBackOff状态

2.4 ImagePullBackOff状态

2.5 Error状态

2.6 其他状态说明

tips: 

3.自动重启的可能原因：

3.1  Xms超出了k8s分配 

 3.2 docker容器的内存限制

3.3 出现OOMKilled事件

4 投票

---

 

努力最大的意义在于谋求更多的选择权，储蓄更多的安全感，让内心不失控，生活不失序。

文章标记颜色说明：

• 黄色：重要标题
• 红色：用来标记结论
• 绿色：用来标记一级论点
• 蓝色：用来标记二级论点

1 重启策略

1.1 Always

Pod中的容器，不管因为什么原因停止，都会自动重启。

该为默认策略，

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

1.2  OnFailure

Pod中的容器，非正常停止/异常退出时，会自动重启容器，如果是正常停止，则不会

1.3 Nerver

Pod中容器不管以什么原因退出，都不会自动重启容器

1.4 yaml示例 

其关键字为：restartPolicy 

   

    

     

      

     
     

      

       apiVersion: v1
      
     
    

     

      

     
     

      

       kind: 
       Pod
      
     
    

     

      

     
     

      

       metadata:
      
     
    

     

      

     
     

      
  
       name: nginx-pod-test
      
     
    

     

      

     
     

      

       spec:
      
     
    

     

      

     
     

      
  
       restartPolicy: 
       Always/
       OnFailure/
       Nerver 
       # 重启策略,根据需求选择一种即可
      
     
    

     

      

     
     

      
  
       containers:
      
     
    

     

      

     
     

      

           - 
       name: nginx-pod-test
      
     
    

     

      

     
     

      
      
       image: nginx
      
     
   

2 Pod常见异常状态

• Pending状态
• Waiting/ContainerCreating状态
• CrashLoopBackOff状态
• ImagePullBackOff状态
• Error状态
• 其他状态说明

2.1  Pending状态

Pending状态:

1. 说明Pod的YAML文件已提交给Kubernetes
2. API对象已经被创建并保存在Etcd当中

原因：这个Pod里有些容器因为某种原因而不能被顺利创建。

可能原因：

• 调度不成功

1. 可以通过命令查看到当前Pod的事件，进而判断为什么没有调度。

kubectl describe pod {podname}

• 资源不足

1. 原因：集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源
2. 解决方法：增加资源配置/优化容器资源使用方式

• HostPort 已被占用

1. 解决方法：使用Service对外开放服务端口

2.2 Waiting/ContainerCreating状态

首先通过 命令查看当前Pod的事件

kubectl describe pod {podname}

可能的原因有:

• 镜像拉取失败：比如镜像地址配置错误、拉取不了国外镜像源（gcr.io)、私有镜像密钥配置错误、镜像太大导致拉取超时 (可以适当调整kubelet的-image-pull-progress-deadline和-runtime-request-timeout选项)等。
• CNI网络错误：检查CNI网络插件的配置，比如:无法配置Pod 网络、无法分配IP地址。
• 容器无法启动：检查是否打包了正确的镜像或者是否配置了正确的容器参数
• Failed create pod sandbox：查看kubelet日志，原因可能是磁盘坏道（input/output error)。

2.3 CrashLoopBackOff状态

处于CrashLoopBackOff状态
说明容器曾经启动了，但又异常退出。

1.查看容器的日志，查看退出原因

   

    

     

      

     
     

      

       kubectl logs {podname}
      
     
    

     

      

     
     

      

       kubectl logs --previous {podname}
      
     
   

2.进入容器查看

kubectl exec {mypodname} -c {containername} -it -- bash

3.ssh登录Node查看
 

2.4 ImagePullBackOff状态

处于ImagePullBackOff状态
原因：是镜像名称配置错误或者私有镜像的密钥配置错误导致。

2.5 Error状态

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

2.6 其他状态说明

  

   

    

     

    
    

     

      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被驱赶
     
    
  
 

  
 

tips: 

k8s中不支持重启Pod资源，只有删除重建！重建！

3.自动重启的可能原因：

1.  Xms超出了k8s分配
2. docker容器的内存限制
3. 出现OOMKilled事件

3.1  Xms超出了k8s分配 

在没有给jvm指定内存大小的情况下，机器物理内存很大时，jvm默认占用的内存Xms超出了k8s分配给pod的内存，导致pod内存溢出，从而k8s不断重启pod。

或者：运行过程中，jvm不断申请内存直到最大heap内存Xmx，Xmx超出了k8s分配给pod的内存，从而k8s自动重启pod。

解决方法：在启动的脚本中设置jvm内存-Xms、-Xmx参数

例如：java -Xms1024m -Xmx1024m -jar test.jar

 3.2 docker容器的内存限制

设置了docker容器的内存限制，制作的镜像未对JVM进行配置，

JVM 会默认设置堆栈的大小。

这样，当jvm占用内存超过docker容器限制时，就会出现container 被docker killed情况。

解决方法：一样是设置jvm内存-Xms、-Xmx参数

注意要小于docker容器的内存限制。

3.3 出现OOMKilled事件

pod运行过程中出现了OOMKilled事件

即pod运行过程内存需求持续增加，超过为pod设置的内存大小时，pod会被重启。

解决方法：将pod的内存配置项的值修改大点。

例如之前是1/2，可改为2/4

4 投票

 

转载：https://blog.csdn.net/weixin_36755535/article/details/128804691