Pod异常问题排查

更新时间：2025-08-21

1.调度问题

Pod未调度到节点

如果Pod长时间处于“未调度到节点”（Pending）状态，没有被安排到任何节点上运行，可能是出于以下原因。

报错信息	说明	推荐的解决方案
no nodes available to schedule pods.	当前集群中无可用节点可供调度。	1. 查看集群节点状态是否为NotReady。如果存在节点处于NotReady状态，则对问题节点进行检查和修复。 2. 检查Pod中是否声明了nodeSelector、nodeAffinity或污点容忍。若不存在亲和性策略，可以增加节点。
0/x nodes are available: x Insufficient cpu. 0/x nodes are available: x Insufficient memory.	集群中没有可用节点能够满足Pod所需的CPU或内存资源。	在节点页面查看容器组、CPU、内存的使用情况，确定集群的资源使用率。说明当某个节点的CPU和内存利用率维持在较低水平时，即便引入一个新Pod不会立即达到资源使用的上限，调度器也会谨慎考虑，以防该Pod的加入导致未来高峰时段节点资源紧张，避免因资源分配不当而引发的节点资源短缺问题。若集群中的CPU或内存已经耗尽，可参考如下方法处理。 1.删除或减少不必要的Pod 2.根据自身业务情况，调整Pod的资源配置，重新配置容器Request和Limit。 3.根据Pod声明的亲和性策略在集群中添加新的节点。
x node(s) didn't match node selector. x node(s) didn't match pod affinity/anti-affinity.	集群现有节点没有匹配Pod声明的节点亲和性（nodeSelector）要求或Pod亲和性（podAffinity和podAnitiAffinity）要求。	1. 检查并调整Pod的节点亲和性策略，包括节点标签、nodeSelector、nodeAffinity、污点和容忍等。 2. 检查并调整Pod的Pod亲和性策略，评估节点是否满足Pod的亲和性要求：如果Pod配置了podAffinity，则需要检查目标节点上是否有匹配的Pod存在；如果配置了podAntiAffinity，则需确认目标节点上没有不应共存的Pod。
0/x nodes are available: x node(s) had volume node affinity conflict.	Pod所使用的存储卷与待调度的节点之间存在亲和性冲突，云盘无法跨可用区挂载，导致调度失败。	检查并调整Pod和存储卷的节点亲和性策略，包括节点标签、nodeSelector、nodeAffinity、污点和容忍等。
0/x nodes are available: x node(s) had taints that the pod didn't tolerate.	需要调度的节点打上了污点，不允许Pod调度到该节点上。	1.如果污点是由您手动添加，您可以删除非预期的污点。 2.如果无法删除污点，可以为Pod配置相应的容忍。 3.如果污点为系统自动添加，根据污点内容排查和解决问题，并等待Pod重新调度。
0/x nodes are available: pod has unbound immediate PersistentVolumeClaims.	Pod绑定PVC失败。	检查Pod所指定的PVC或PV是否已经创建，通过kubectl describe pvc 或kubectl describe pv 命令查看PVC、PV的Event信息，进一步进行判断。

Pod已调度到节点

如果Pod已经被调度到某个节点上但仍处于Pending状态，请参见下文解决。

判断Pod是否配置了hostPort：如果Pod配置了hostPort，那么每个节点上只能运行一个使用该hostPort的Pod实例。因此，Deployment或ReplicationController中Replicas值不能超过集群中的节点数。如果该端口被其他应用占用，将导致Pod调度失败。hostPort会带来一些管理和调度上的复杂性，推荐您使用Service来访问Pod。
如果Pod没有配置hostPort，请参见下方步骤排查。
a. 通过kubectl describe pod 命令查看Pod的Event信息，并解决对应的问题。Event可能会解释Pod启动失败的原因，例如镜像拉取失败、资源不足、安全策略限制、配置错误等。
b. Event中没有有效信息时，进一步查看该节点kubelet的日志，进一步排查Pod启动过程中存在的问题。您可以通过grep -i /var/log/messages* | less命令搜索系统日志文件（/var/log/messages*）中包含指定Pod名称的日志条目。

