K8s 1.25 集群用 local 类型的 PV 给日志服务做存储,一台 worker 下线维护后,它的 Pod 在新节点上重建,状态一直 Pending,事件里写 node affinity 不满足。
一开始怀疑是「原来那台节点还是 Ready 状态,调度器认为卷仍可用」,查了一圈,方向不对。
真正麻烦的地方在于,几个原因的现象几乎一样。local 卷的 PV 上带着 nodeAffinity,Pod 被调度到别的节点就找不到卷。少数情况下是StatefulSet 的 Pod 和 PV 是通过名字绑定的,卷没释放新 Pod 抢不到。
少数情况下是StorageClass 的 volumeBindingMode 设成了 Immediate,卷在创建时就被钉死。
上来先看 Pod 事件里到底卡在哪一步
kubectl describe pod log-0 | tail -20
再往下确认 PV 当前绑定的节点和状态
kubectl get pv -o wide | grep local
然后把旧节点标记为不可调度再驱逐
kubectl cordon node-05 && kubectl drain node-05 --ignore-daemonsets --delete-emptydir-data
等前面都确认过,再重建 Pod 并观察是否被调度过去
kubectl delete pod log-0 && kubectl get pod -o wide -w
别只看报错消失,验证要多做一步。kubectl get pod 里 log-0 变成 Running 并且所在节点与 PV 的 nodeAffinity 一致,日志正常写入本地盘目录。
local 卷的可用性取决于单台机器,节点挂了数据就没了;这类存储只适合可重建的缓存和日志,真要高可用还是得上网络存储。这类问题最好一次改到位,反复小改反而容易把原因搅混。
