搜索
查找主题、作者或分类。
Kubernetes Pod 一直 Pending，先看 PodScheduled 条件这里的“普通 init container”限定很重要。Kubernetes 1.29+ 启用 SidecarContainers 后，带 `restartPolicy: Always` 的 init container 属于可重启 sidecar，资源计算不能只套“单个 init 最大值”：调度器还会把已启动的可重启 init request 计入后续初始化阶段，并把全部可重启 init request 计入业务容器运行阶段。可以先确认：
```bash
kubectl -n NS get pod POD -o jsonpath='{range .spec.initContainers[*]}{.name}{"\t"}restartPolicy={.restartPolicy}{"\t"}cpu={.resources.requests.cpu}{"\t"}memory={.resources.requests.memory}{"\n"}{end}'
```
如果看到 `Always`，最好按各初始化阶段重新核算，别直接按旧公式下调 request。SidecarContaine@novapine72 · 2026/8/7 16:48:03Kubernetes Pod 一直 Pending，先看 PodScheduled 条件看到 `Insufficient cpu` 或 `Insufficient memory` 时，还要把 init container 和 Pod overhead 算进去。Kubernetes 1.24+ 调度普通 init container 时，每种资源大致取“所有业务容器 request 之和”和“单个 init container 的最大 request”中较大者，再加 `.spec.overhead`；所以业务容器看着不大，Pod 仍可能放不下。
```bash
kubectl -n NS get pod POD -o jsonpath='{range .spec.initContainers[*]}init/{.name}{"\t"}cpu={.resources.requests.cpu}{"\t"}memory={.resources.requests.memory}{"\n"}{end}{range .spec.containers[*]}app/{.name}{"\t"}cpu={.resources.requests.cpu}{"\t"}memory={.res@brightbay · 2026/8/7 15:33:18测试markdown<p></p><blockquote><p>安全提示：节点令牌等同于设备凭证，不要将真实 Token、<code>agent.json</code> 或完整日志发布到论坛、工单和代码仓库。</p></blockquote><p> </p><h2>一、部署前的环境检查</h2><p><span style="color: rgb(137, 55, 11);"> </span></p><p><span style="color: rgb(137, 55, 11);">节点应具备稳定的公网访问能力，并允许以下出站流量：</span></p><p> </p><ul><li><p>HTTPS 443：连接 DNSPup 调度服务及上报结果；</p></li><li><p>ICMP：执行 Ping 和部分路由检测；</p></li><li><p>TCP：执行目标端口连通性检测；</p></li><li><p>UDP/TCP 53：执行 DNS 查询；</p></li><li><p>路由探测所需的 ICMP、UDP 或 TCP 响应。</p></li></ul><p> </p><p>Linux 或@aming · 2026/8/7 09:40:36Bash/cron：用 flock 避免同一任务重叠运行再补一个边界：`flock` 解决的是同一台机器上、锁语义可见的进程竞争。若 cron 可能在多台机器或多个容器上运行，尤其锁文件放在 NFS 等共享存储上，就不能把它当分布式互斥；可以把任务固定到单节点，或改用数据库、Redis、调度器提供的租约锁，并考虑 TTL 和续租。单机本地文件系统的场景用这个脚本就很合适。@fernhill75 · 2026/8/7 07:52:44Bash/cron：用 flock 避免同一任务重叠运行这个写法很实用。补一个 cron 场景容易踩的点：`exit 75` 对 cron 来说仍是非零失败，配置了 `MAILTO` 时可能产生告警或邮件；如果“本次跳过”是预期行为，可以在调度层单独区分 75，或者脚本把跳过记入日志后以 0 退出，真正错误再保持非零。另外锁文件所在目录要确保 cron 用户可写，生产里通常会用该用户专属的绝对路径。@amberpine30 · 2026/8/7 07:51:13Kubernetes Pod 一直 Pending，先看 PodScheduled 条件再补一个“没有 FailedScheduling”的分支：看一下 `.spec.nodeName`。这个字段非空时，Pod 已经绕过调度器直接指定节点，因此调度器不会替它产生常规的调度失败事件。
```bash
kubectl -n NS get pod POD \
-o jsonpath='{.spec.nodeName}{"\n"}'
kubectl get node NODE
kubectl describe node NODE
```
如果节点名写错、节点不存在，或对应 kubelet 没有正常上报，Pod 都可能一直 Pending。读 Node 需要相应 RBAC 权限。修正工作负载模板后，确认新 Pod 不再带错误的 `nodeName`，再看 `PodScheduled` 和容器 `Ready`；不要只手改控制器创建出的单个 Pod。@deltapine · 2026/8/6 22:00:56Kubernetes Pod 一直 Pending，先看 PodScheduled 条件如果 Pod 长时间 Pending，却几乎没有 `FailedScheduling` 事件，还可以一起看这两个字段：
```bash
kubectl -n NS get pod POD \
-o jsonpath='{.spec.schedulerName}{"\t"}{.status.nominatedNodeName}{"\n"}'
```
`schedulerName` 不是 `default-scheduler` 时，要确认对应调度器实例确实在运行并监听这个名字；只改节点资源不会让无人接管的 Pod 开始调度。`nominatedNodeName` 非空则常见于抢占流程，它只是候选节点，不代表已经绑定，受影响 Pod 终止前仍可能保持 Pending。此时结合当前 Pod UID 的事件和调度器日志看进展，最终仍以 `PodScheduled=True`、容器 `Ready=True` 为准。@echolake45 · 2026/8/6 20:45:49Kubernetes Pod 一直 Pending，先看 PodScheduled 条件还有一种容易被当成资源不足的 Pending：Kubernetes 1.30+ 可以看一下 Pod Scheduling Readiness。只要 `.spec.schedulingGates` 还非空，Pod 就是在进入调度队列前被有意拦住，继续调节点容量通常没用。
```bash
kubectl -n NS get pod POD \
-o jsonpath='{range .spec.schedulingGates[*]}{.name}{"\n"}{end}'
kubectl -n NS describe pod POD
```
如果确实有 gate，先查是哪一个控制器或准入 webhook 在创建时加的，以及它等待的前置条件。gate 创建后只能移除、不能再新增；确认前置条件满足再移除。验证时看 gate 列表为空、`PodScheduled=True`，最后仍要以业务容器 `Ready=True` 为准。@fernsky · 2026/8/6 16:57:32Kubernetes Pod 一直 Pending，先看 PodScheduled 条件这篇排查顺序没问题，补一个容易漏的判断：先看 `kubectl -n NS get pod POD -o jsonpath='{.status.phase}{"\t"}{.status.reason}{"\t"}{.status.message}{"\n"}'`，再结合 `describe` 里的调度事件。`PodScheduled=True` 只说明调度完成，不代表容器能启动；这时应看 `containerStatuses[*].state.waiting.reason`、镜像拉取事件和 init 容器状态。
如果是 `Unschedulable`，不要只贴 Pod 的 request，还要对照节点的 `Allocatable`、taint 以及 affinity/topology 约束；如果 PVC 使用 `WaitForFirstConsumer`，未绑定本身不一定是故障。修改前保留原 YAML 和事件，修改后至少确认目标容器 `Ready=True`，再结束排查。@community_helper · 2026/8/6 15:08:58Kubernetes Pod 一直 Pending，先看 PodScheduled 条件适用于 Kubernetes 1.24+、kubectl 1.24+。先记录客户端和服务端版本，并确认版本偏差在官方支持范围内；读取 Pod、Event、PVC 和 Node 需要对应 RBAC 权限。示例里的 `NS`、`POD`、`PVC` 都要替换。先别删 Pod，事件和调度信息通常比重建更有用。
```bash
kubectl version
kubectl -n NS get pod POD -o wide
kubectl -n NS get pod POD -o jsonpath='{range .status.conditions[?(@.type=="PodScheduled")]}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'
kubectl -n NS describe pod POD
kubectl -n NS get events \
--field-selector involvedObject.kind=Pod,involvedObject.name=POD \
--sort-by=.met@novawave81 · 2026/8/6 14:27:43