PV
持久化存储数据卷。这个API对象主要定义的是一个持久化存储在宿主机上的目录
PVC
Pod所希望使用的持久化存储的属性，如，Volume存储的大小，可读写权限等等
PV与PVC绑定的条件
- PV和PVC的spec字段，比如：PV的存储大小，就必须满足PVC的要求
- PV和PVC的storageClassName字段必须一样
Volume Controller
PersistentVolumeController
- 不断查看当前每一个PVC，是不是已经处于Bound状态，如果不是，那它就会遍历所有的、可用的PV，并尝试将其与这个“单身”的PVC进行绑定
- PV和PVC绑定，就是将这个PV对象的名字，填在PVC对象的spec.volumeName字段上
准备持久化宿主机目录的过程
- 当一个Pod调度到一个节点上后，kubelet负责为这个pod创建它的Volume目录。
- 如果是远程块存储
- kubelet需要调用Google Cloud的API，将提供的Persistent Disk挂载到Pod所在的宿主机上（Attach）
- 格式化磁盘设备，将它挂载到宿主机指定的挂载点（Mount）
- 通过CRI接口Mount
Kubernetes如何定义和区分这两个阶段
通过参数控制，1. Attach通过nodeName来控制 2.Mount通过dir参数控制
PV、PVC这样的用法，是不是有“过度设计”的嫌疑
解耦，扩展性
Local Persistent Volume
如何把本地磁盘抽象成PV
绝不应该把一个宿主机上的目录当作PV使用
- 本地目录的存储行为完全不可控，所在的磁盘随时都可能被应用写满，甚至造成整个宿主机宕机
- 不同的本地目录之间也缺乏哪怕最基础的I/O隔离机制
一个PV一块盘
调度器如何保证 Pod 始终能被正确地调度到它所请求的 Local Persistent Volume 所在的节点上呢？
调度器就必须能够知道所有节点与 Local Persistent Volume 对应的磁盘的关联关系，称为“在调度的时候考虑Volume分布”。VolumeBindingChecker的过滤条件专门负责这个事情
延迟绑定（volumeBindingMode=WaitForFirstConsumer）
- 一般情况下，声明PV和PVC及StrorageClass会被Kubernetes直接进行绑定
- 当PV和PVC直接绑定之后，而Pod设置的调度规则有可能不满足PV所在节点，则调度失败
- 但如果PV和PVC的绑定是根据Pod的调度规则之后在绑定，就会减少调度失败的可能