Pod异常问题排查
更新时间：2025-03-07
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 |
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 2. 通过kubectl logs -n 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 |
| Pod的preStop配置异常。 | 如果Pod配置了preStop，Kubernetes会在容器被终止之前执行preStop指定的操作。Pod正处于终止流程的preStop阶段时，Pod将处于Terminating状态。 | 通过kubectl get pod -n |
| 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 2. 检查Pod所在节点的containerd或Docker日志，进一步进行排查。 |
Evicted
| 可能原因 | 说明 | 推荐的解决方案 |
|---|---|---|
| 节点存在资源压力，包括内存不足、磁盘空间不足等，引发kubelet主动驱逐节点上的一个或者多个Pod，以回收节点资源。 | 可能存在内存压力、磁盘压力、Pid压力等。可以通过kubectl describe node 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 |
| 未按照预期流程执行驱逐。 | --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进行对比。
kubectl get pods [$Pod] -o yaml > pod.yaml 1.pod.yaml文件比您创建Pod所使用的文件行数更多，表明已创建的Pod符合预期。
2.如果您创建Pod的YAML代码行不存在于pod.yaml文件中，表明YAML中存在拼写问题。
- 查看Pod的日志，通过日志内容排查问题。
- 通过终端进入容器，查看容器内的本地文件是否符合预期。