【K8S系列】Pod重启策略及重启可能原因
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状态:
- 说明Pod的YAML文件已提交给Kubernetes
- API对象已经被创建并保存在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.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.自动重启的可能原因:
- Xms超出了k8s分配
- docker容器的内存限制
- 出现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
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
2021-12-27 常见内网穿透工具使用总结