pod宿主机挂载pv存储过程

1处的控制循环Control Loop应该是：VolumeManagerReconciler

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Local Persistent Volume: 利用pv&pvc这种松耦合机制来实现直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器 Volume

设计lpv过程需要考虑的两个问题：

1. 如何把本地磁盘抽象成 PV（一个 PV 一块盘）：pv对应的目录所挂载的磁盘不应该是宿主机根目录使用的硬盘，因为一旦pv不使用独立的磁盘，将会变成完全不可控，比如磁盘很容易被其他进程应用写满，甚至造成整个宿主机宕机。而且同一个磁盘的不同的目录之间也缺乏最基础的 I/O 隔离机制.

2.  Pod 能被正确地调度到lpv 对应节点上（延迟绑定）：常规的pv记录的是与节点无关的远程共享存储，而lpv则与某些节点关联在一起.

考虑这样的场景：

假设我的集群中有3个节点，分别是node1、node2、node3，其中node1和node2具有diskType=ssd的标签，且node1和node2已经使用独立的磁盘挂载到/mnt/disks/volA目录，node3使用独立的磁盘挂载到/mnt/disks/volB目录

假设我的集群已经创建好了两个pv，分别是pvA和pvB

pvA.yaml如下。字段nodeAffinity表明想要使用这个pv的pod只能被调度到带diskType=ssd标签的节点上，也就是node1、node2

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pvA
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  local: #local字段表明这是一个Local Persistent Volume的pv
    path: /mnt/disks/volA
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: diskType
          operator: In
          values:
          - ssd

pvB.yaml如下。字段nodeAffinity表明想要使用这个pv的pod只能被调度到带node3

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pvB
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  local: local字段表明这是一个Local Persistent Volume的pv
    path: /mnt/disks/volB
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node3

pvc.yaml文件如下

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: local-storage

创建一个pod声明使用example-local-claim这个pvc，如果按照常规pv的处理模式来说，当pvc一旦创建，就会被volumeController的PersistentVolumeController控制循环检测到，并尝试寻找合适的pv进行绑定。Kubernetes将先调度 Pod 到某个节点上，然后，根据pv上定义的信息，通过“两阶段处理”来“持久化”这台机器上的 Volume 目录，进而完成 Volume 目录与容器的绑定挂载（将一个目录挂载到挂载点目录，而不是将一个设备挂载到挂载点目录）。在lpv上就不能通过这种方式处理了，因为如果pvc一经创建就选择一个pv绑定，在上面的例子中，如果pvc和pvB绑定，那么使用这个pvc的pod也就被限制在node3节点，如果pod这边又通过NodeAffinity节点亲和性或nodeSelector强制pod调度到节点node2，此时就会出现冲突，这个pod也就会一直pending了。

k8s的lpv是通过pvc和pv的延迟绑定来解决这个冲突的：创建一个storageClass，配置volumeBindingMode为WaitForFirstConsumer，且在pvA和pvB中声明使用这个storageClass

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

WaitForFirstConsumer表示第一个使用这个pvc的pod在调度过程中才决策合适的pv进行绑定。这样一来，k8s就可以综合考虑pod对Node的要求和pv对Node的要求，最终pvc选择和pvA进行绑定。

参考资料：

当前k8s支持的存储插件：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes