彻底搞懂 K8S Pod Pending 故障原因及解决方案

发布时间：2025-11-05 07:22:26 来源：创站工坊 作者：应用开发

即使在高成熟度级别 Kubernetes 集群中 pod pending 也是彻底无处不在。

如果您随机询问任何使用 Kubernetes DevOps 工程师来确定折磨他们噩梦的搞懂故障最常见错误，pod pending 可能是原因非常常见的问题（可能仅次于 CrashLoopBackOff）。

尝试推送更新并看到它卡住会使 DevOps 紧张。及解决方即使解决方案相当简单，彻底找到 pod 挂起的搞懂故障原因并了解您需要应用的更改也很重要（Kubernetes 故障排除很少是微不足道的）。

在本文中，原因我们将阐明导致此问题的及解决方不同情况，让 DevOps 团队能够快速找到解决方案，彻底最重要的搞懂故障是，尽可能避免它。原因

Kubernetes 中的 Pod 的生命周期由几个不同的阶段组成：

大多数 pod 只需要几秒钟就可以从 Pending 到 Running 并在该状态下度过大部分时间。

至此，Pod 已被 Kubernetes 集群接受。但是免费源码下载一个或多个容器尚未准备好对外提供服务。这包括 Pod 等待调度所花费的时间以及通过网络下载容器镜像所花费的时间。

当 pod 无法从 PendingtoRunning 阶段前进时，生命周期将停止并保留 pod，直到阻止它前进的问题得到修复。

如果我们使用 kubectl 列出 pod，我们将看到显示 Kubernetes pod 挂起情况的输出：

除非我们解决问题，否则 pod 被卡住并且不会运行。

排查 Kubernetes pod Pending 的常见原因

有几个原因可以阻止 Pod 运行，但我们将描述三个主要问题：

第一个是最常见的，最后一个很少见。让我们详细说明每种情况。

创建 Pod 后，Kubernetes 集群做的第一件事就是尝试调度 Pod 在其中一个节点上运行。这个过程通常非常快，并且 pod 被快速分配给具有足够资源来运行它的节点。

为了放置它，集群中的 Pod 被分配给具有更多未请求资源的高防服务器节点，并继续其快乐而美好的生活，其中充满了对请求的符合 SLO 的回复。

但是，如果此过程每次都有效，有几个因素可能导致集群无法分配 pod。

让我们回顾一下最常见的。

Kubernetes 使用调度请求来决定fits节点中是否有 pod。资源的真正使用无关紧要，只有其他 pod 已经请求的资源。

effective requests当一个 pod 有足够的可请求资源来参与该 pod 的内存和 CPU 时，它将被调度到一个节点中。并且节点必须没有达到它可以运行的最大 pod 数。

当没有任何节点满足 pod 的所有要求时，它将保持在 Kubernetes pod 挂起状态，直到释放一些资源。

由于不同的问题（节点压力）或人为行为（节点封锁），节点可能会变为不可调度的站群服务器状态。这些节点在状态发生变化之前不会调度任何 pod。

污点是 Kubernetes 的一种机制，它允许我们限制可以分配给不同节点的 pod。当节点具有 taint 时，只有匹配容忍度的 pod 才能在该节点中运行。

这种机制允许 Kubernetes 的特殊用途，例如为不同的工作负载使用不同类型的节点（具有 GPU 的节点，具有不同的 CPU/内存比率等）。

即使我们分别描述每个原因，调度问题也往往是由这些问题的组合引起的。通常，您无法调度，因为某些节点已满而其他节点已被污染，或者某个节点可能由于内存压力而无法调度。

为了找出调度问题是什么，您需要查看调度程序生成的关于 pod 的事件，其中将详细描述阻止节点分配的原因。我们可以使用 kubectl describe 查看事件，例如：

我们可以在输出中看到消息中的确切原因：

为了解决这个问题，我们有两个选择：

如果要更新当前运行的工作负载，还需要考虑另一个重要因素：升级策略。

由于此策略，Kubernetes 可以允许工作负载在更新过程中创建比平时更多的 Pod，在创建新 Pod 时保留旧 Pod 一段时间。这意味着工作负载可能会在一段时间内请求比预期更多的资源。如果集群没有足够的备用资源，更新将被阻塞，留下一些 pod 待处理，直到进程被解除阻塞（或回滚超时停止更新）。

由于镜像问题，Pod Pending

一旦在一个节点中分配了 pod，kubelet就会尝试启动 pod 中的所有容器。为此，它将尝试下载镜像并运行它。

有几个错误会阻止镜像被下载：

Kubernetes Pod 由于依赖问题而挂起

在 pod 启动之前，kubelet将尝试检查与其他 Kubernetes 元素的所有依赖关系。如果无法满足这些依赖项之一，则 pod 将保持挂起状态，直到满足依赖项。

在这种情况下，kubectl 将像这样显示 pod：

在事件中，我们可以看到如下内容：

该 Message 列将为您提供足够的信息，以便能够查明缺失的元素。常见的原因有：

结论

了解 pod 保持在该 Pending 阶段的原因是在 Kubernetes 中安全部署和更新工作负载的关键。能够快速定位问题并加快部署进度将为您省去一些麻烦并减少停机时间。

相关文章