搜索结果: "node"

title: Node 排障 — NotReady 九步排查 / Kubelet / 容器运行时 / 资源压力 / 证书 / 预防

tags: [kubernetes, troubleshooting, node, production, monitoring, networking, certificate]

- raw/articles/k8s-node-notready-troubleshooting.md

# Node 排障

> Node 是 Pod 运行的基础底层，Node 不可用会直接影响其上所有 Pod。

FROM node:20.11-alpine3.19

FROM node:20.11-alpine3.19

| `node:20.11-alpine3.19` | ~5 MB | 生产推荐，最小化 Linux 环境 |

**原则：** 生产环境优先选 `alpine` 或 `slim` 版本。完整版本号锁定（如 `node:20.11.1-alpine3.19`），不用 `latest`。

node_modules/

K8s Node (物理/虚拟机)

nodeUsageMode: NORMAL

| `jenkins_node_online_count` | 在线 Agent 数 | = 0 持续 5min |

| `jenkins_node_disk` | Master 磁盘使用率 | > 85% |

| 构建任务一直 Pending | Agent Pod 创建失败或资源不足 | `kubectl describe pod ` 查看 Events + `kubectl top nodes` |

│ Worker Nodes │

| **Controller Manager** | 运行各类控制器 | Deployment/ReplicaSet/Node 等控制器持续调谐 |

### Worker Node 组件

| **NodePort** | 节点 IP:端口 | ClusterIP + 节点端口映射 | 开发调试、简单暴露 |

| **LoadBalancer** | 外部 LB | 云厂商 LB + NodePort | 生产对外服务 |

kubectl top nodes

kubectl describe node <node-name>

# 重点看：spec.nodeName, spec.nodeSelector, spec.affinity,

# 0/5 nodes are available: 3 Insufficient memory.

kubectl describe node <node> | grep -A5 "Allocated resources"

- 调度器检查：Node 已分配 Request 总量 + 新 Pod 的 Request ≤ Node 实际容量

- 容器实际使用超过 Request 仍可运行，但 Node 会发生资源超售

CPU 是"可压缩资源"（compressible resources）。Node 资源紧张时，K8s 通过降低 CPU 时间片"挤出"更多资源，

| Burstable | min(max(2, 1000 - 1000×memoryRequest/nodeMemory), 999) | 中等 |

Node 内存紧张时，**Pod A 反而更容易被 OOMKill**，即使它的 Request 是 2Gi。

1. `nodeName`（最高优先级，直接指定节点名，跳过调度器）

3. nodeSelector（简单标签匹配）

4. nodeAffinity（灵活的节点亲和性）

### 1. nodeSelector — 最简单的调度约束

nodeSelector:

### 场景二：集群外部通过 NodePort 访问

外部客户端 → NodeIP:NodePort → kube-proxy → EndpointIP:ContainerPort → PodB

外部请求到达任意节点的 NodePort，kube-proxy 将流量转发到后端 Pod（不一定是 Pod 所在节点）。

外部客户端 → Ingress Controller Pod → Ingress 规则匹配 → Service:NodePort → kube-proxy → PodB

- 从 Pod 内直接访问 Service IP（绕过 Ingress 和 NodePort）

tags: [kubernetes, troubleshooting, production, debugging, pod, node, service, storage, networking, security]

| **资源不足** | `kubectl top nodes` → 检查 Allocatable | 扩容节点 / 降低资源请求 / 清理低优 Pod |

| **污点/容忍** | `kubectl get node -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints` | 添加 tolerations 或临时 `kubectl taint node ... -` |

## 问题五：Node NotReady

**诊断入口：** `kubectl get nodes` → `kubectl describe node <node-name>`

- raw/articles/k8s-node-notready-troubleshooting.md

先看 **Node 状态**，再看 **Pod 状态**，最后看 **应用日志**。跳过底层基础设施直接看 Pod 内部容易误判。

| 4 | `kubectl top pod / kubectl top node` | 确认资源使用情况 |

- **集群层:** `kubectl get nodes`, `kubectl get events --all-namespaces`

| NotReady | `kubectl describe node` Conditions | 磁盘满、内存满、网络异常 |

kubectl top nodes

| Burstable | min(max(2, 1000 - 1000×memoryRequest/nodeMemory), 999) | 中等 |

Node 内存紧张时，**Pod A 反而更容易被 OOMKill**——尽管它的 Request 更大。

kubectl get node -o jsonpath='{.spec.taints}'

- `node.kubernetes.io/not-ready:NoExecute`

ssh <node> "sudo iptables -t nat -L -n | grep "

