k8s之pod异常状态说明
# 一，前言
记录pod的常见异常状态和原因, 方便日后查看。
# 二，Terminating
表示pod被删除的状态。
pod删除流程:
api-server收到删除请求, 将pod标记为被删除, 此时pod处于Terminating状态。
kubelet watch到pod被删除, 开始销毁pod。
kubelet 调用cri清理容器接口。
cri容器全部清理成功, 通知给api-server。
api-server感知到pod成功销毁, 再检查metadata中finalizers, 如果还有就等待着关联资源清理完, 如果finalizers结束了, 再从etcd中删除pod数据, 流程结束。
卡在terminating的原因分析:
1. 节点, kubelet, cri 异常
根据流程来看, 节点, kubelet, cri异常导致容器清理失败, 没有办法通知到api-server去修改状态, 具体原因可能是节点宕机, 节点负载过高, 节点网络异常等问题
2. finalizers 异常
finalizers的关联删除机制, 需要等到关联的程序处理结束去把finalizers字段删掉, api-server才会真正清除pod, 如果关联程序或者资源异常, 也会卡在terminating
3. terminationGracePeriodSeconds 值过大
pod中的平滑关闭时间设置的过大(默认为30秒), 导致卡很久
# 三，Pending
表示pod待调度状态。
卡在pending的原因分析:
1. 资源不足
比较常见的原因, 比如集群可分配的内存, gpu等资源不足
2. nodeSelector, affinity问题
pod调度不满足节点标签, 或者节点亲和性 pod亲和性等
3. taint问题
节点存在pod没有设置容忍的污点
4. 调度组件的问题
本身就是调度器执行的操作, 所以kube-scheduler组件异常, 也会导致没有办法调度
# 四，CrashLoopBackOff
表示服务启动之后异常退出的状态。
原因分析:
1. 业务异常,主动退出
Exit Code 0, 可以通过kubectl logs查看业务日志。
2. OOM异常(cgroup OOM, 系统OOM)
Exit Code 137, 例如 limit设置小了出问题, 节点系统OOMkiil掉对应服务, 存活探针失败。
3. 物理机异常(重启)
Exit Code 255, 物理机重启导致容器重启。
# 五，ImagePullBackOff
表示容器镜像拉取失败。
原因分析:
1. 镜像权限异常(registry secret不存在或者不对)
2. 镜像异常(不存在,超时)
扫码关注我
天府云计算架构茶话会