从 PVC 绑定到容器启动逐层排查
一份私有故障笔记依次记录了 PVC 未绑定、卷创建辅助 Pod 无法拉取镜像、应用镜像架构不匹配。它提示排查时在每个状态变化后重新定位当前阻塞点，而不是把最初的 PVC 问题当成最终原因。
- Pod 与 PVC 均处于
Pending时，先读事件，再核对 PVC 请求的访问模式与实际 StorageClass、provisioner 能力。ReadWriteOnce与ReadWriteMany的节点挂载语义不同；不能仅凭 provisioner 名称断言它只支持一种模式。 - 若卷供应器使用辅助 Pod 创建目录，继续检查该 Pod 的事件、镜像可达性和供应器日志。PVC 变为
Bound后，重新核对业务 Pod 状态。 - 容器已被调度却出现
exec format error时，核对节点 CPU 架构与镜像 manifest 的目标架构；不要从镜像标签的命名推断架构。
**核验边界：**访问模式语义已对照 Kubernetes PersistentVolume 文档；辅助 Pod 机制已对照 local-path-provisioner 文档。原笔记的环境、事件顺序和最终修复未独立复现，不保留其命名空间、镜像标签或变更命令。