2.镜像拉取问题

报错信息	说明	推荐的解决方案
Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:	请求访问镜像仓库时被拒绝，创建Pod时未指定imagePullSecret。	检查Pod YAML中spec.template.imagePullSecrets指定的Secret是否存在。使用CCR企业版时，可以使用免密组件拉取镜像，请参见https://cloud.baidu.com/doc/CCE/s/4m0kru8g5。
Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host	通过HTTPS协议从指定的镜像仓库地址拉取镜像时，镜像地址解析失败。	1. 检查Pod YAML中spec.containers.image配置的镜像仓库地址是否正确。如有误，需修改为正确地址。 2. 如地址无误，进一步验证从Pod所在节点到镜像仓库的网络连接是否通畅。
Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device	节点磁盘空间不足。	登录到Pod所在节点，运行df -h查看磁盘空间状态。如磁盘已满，请扩容磁盘
Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled	操作取消，可能是由于镜像文件过大。Kubernetes默认存在拉取镜像超时时间，如果一定时间内镜像下载没有任何进度更新，Kubernetes会认为此操作异常或处于无响应状态，主动取消该任务。	1. 检查Pod YAML中配置的imagePullPolicy是否为IfNotPresent。 2. 登录到Pod所在节点，运行cmd命令docker pull或ctr images pull判断镜像是否可以被拉取。
Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)	无法连接镜像仓库，网络不通。	1. 登录到Pod所在节点，运行cmd命令curl https://xxxxxx/xxxxx/ 判断地址是否可以访问。如有报错，进一步判断是否存在网络配置、防火墙规则、DNS解析等网络访问问题。 2. 判断节点的公网策略是否正常，例如负载均衡BLB、安全组、绑定的弹性公网IP等配置。
一直显示Pulling image	可能触发了kubelet的镜像拉取限流机制。	通过自定义Kubelet参数功能调整registryPullQPS（镜像仓库的QPS上限）和registryBurst（突发性镜像拉取的个数上限）。

3.启动问题

Pod处于init状态

错误信息	说明	推荐的解决方案
停留在Init:N/M状态	该Pod包含M个Init容器，其中N个已经启动完成，但仍有M-N个Init容器未启动成功。	1. 通过kubectl describe pod -n 命令查看Pod的事件，确认当前Pod中未启动的Init容器是否存在异常。 2. 通过kubectl logs -n -c 命令查看Pod中未启动的Init容器的日志，通过日志内容排查问题。 3. 查看Pod的配置，例如检查健康检查配置，进一步确认未启动的Init容器配置是否正常。关于Init容器的更多信息，请参见调试Init容器。
停留在Init:Error状态	Pod中的Init容器启动失败。	同上
停留在Init:CrashLoopBackOff状态	Pod中的Init容器启动失败并处于反复重启状态。	同上

Pod创建中（Creating）

错误信息	说明	推荐的解决方案
Network plugin returns error: cni plugin not initialized	CNI网络组件未初始化导致pod无法创建	查看pod所在节点cce-network-agent和cce-network-operator状态，收集日志根据日志内容排查问题或提工单解决。
ce-network-agent is not running or ready on this node	cce-network-agent异常导致pod无法创建。	查看pod所在节点cce-network-agent状态，收集日志根据日志内容排查问题或提工单解决。

Pod启动失败（CrashLoopBackOff）