ssh <node> "sudo iptables -t filter -L FORWARD -n | grep KUBE"

ssh <node> "sudo ipvsadm -L -n"

ssh <node> "lsmod | grep ip_vs"

# 查看 calico-node 是否 Running

| inode 使用率 | > 80% | > 95% |

### Prometheus + node_exporter

rate(node_disk_io_time_seconds_total[5m]) * 100

rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) * 1000

rate(node_disk_read_bytes_total[5m]) / 1024 / 1024

> 磁盘满有三种情况：**空间真满** / **Inode 耗尽** / **文件已删但空间未释放**。不分清楚就删文件，可能白费力气。

### ② df -i — Inode 使用率

小文件太多时 inode 先于空间耗尽。每个文件消耗一个 inode（不管大小）。

copytruncate # 复制后截断，不改变 inode

- [[node-troubleshooting]] — K8s Node DiskPressure 处理（节点磁盘清理）

- **历史基线**：关键是和基线对比，Prometheus 用 `avg_over_time(node_load1[7d])` 计算 baseline

两次采样差值计算 CPU 使用率分布。Prometheus node_exporter 就是这样采集的。

同时失真的还有 `/proc/cpuinfo`（显示宿主机全部核数）和 `/proc/stat`（宿主机的 CPU 统计）。Java/Node.js 等运行时如果用 Load Average 做自适应调优，在容器内全部失效。

node_load5 / count without(cpu)(node_cpu_seconds_total{mode="idle"}) > 0.7

node_load5 / count without(cpu)(...) > 1.0

| **Buffer** | 块设备元数据缓存（superblock、inode bitmap 等），加速磁盘元数据操作 | `Buffers` | 内存紧张时可回收 |

| **Slab** | 内核对象缓存（dentry、inode、网络缓冲区等） | `SReclaimable` / `SUnreclaimable` | 可回收部分自动释放 |

SReclaimable: 520000 kB # 可回收 Slab（dentry、inode 缓存）

echo 2 > /proc/sys/vm/drop_caches # 释放 Slab（dentry/inode）

| inode_cache | inode 缓存 | 同上 |

| **文件系统** | IUse%, 文件系统类型 | df -Th, tune2fs, df -i | 磁盘空间够 ≠ 能写文件（Inode耗尽） |

文件系统是容易被忽视的第五个瓶颈维度。磁盘空间够 ≠ 能写文件（Inode 耗尽）。

df -i # Inode 使用率（小文件多时易踩坑）

- IUse% > 90% → Inode 即将耗尽（小文件密集场景预警）

- `df -i` 定期监控 Inode，别等到 100% 才发现

OTHER_NODE="192.168.1.11"

echo "Step 3: Verifying peer node health..."

ssh root@$OTHER_NODE "curl -s http://127.0.0.1/health" >/dev/null

echo "Peer node health check failed!"; exit 1

echo "Step 4: Restarting nginx on current node..."

### 误区一：sendfile / tcp_nopush / tcp_nodelay 三选一

tcp_nodelay on; # 禁用 Nagle 算法，小包立即发送（对交互式 API 重要）

**策略：** 对大文件下载（静态资源）用 `sendfile on + tcp_nopush on` 提升吞吐；对 API 代理用 `tcp_nodelay on` 降低延迟。三者可以同时开启——`tcp_nopush` 确保缓冲区满再发，`tcp_nodelay` 对个别小包突破此规则立即发送，互不矛盾。

limit_req zone=login_limit burst=3 nodelay;

limit_req zone=api_limit burst=20 nodelay;

limit_req zone=req_login burst=10 nodelay;

limit_req zone=req_sms burst=5; # 不加 nodelay：平滑排队

**`nodelay` vs 不加：**

- `nodelay` → 超过速率后快速拒绝，适合不允许多次重试的接口

- 不加 `nodelay` → 短时突刺被延迟处理，用户体验更平滑

- Created concepts: k8s-troubleshooting-principles, pod-troubleshooting, node-troubleshooting, service-troubleshooting, storage-troubleshooting, resource-rbac-scheduling-troubleshooting

- Created raw: raw/articles/k8s-node-notready-troubleshooting.md

- Merged into: node-troubleshooting

- Updated: k8s-rolling-update-pitfalls, k8s-statefulset-guide, node-troubleshooting（添加案例交叉引用）

- 覆盖：Pod Pending / CrashLoopBackOff / Service 访问失败 / 镜像拉取失败 / Node NotReady / 存储挂载异常 / 资源配额耗尽 / etcd 故障 / DNS 异常 / Pod 安全策略 — 10 大场景

| inode | 相同 | 不同 |

