Kubernetes系列-pod状态异常原因分析

转载自博客：https://blog.csdn.net/ygq13572549874/article/details/128836960

pod是业务运行的基础环境，但是在不同阶段，pod会因为某种事件发生状态变更，那么当pod状态异常时，应该如何排查呢？排查思路如下图。

 

1. 前置条件

pod运行在node实例中，那么可能引起pod异常的原因就是node异常，因此首先需要排出node节点异常。

kubectl get nodes

如果存在非reday状态，那么确认异常pod是否在一场node上部署，如果是，则需要将pod迁移至正状态正常的node上，一般情况，k8s集群会自动调度pod至正常状态的node上，不需要手动迁移。

2. pod异常状态分析
2.1 pod状态为CrashLoopBackOff

kubectl  logs <podname> -n <namespace> 

kubectl describe pod <podname> -n <namespace>

.2 pod状态为Pending
pod状态为Pending状态，说明调度失败，通常跟污点、标签、cpu、内存、磁盘等资源相关

kubectl describe pod <podname> -n <namespace>
2.3 pod状态为Init:0/1
通过kubectl get pod <podname> -n <namespace> -o yaml查pod的Init Containers，并找到init_container_name。

# 查看Init Container的日志
kubectl logs -n <namespace> <podname> -c <init_container_name>

2.4 pod状态为Terminating
2.4.1 pod或其控制器被删除
解决方案：

1）查看pod控制器类型和控制器名称，查看其控制器是否正常。

2）如果正常pod将会被重建，如果pod没有被重建，查看controller-manager是否正常

2.4.2 pod所在节点状态NotReady导致
解决方法：
1）检查该节点的网络，cpu，内存，磁盘空间等资源是否正常。
2）检查该节点的kubelet、docker服务是否正常。
3）检查该节点的网络插件pod是否正常。

2.4.3 正常变更，强制删除
kubectl delete pods -n <namespace> <name> --grace-period=0 --force
2.5 pod状态为Evicted
2.5.1 node节点资源达到指定阈值
原因：kubelet服务启动时存在驱逐限制当节点资源可用量达到指定阈值。资源阈值如下：

magefs.available<15%
memory.available<300Mi
nodefs.available<10%
nodefs.inodesFree<5%
当podnode资源达到以上限制会优先驱逐Qos级别低的pod以保障Qos级别高的pod可用

解决方法：增加节点资源或将被驱逐的pod迁移到其他空闲资源充足的节点上

2.5.2 node被设置污点
原因pod所在节点上被打上了NoExecute的污点，此种污点会将该节点上无法容忍此污点的pod进行驱逐
解决方法：查看该节点上的NoExecute污点是否必要，或对pod是否可以迁移到其他节点。

2.5.3 pod所在的节点为NotReady状态
通常可以通过的底部的Events信息来找到一些问题的原因。例如下面例子中可以看到DiskPressure信息，说明跟磁盘相关。

Events:
---- ------ ---- ---- -------
Warning Evicted 61s kubelet, acs.deploy The node had condition: [DiskPressure]

kubectl describe pods <pod> -n <namespace>

批量删除状态Evicted的pod，此操作会删除集群里面所有状态为Evicted的pod。

ns=`kubectl get ns | awk 'NR>1 {print $1}'`
for i in $ns
do
kubectl get pods -n $i | grep Evicted| awk '{print $1}' | xargs kubectl delete pods -n $i
done

2.5.4 pod状态为Unknown
通常该状态为pod对应节点的为NotReady

kubectl get node
2.5.5 pod为running，但是Not Ready状态
argo-ui-56f4d67b69-8gshr 0/1 Running
猜测是pod的readiness健康检查没过导致的。

kubectl get pods -n <namespace> <name> -o yaml
找到健康检查部分，关键字为readiness，然后进入pod中执行健康检查命令确认。

2.5.6 pod为ContainerCreating状态

kubectl describe pods -n <namespace> <name> 

查看输出的events事件部分

Pod无法正常启动，出现CrashLoopBackOff状态。这个状态表示Kubernetes已经尝试了多次重新启动Pod，但是每次都失败了。

这种情况的原因有很多，以下是一些常见的原因以及相应的解决方法：

容器镜像拉取失败：可能是由于网络问题导致容器镜像无法下载。可以尝试使用 kubectl describe pod <pod-name> 命令来查看更详细的错误信息，如果是网络问题，则需要排除网络故障或者使用私有镜像仓库。

Pod配置中的容器命令或参数错误：容器启动时，Kubernetes将执行定义在Pod配置文件中的命令和参数。如果其中任何一个存在错误，则容器将无法启动。可以使用 kubectl logs <pod-name> <container-name> 命令来获取容器的日志，这有助于快速诊断问题。

资源限制不足：Kubernetes会根据集群资源情况分配CPU、内存等资源给每个Pod。如果Pod所需的资源超过了集群可用的资源，则Pod将无法启动。可以尝试增加节点数量或者减少Pod所需资源量来解决问题。

存储卷挂载失败：如果Pod的配置包含存储卷，但是存储卷挂载失败，则容器可能无法启动。可以使用 kubectl describe pod <pod-name> 命令来查找存储卷挂载错误信息，并尝试修复错误。

Pod被误删除：如果Pod被意外删除，Kubernetes可能会尝试重新启动Pod。如果没有正确配置Pod的持久性存储，则该Pod将无法重新启动。可以使用 kubectl get pods --all-namespaces 命令来查看是否存在已经删除的Pod。

这些是一些常见的Pod无法正常启动的原因和解决方法，当遇到类似的问题时，建议先确定问题的原因，然后针对性地解决问题。

 转载自博客：https://www.cnblogs.com/wblinux/articles/15841684.html

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：网络插件还没有完全启动