K8s集群keycloak-postgresql-0 Pod挂载PVC超时实例未找到问题求助

• 第一步：校验底层存储资源有效性
  你在Rancher中看到的PV为Bound状态仅代表K8s etcd中存储的资源状态正常，不代表底层实际存储实例可用。先执行kubectl get pv pvc-94b61d69-b529-4b0b-bef3-4b85880a0e71 -o yaml查看spec字段下的存储源配置：如果是云厂商块存储，确认对应云控制台中该ID的块存储是否存在、权限配置是否正常；如果是本地存储/分布式存储，确认存储路径/存储池是否正常可访问。
• 第二步：排查节点挂载上限
  执行kubectl get pod keycloak-postgresql-0 -o wide确认Pod调度到的目标节点，再执行kubectl describe node <目标节点名>，查看Capacity块下attachable-volumes-<存储类型>的阈值，统计该节点当前已挂载的PV数量，若达到阈值则会触发挂载超时报错，可通过调整Pod调度策略分散挂载，或联系存储提供商调整节点挂载上限。
• 第三步：清理残留挂载资源
  K8s异常重启/卷卸载失败时会残留VolumeAttachment对象，导致新挂载请求冲突，执行以下命令排查并清理：

# 查看对应PVC的残留挂载记录
kubectl get volumeattachment | grep pvc-94b61d69-b529-4b0b-bef3-4b85880a0e71
# 若有返回结果则执行删除
kubectl delete volumeattachment <返回的资源名称>

清理完成后删除卡住的Pod，等待StatefulSet自动重建即可。

• 第四步：校验StatefulSet存储配置
  检查keycloak-postgresql对应的StatefulSet配置中volumeClaimTemplates字段的storageClassName、accessModes等参数，是否与现有PVC的配置完全一致，重新部署时如果配置被修改会导致PVC和实际存储匹配异常。

补充说明：你遇到的Pod无日志属于正常现象，此时Pod还处于卷挂载的初始化阶段，未到启动业务进程的步骤，无需关注业务日志，优先通过kubectl describe pod查看Events字段的完整报错信息即可。

内容的提问来源于stack exchange，提问作者Jack Linhart