错误信息	说明	推荐的解决方案
日志中存在exit(0)。	日志中存在exit(0)。	1. 登录异常工作负载所在的节点。 2. 执行docker ps -a
Event信息中存在Liveness probe failed: Get http…。	健康检查失败。	核查Pod中所配置的容器健康检查（Liveness Probe）策略是否符合预期，能有效地反映出容器内应用程序的实际运行状况。
Pod日志中存在no left space。	磁盘空间不足。	1.扩容磁盘。 2.清理不必要的镜像，释放磁盘空间，并按需配置imageGCHighThresholdPercent，控制节点上触发镜像垃圾回收（Image GC）的阈值。
启动失败，无Event信息。	Pod中声明的Limit资源少于实际所需资源时，会导致启动容器失败。	检查Pod的资源配置是否正确。重新配置容器Request和Limit。
Pod日志中出现Address already in use。	同一Pod中的Container端口存在冲突。	1. 检查Pod是否配置了hostNetwork: true，这意味着Pod内的容器会直接与宿主机共享网络接口和端口空间。如果无需使用，请改为hostNetwork: false。 2. 如果Pod需要使用hostNetwork: true，请配置Pod的反亲和性，确保同一副本集中的Pod被调度到不通节点。 3. 检查并确保不存在也不会有两个或多个具有相同端口需求的Pod运行在同一台节点上。
Pod日志中出现container init caused "setenv: invalid argument"": unknown。	工作负载中挂载了Secret，但Secret对应的值没有进行Base64加密。	1.通过控制台创建Secret，Secret对应的值会自动进行Base64加密。 2.通过YAML创建Secret，并执行echo -n "xxxxx"
自身业务问题。	-	查看Pod日志，通过日志内容排查问题。

4.Pod运行问题

OOM

当集群中的容器使用超过其限制的内存，容器可能会被终止，触发OOM（Out Of Memory）事件，导致容器异常退出。关于OOM事件，请参见为容器和Pod分配内存资源。

若被终止的进程为容器的阻塞进程，可能会导致容器异常重启。
若集群配置了集群容器副本异常报警，OOM事件出现时会收到相关报警信息。

Terminating

可能原因	说明	推荐的解决方案
节点存在异常，处于NotReady状态。	-	处于NotReady状态的节点恢复正常后会被自动删除。
Pod配置了Finalizers。	如果Pod配置了Finalizers，Kubernetes会在删除Pod之前执行Finalizers指定的清理操作。如果相关的清理操作没有正常响应，Pod将保持在Terminating状态。	通过kubectl get pod -n -o yaml查看Pod的Finalizers配置，进一步排查异常原因。
Pod的preStop配置异常。	如果Pod配置了preStop，Kubernetes会在容器被终止之前执行preStop指定的操作。Pod正处于终止流程的preStop阶段时，Pod将处于Terminating状态。	通过kubectl get pod -n -o yaml查看Pod的preStop配置，进一步排查异常原因。
Pod配置了优雅退出时间。	如果Pod配置了优雅退出时间（terminationGracePeriodSeconds），Pod收到终止命令后（例如kubectl delete pod <pod_name>命令）会进入Terminating状态。等待terminationGracePeriodSeconds设定的时间后，或容器提前退出后，Kubernetes才认为Pod已经成功关闭。	等待容器优雅退出后，Kubernetes将自动删除Pod。
容器无响应。	发起停止或删除Pod的请求后，Kubernetes会向Pod内的容器发送SIGTERM信号。如果容器在终止过程中没有正确响应SIGTERM信号，Pod可能会停留在Terminating状态。	1. 使用kubectl delete pod --grace-period=0 --force强制删除，释放Pod资源。 2. 检查Pod所在节点的containerd或Docker日志，进一步进行排查。

Evicted

