Kubernetes所有PVC已绑定，但含initContainer的Pod仍提示未绑定PVC

• 核对PV与PVC的访问模式一致性
  即便PV和PVC显示为Bound状态，也要确认二者的accessModes完全匹配。比如PV配置的是ReadWriteOnce，PVC的请求模式也必须一致——尤其是initContainer和主容器同时挂载同一个PVC时，要保证访问模式支持多容器挂载（ReadWriteOnce允许同一节点的多个容器挂载，ReadOnlyMany无节点限制）。可以用以下命令对比：

  kubectl get pv <你的PV名称> -o yaml | grep accessModes
  kubectl get pvc <你的PVC名称> -o yaml | grep accessModes
  

• 检查initContainer的挂载配置细节
  重点排查挂载路径和权限问题：

  • 确认initContainer要写入的路径，是否被主容器的挂载路径覆盖，导致复制操作失效；
  • 查看initContainer的securityContext配置，比如runAsUser是否和存储目录的属主匹配，是否需要开启privileged模式（针对HostPath这类特殊存储）。

• 拉取initContainer的具体日志
  别只依赖kubectl describe pod的简略提示，直接获取initContainer的日志能定位真实错误：

  kubectl logs <异常Pod名称> -c <initContainer名称>
  

  日志会直接显示是复制命令报错、存储目录不存在，还是权限不足这类具体问题。

• 排查Kubernetes老版本的已知Bug
  Kubernetes 1.14.6属于较旧版本，存在initContainer与PVC挂载相关的已知问题，可能出现PVC已绑定但kubelet误判状态的情况。可以尝试：

  • 删除异常Pod，让控制器重新创建：kubectl delete pod <异常Pod名称>
  • 查看kubelet日志，获取挂载相关的具体错误（systemd环境下执行）：

    journalctl -u kubelet -f
    

• 验证Helm模板渲染后的Pod配置
  用Helm渲染出最终的Pod YAML，检查是否存在模板错误：

  helm template <你的Release名称> <Chart路径>
  

  重点核对PVC名称是否正确、volumeMounts的name是否与Pod的volumes定义一致，有没有拼写错误。

内容的提问来源于stack exchange，提问作者Taylor Lopez