目录1 重启策略1.1Always1.2OnFailure1.3Nerver1.4 yaml示例2 Pod常见异常状态2.1Pending状态2.2 Waiting/ContainerCreating状态2.3CrashLoopBackOff状态2.4ImagePullBackOff状态2.5 Error状态2.6其他状态说明3.自动重启的可能原因：3.1Xms超出了k8s分配3.2docker容器的内存限制3.3 出现OOMKilled事件总结
1 重启策略
1.1Always
Pod中的容器，不管因为什么原因停止，都会自动重启。
该为默认策略，
没有定义重启策略时，默认的就是always
1.2OnFailure
Pod中的容器，非正常停止/异常退出时，会自动重启容器，如果是正常停止，则不会
1.3Nerver
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.1Pending状态 Pending状态:
说明Pod的YAML文件已提交给KubernetesAPI对象已经被创建并保存在Etcd当中 原因：这个Pod里有些容器因为某种原因而不能被顺利创建。
可能原因：
调度不成功
可以通过命令查看到当前Pod的事件，进而判断为什么没有调度。
kubectl describe pod {podname}
资源不足 原因：集群内所有的Node都不满足该Pod请求的CPU、内存、GPU等资源解决方法：增加资源配置/优化容器资源使用方式 HostPort 已被占用
解决方法：使用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.3CrashLoopBackOff状态 处于CrashLoopBackOff状态
说明容器曾经启动了，但又异常退出。
1.查看容器的日志，查看退出原因
kubectl logs {podname}
kubectl logs --previous {podname}
2.进入容器查看kubectl exec {mypodname} -c {containername} -it -- bash
3.ssh登录Node查看2.4ImagePullBackOff状态 处于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.自动重启的可能原因： Xms超出了k8s分配docker容器的内存限制出现OOMKilled事件
3.1Xms超出了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.2docker容器的内存限制 设置了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
总结 到此这篇关于K8S中Pod重启策略及重启可能原因的文章就介绍到这了,更多相关K8SPod重启策略及原因内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
