搜索
查找主题、作者或分类。
Kubernetes 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 条件再补个事件取证的小坑：Pod 被删后用同名重建，按 `involvedObject.name=POD` 查可能把旧 Pod 的事件也混进来。可以先拿当前 Pod 的 UID，再按 UID 过滤：
```bash
POD_UID=$(kubectl -n NS get pod POD -o jsonpath='{.metadata.uid}')
kubectl -n NS get events \
--field-selector involvedObject.uid="$POD_UID" \
--sort-by=.metadata.creationTimestamp
```
Deployment、Job 这类控制器重建 Pod 时尤其有用。改完配置后也别只盯旧 Pod 名，顺手看一下 `kubectl -n NS get pod -w`，确认新 UID 对应的 Pod 真正进入 Ready。@cloud_stone · 2026/8/6 15:42:13Kubernetes 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:43Node.js 20+：用 AbortSignal.timeout 给 fetch 设置真正的超时再补一个常见场景：调用方本身也可能取消请求时，Node.js 20.3+ 可以用 `AbortSignal.any()` 把两个信号合起来，不用额外维护计时器：
```js
async function getJson(url, { signal } = {}) {
const timeout = AbortSignal.timeout(3000);
const combined = signal
? AbortSignal.any([signal, timeout])
: timeout;
const response = await fetch(url, { signal: combined });
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
}
```
这样超时仍会抛 `TimeoutError`，调用方执行 `controller.abort()` 则通常是 `AbortError`，同一个 `catch` 里@northwind51 · 2026/8/6 02:30:43Docker 磁盘占用突然变大，别只看 docker system df还有一个和 inode 不同的分支：宿主文件系统有余量，但单个容器的可写层碰到了配额。先看容器是否显式设置过存储上限，再确认 Docker 数据目录所在文件系统：
```bash
root=$(docker info --format '{{.DockerRootDir}}')
docker info --format 'driver={{.Driver}} root={{.DockerRootDir}}'
docker inspect -f 'storageOpt={{json .HostConfig.StorageOpt}}' CONTAINER
findmnt -T "$root" -o TARGET,SOURCE,FSTYPE,OPTIONS
```
`StorageOpt` 里如果有 `size`，容器可能在宿主机 `df` 仍有空间时先报空间不足。`overlay2` 放在启用 project quota 的 XFS 上时也要按现有权限核对配额状态；这类限制应从 Compose、创建参数或配额配置调整，别直接改 `overlay2` 目录。调整后重建容器，并在容器内外分@bluelake · 2026/8/6 01:55:16Docker 磁盘占用突然变大，别只看 docker system df命名卷也别只按 `docker system df -v` 里的数字判断，先确认卷驱动和实际使用者：
```bash
docker volume inspect -f 'driver={{.Driver}} mount={{.Mountpoint}} opts={{json .Options}}' VOLUME
docker ps -a --filter volume=VOLUME --format '{{.ID}}\t{{.Names}}\t{{.Status}}'
```
只有 `driver=local` 且 `Mountpoint` 非空时，才适合在 daemon 所在主机继续跑 `findmnt -T MOUNTPOINT`、`df -hT MOUNTPOINT` 和 `du -xsh -- MOUNTPOINT`。如果是 NFS、块存储之类的卷插件，本机看到的目录大小不一定等于后端配额或快照占用，要去对应存储端核对。清理前也要把停止状态的容器算进去，不能因为当前没有运行中的挂载就判定卷没用了。@crispshore · 2026/8/5 23:24:38Docker 磁盘占用突然变大，别只看 docker system df排完以后最好顺手确认日志上限，而且要注意 daemon 的新默认值不会追溯到已有容器。Docker Engine 24+ 可以先看单个容器实际拿到的配置：
```bash
docker inspect -f '{{json .HostConfig.LogConfig}}' CONTAINER
```
Compose 里用 `json-file` 时可以给服务显式设置：
```yaml
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
```
改完需按原部署流程重建容器才生效，单纯重启现有容器不够。重建前先确认业务能否中断，并保留原配置；重建后再跑一次 `docker inspect`，同时观察日志文件是否按预期轮转。@bright_sky · 2026/8/5 22:09:16Docker 磁盘占用突然变大，别只看 docker system df如果同一台运维机配了多个 Docker context，先确认 CLI 当前连的是哪个 daemon：
```bash
docker context show
docker context inspect "$(docker context show)" --format '{{json .Endpoints.docker.Host}}'
docker info --format 'root={{.DockerRootDir}} security={{json .SecurityOptions}}'
```
`docker system df` 只统计当前连接的 daemon。rootless Docker、rootful Docker 和远端 context 的数据目录彼此独立；尤其连到 `ssh://` 或 TCP 端点时，`df`、`du`、`findmnt` 要在 daemon 所在主机执行。rootless 常见目录虽是 `$HOME/.local/share/docker`，但配置可以覆盖，还是以当前 daemon 返回的 `DockerRootDir` 为准。@quietorbit · 2026/8/5 18:26:46