AKS中强制删除PersistentVolume后Pod仍可读写卷挂载是否正常？

现象是否正常？ #

这个现象是正常的，但属于Kubernetes存储层与容器运行时层解耦导致的状态不一致场景

背后的底层机制 #

• API层与节点本地挂载的解耦：
  强制删除PV（删除后移除终结器）只是在Kubernetes API Server里清除了PV的记录，但节点上的存储卷挂载关系不会被主动解除。Pod的容器进程已经通过节点本地的文件系统路径（比如/var/lib/kubelet/pods/[PodID]/volumes/[VolumeType]/[VolumeName]）绑定到了实际存储设备，只要Pod不重启、节点挂载点没被手动清理，容器就能继续访问本地挂载的卷。
• PVC报错的逻辑：
  PVC的报错是Kubernetes控制平面的判断——因为它找不到绑定的PV对象了，所以标记PVC为异常状态，但这个状态不会直接触发节点上的挂载卸载操作，控制平面不会主动中断Pod正在进行的文件系统访问。
• AKS默认存储类的特性：
  AKS默认存储类创建的PV，对应底层Azure存储资源（比如Azure Disk或Azure Files），强制删除PV后，底层存储资源不会立刻被销毁（除非设置了Delete回收策略且走正常删除流程），所以节点上的挂载设备依然有效，Pod的读写操作实际还是在底层存储资源上进行。

风险提示 #

• 虽然Pod能继续读写，但此时PVC已处于异常状态，无法被其他Pod绑定，也无法通过Kubernetes存储管理功能做扩容、备份等操作。
• 如果Pod重启或节点故障，挂载关系会丢失，Pod将无法重新挂载该卷（因为PV已不存在），此时才会真正无法访问数据。
• 强制删除PV属于非常规操作，会破坏Kubernetes存储的状态一致性，生产环境绝对不能这么做。

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