kubernetes-PV与PVC 的关系与绑定的条件

PV ：声明这个资源是一个持久卷 (PV)。

PVC：声明这个资源是一个持久卷声明 (PVC)。

创建yaml配置

apiVersion: v1
kind: PersistentVolume  #PV是集群中的一块存储，可以由PVC请求并使用。-虚拟存储 - 实体机的存储、不是容器中的存储
metadata:
  name: postgresql-pv  
  namespace: ops-system
spec:
  storageClassName: nfs   #指定了与此PV关联的存储类（StorageClass）是nfs
  accessModes:            #这定义了PV可以被如何访问
    - ReadWriteMany       #表示该PV可以被多个节点以读写模式同时访问。
  capacity:               #这定义了PV的存储容量。
    storage: 200Mi        #指定了该PV的存储容量为200兆字节。- 可通过此属性来被PVC绑定
  nfs:                                #定义了NFS（网络文件系统）的具体配置
    path: /vol/nfsshare/kong/data     #这是NFS服务器上的共享目录的路径，Kubernetes节点将挂载这个目录来访问存储。
    server: 192.168.19.3              #这是NFS服务器的IP地址
---
#PVC是用户对存储资源的请求，当PVC被创建后，Kubernetes会尝试找到一个与之匹配的PersistentVolume（PV）来绑定
#如果没有创建PV PVC也会通过StorageClass 动态的创建PV
#当 PVC 和 PV 成功绑定后，PVC 可以被应用（Pod）使用。应用程序通过 PVC 挂载存储卷，获取持久存储空间
apiVersion: v1    #指定了Kubernetes API的版本，用于该资源定义
kind: PersistentVolumeClaim   #PVC是用户对存储资源的请求，当创建PVC后，Kubernetes将尝试找到一个匹配的PV来满足这个请求 - -虚拟存储 - 实体机的存储、不是容器中的存储
metadata:
  name: postgresql-pvc    
  namespace: ops-system
spec:
  storageClassName: nfs   #这指定了PVC应该使用哪个StorageClass。在这里，它指定了nfs，意味着这个PVC希望与一个基于NFS的PV进行绑定。
  accessModes:            #这定义了PVC可以如何访问存储资源。
    - ReadWriteMany       #表示这个PVC希望PV支持多个节点以读写模式同时访问。
  resources:              #这定义了PVC对存储资源的需求。
    requests:             #指定了PVC请求的存储资源的大小
      storage: 200Mi      #此属性会去找相同大小的 200Mi PV绑定
  
#一旦这个PVC被创建，Kubernetes将尝试找到一个与之匹配的PV（在这个例子中，可能是一个名为postgresql-pv的PV，其规格storage：200Mi 与这个PVC相匹配）并进行绑定。
#如果找到了匹配的PV，那么这个PV的存储资源就可以被使用这个PVC的Pod所使用。如果没有找到匹配的PV，PVC将保持未绑定状态，直到有匹配的PV可用为止
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: iam-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 100Mi
  nfs:
    path: /vol/nfsshare/iam/assets
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iam-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Mi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: lap-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 1Gi
  nfs:
    path: /vol/nfsshare/lap/uploads
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lap-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: ops-manage-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 50Gi
  nfs:
    path: /vol/nfsshare/ops-manage/key_cfg_compare
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ops-manage-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: ops-ledger-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 2Gi
  nfs:
    path: /vol/nfsshare/ops-ledger/images
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ops-ledger-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

聊聊 PVC 是如何绑定 PV的

# PVC 是通过以下几个属性与 PV 绑定的：
# 1、storageClassName
- PVC 和 PV 的 storageClassName 必须匹配。这决定了 PVC 会优先匹配到哪些 PV。这里，PVC 和 PV 都使用了 nfs 作为 storageClassName。
- spec:
  storageClassName: nfs
  
# 2、accessModes
- PVC 的 accessModes 必须是 PV accessModes 的一个子集。换句话说，PVC 请求的访问模式必须被 PV 支持
- spec:
  accessModes:
    - ReadWriteMany
    
# 3、requests 和 capacity
- PVC 请求的 storage 容量必须小于或等于 PV 提供的 capacity。这里，PVC 请求了 100 MiB，恰好等于 PV 提供的 100 MiB
- spec:
  resources:
    requests:
      storage: 100Mi
      
# 总结机制：
#PVC 和 PV 的绑定是基于对存储资源需求和供应的属性匹配。以下是主要的匹配属性：
容量匹配: PV 的 capacity 必须至少等于 PVC 请求的存储量。
访问模式: PV 和 PVC 必须有兼容的 accessModes。
StorageClass: PVC 和 PV 必须有匹配的 storageClassName。
标签选择器: PVC 可以使用标签选择器来精确匹配特定的 PV。
绑定状态: 只有状态为 Available 的 PV 才会被考虑用于绑定。
动态供应: 当 PVC 没有找到匹配的 PV 时，如果指定了 storageClassName，Kubernetes 可以动态创建一个符合需求的 PV。

PV 和 PVC 的绑定机制

##当 PVC 被创建时，Kubernetes 控制器会自动查找匹配的 PV。它会按照以下规则进行匹配：
- 查找具有相同 storageClassName 的 PV。
- 检查 accessModes 是否兼容。
- 确保 capacity 能够满足 PVC 的 requests。
- 如果找到合适的 PV，Kubernetes 会自动将这个 PV 和 PVC 绑定起来。

#绑定信息的体现:
- 当 PV 和 PVC 成功绑定后，PV 的 status.phase 会更新为 Bound，PVC 的 status.phase 也会更新为 Bound。

总结

PersistentVolume (PV) 定义了一个持久化存储资源，可以是 NFS、云存储或本地存储等。
PersistentVolumeClaim (PVC) 是对存储资源的请求，PVC 通过 storageClassName、accessModes 和 resources.requests 等属性与 PV 匹配和绑定。
PVC 创建后，Kubernetes 控制器会自动查找和绑定合适的 PV，使得应用程序可以通过 PVC 访问底层的持久存储资源。
这种机制使得存储的配置和使用变得灵活，并且能够在不同的环境中保持一致，极大地提高了 Kubernetes 集群中持久化存储的管理效率。