### 47. inode 与 block

- **inode**: 存储文件元数据（权限、大小、时间、block 位置）

- `df -i` 查看 inode 使用情况

| 6 | 什么是 Service？ | 暴露应用的稳定访问地址，类型：ClusterIP/NodePort/LoadBalancer/ExternalName | [[service-troubleshooting]] |

| 21 | Node/Pod Affinity？ | 控制 Pod 调度位置的规则（亲和性和反亲和性） | — |

| 66 | 服务发现和负载均衡？ | DNS 服务发现 + ClusterIP/NodePort/LoadBalancer/Ingress 负载均衡 |

| [[node-troubleshooting]] | 节点排障（NotReady/Kubelet/资源压力） |

kubectl describe node <node> | grep -A5 Conditions

**修复：** 分散定时任务执行时间、kubelet `--node-status-update-frequency=10s`（默认 10s）、`--node-monitor-grace-period=40s`。

kubectl drain <node> --ignore-daemonsets --dry-run=client

| [[node-troubleshooting]] | 案例 4：节点 NotReady 排查 |

# Message: "0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taints..."

kubectl top nodes

kubectl describe nodes | grep -A5 "Allocated resources"

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.taints[*].key}{"\n"}{end}'

kubectl top node

kubectl describe node | egrep -A3 'Allocated resources'

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85

avg by(instance) (rate(node_cpu_seconds_total{mode="softirq"}[5m])) * 100 > 25

节点可分配资源 = node allocatable - 系统预留 - DaemonSet 预留

### Node.js 容器

NODE_OPTIONS="--max-old-space-size=768" # RSS 需留余量

客户端 -> DNS -> 外部负载均衡 -> Ingress/Gateway API -> NodePort/ClusterIP -> kube-proxy -> Endpoints -> Pod

- **NodePort**：在每个节点开放端口，外部流量通过节点端口进入

- **LoadBalancer**：云厂商 LB + NodePort 组合

- [[k8s-scheduling-strategy-guide]] — K8s Pod 调度策略完全指南：nodeSelector/Affinity/Taint/Topology/PriorityClass 六大机制

- [[k8s-top10-troubleshooting-checklist]] — K8s 高频问题一站式排查清单：10 大故障场景快速参考（Pod Pending/CrashLoopBackOff/Node NotReady/etcd/DNS 等）

- [[node-troubleshooting]] — Node 排障：NotReady 九步排查 / Kubelet / 容器运行时 / 资源压力 / 证书

| 数据模型 | 树形 znode（持久/临时/顺序节点） |

| 数据模型 | 服务实例模型 | 树形 znode | 服务目录+KV |

1. **K8s Pod 状态** — `kubectl get pod -A -o wide` → 看 STATUS / IP / NODE 字段

升级后调用下游接口 30% 超时，排查发现超时 Pod 集中在 Node-B，该节点 `rp_filter=1` 而 Node-A 为 2。回包到宿主机后被 rp_filter 丢弃，未进入容器 veth。修复后恢复，后续做持久化基线治理。

vm.vfs_cache_pressure = 50 # 默认 100，降低后更倾向保留 dentry/inode 缓存

控制内核回收 VFS（dentry/inode）缓存的速度。文件操作密集场景降低此值可减少缓存回收频率，提升文件系统性能。

| 3. 客户端挂载状态异常 | 挂载点卡死、Stale file handle、df/ls 阻塞 | 服务端重启致 inode 变化、hard 挂载未设 intr |

- **根因**：服务端重启/导出路径 inode 变更，客户端缓存的 filehandle 失效

location /api/login { limit_req zone=login_limit burst=3 nodelay; ... }

location /api/ { limit_req zone=api_limit burst=20 nodelay; ... }

- node: Node 相关

**解决 MOVED：** 确保客户端开启集群模式（如 Spring Boot 配置 `spring.redis.cluster.nodes` + `max-redirects`）。

- **Node.js：** 无法使用 scratch，但可用 `node:18-alpine` + 多阶段构建分离 dev 依赖

| 6 | Prometheus 监控 K8s？ | Prometheus Operator + ServiceMonitor + Node Exporter + kube-state-metrics + 告警规则 | — |

| Kubernetes | 最终运行环境 | Master + Node |

| [[node-troubleshooting]] | Node 排障与 k8s-statefulset-guide 的 Pod 行为交叉 |

kubectl logs -n kube-system node-pod-name> --tail=100

- `vm.vfs_cache_pressure = 50`（保留 inode/dentry 缓存）

df -i # inode 使用情况

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

tcp_nodelay on; # 禁用 Nagle 算法（低延迟优先）