可能原因	说明	推荐的解决方案
节点存在资源压力，包括内存不足、磁盘空间不足等，引发kubelet主动驱逐节点上的一个或者多个Pod，以回收节点资源。	可能存在内存压力、磁盘压力、Pid压力等。可以通过kubectl describe node ｜grep Taints命令查询。 1.内存压力：带有污点node.kubernetes.io/memory-pressure。 2.磁盘压力：带有污点node.kubernetes.io/disk-pressure。 3.Pid压力：带有污点node.kubernetes.io/pid-pressure。	1.内存压力：根据自身业务情况，调整Pod的资源配置。或增加节点。 2.磁盘压力：定时清理节点上的业务Pod日志，防止磁盘空间被耗尽。或为节点进行磁盘扩容。 3.Pid压力：根据自身业务情况，调整Pod的资源配置，请参见进程ID约束与预留。
发生了非预期的驱逐行为。	待运行Pod的节点被手动打上了NoExecute的污点，导致出现非预期的驱逐行为。	通过kubectl describe node ｜grep Taints命令检查节点是否被打上了NoExecute污点。如是，请删除。
未按照预期流程执行驱逐。	--pod-eviction-timeout（before 1.26）：当节点宕机时间超过设置时间后，开始驱逐宕机节点上的Pod，默认为5min。 --node-eviction-rate：每秒从节点上驱逐的Pod数量。默认为0.1，即每10s至多从一个节点上驱逐Pod。 --secondary-node-eviction-rate：第二档的节点驱逐速率。当集群中宕机节点过多时，节点驱逐速率会降低至第二档，默认值为0.01。 --unhealthy-zone-threshold：可用区的不健康阈值，默认为0.55，即当宕机的节点数量超过总节点数的55%时，该可用区被判定为不健康。 --large-cluster-size-threshold：集群的大规模阈值，默认为50，即当集群节点数量超过50时判定集群为大规模集群。	在小规格的集群（集群节点数小于等于50个节点）中，如果故障的节点大于总节点数的55%，实例的驱逐会被停止，更多信息请参见节点驱逐速率限制。在大规模集群中（集群节点数大于50），如果集群中不健康的节点数量占总节点数的比例超过了预设的阈值--unhealthy-zone-threshold（默认为0.55），驱逐速率由--secondary-node-eviction-rate控制（代表每分钟驱逐节点上Pod的最大比例），默认值为0.01。更多信息，请参见节点驱逐速率限制。
容器被驱逐后仍然频繁调度到原节点。	节点驱逐容器时会根据节点的资源使用率进行判断，而容器的调度规则是根据节点上的“资源分配量”进行判断，被驱逐的Pod有可能被再次调度到这个节点，从而出现频繁调度到原节点的现象。	根据集群节点的可分配资源检查Pod的资源Request请求配置是否合理

Completed

Completed状态下，Pod中容器的启动命令已执行完毕，容器中的所有进程均已成功退出。Completed状态通常适用于Job、Init容器等。

5.其他常见问题

Pod状态为Running但没正常工作

如果您的业务YAML存在问题，Pod可能会处于Running状态但没有正常工作。您可以参见以下流程解决。

查看Pod的配置，确定Pod中容器的配置是否符合预期。
使用以下方法，排查环境变量中的某一个Key是否存在拼写错误。创建Pod时，如果环境变量中的某个Key拼写错误，集群会忽略该错误并使用该YAML成功创建资源。但在容器运行过程中，系统无法执行YAML文件中指定的命令。
a. 在执行kubectl apply -f命令前为其添加--validate，然后执行kubectl apply --validate -f XXX.yaml 命令。如拼写存在错误，会提示报错。
b. 执行以下命令，将输出结果的pod.yaml与您创建Pod使用的YAML进行对比。

Plain Text

1 kubectl get pods [$Pod] -o yaml > pod.yaml

1.pod.yaml文件比您创建Pod所使用的文件行数更多，表明已创建的Pod符合预期。
2.如果您创建Pod的YAML代码行不存在于pod.yaml文件中，表明YAML中存在拼写问题。

查看Pod的日志，通过日志内容排查问题。
通过终端进入容器，查看容器内的本地文件是否符合预期。

CCE典型实践之容器网络模式选择

通过 CCE Ingress 实现虚机和容器服务的统一接入

容器引擎 CCE