Longhorn

概述 2026 年 6 月，homelab 四 worker 集群里 k8s-50 在 Grafana 上 CPU 长期偏高（一度接近 80%），而同节点的 Descheduler 每 15 分钟跑一轮却从不驱逐 Pod。排查、加看板、补配置、放宽调度约束之后，Nexus 从 k8s-50 迁到了 k8s-71，节点负载肉眼可见地降了下来。 本文按时间线记录全过程；概念细节见 Descheduler 与 Resource Requests。 时间线 阶段 时间 做了什么 部署 Descheduler 2026-06-18 ArgoCD 安装 LowNodeUtilization，CronJob 每 15 分钟 发现异常 2026-06-23 Node Exporter Full（1860）见 k8s-50 CPU ~80%，Descheduler 日志 evictedPods=0 加监控 2026-06-23 新建 Grafana 看板 K8s Node Workloads（k8s-node-workloads） 根因 2026-06-23 Grafana 看实际用量，Descheduler 看 requests；大量 Pod 未声明 requests 治理 2026-06-23 补 requests、放宽 Nexus affinity、Kong/Tekton 进 Git、Descheduler 开 nodeFit 见效 2026-06-23 Nexus Pod 落到 k8s-71，Longhorn 卷 attach 成功，k8s-50 压力缓解 1. 发现问题 1.1 现象 在 Grafana Node Exporter Full（社区看板 1860）上选 k8s-50（192.168.50.50:9100）： ...

是什么 PVC 的 accessModes 描述的是这块卷在集群里能被怎样挂载，不是 Linux 文件权限里的 rwx。 Kubernetes 常见三种： 模式 全称 含义（简化） RWO ReadWriteOnce 同一时刻，最多一个节点以读写方式挂载 ROX ReadOnlyMany 多个节点可同时只读挂载 RWX ReadWriteMany 多个节点可同时读写挂载（需 NFS、CephFS、Longhorn RWX 等） 日常自建集群里，Longhorn、本地盘、云厂商块存储（EBS 等）给 Pod 用的，几乎都是 RWO。 RWO 不等于 Pod 不能换节点 很多人会把 RWO 理解成「Pod 永远绑死在一个节点上」。更准确的说法是： 同一时刻只能有一个节点挂载读写； Pod 迁到另一节点时，流程是：旧 Pod 退出 → 卷 detach → 新节点 attach → 新 Pod 启动。 因此 RWO 不阻止 Pod 漂移，但不允许两个 Pod 同时挂同一块盘。 和 Longhorn 副本数的关系 Longhorn 的 numberOfReplicas: 2 表示数据在多个节点各存一份（容错、迁移时 attach 更快），与 RWX 无关： ...