PVC与PV的创建

如下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      #找到对应的PV storage 为200Mi的进行绑定
  
#一旦这个PVC被创建，Kubernetes将尝试找到一个与之匹配的PV（在这个例子中，可能是一个名为postgresql-pv的PV，其规格与这个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 与name无关

在 Kubernetes 中，PersistentVolumeClaim (PVC) 和 PersistentVolume (PV) 的绑定是基于一组特定的属性进行匹配和选择的。
以下是 PVC 和 PV 绑定时所考虑的主要属性：

#PVC 和 PV 绑定的关键属性
# 1. 存储容量
容量匹配: PV 的 spec.capacity.storage 必须至少等于 PVC 请求的 spec.resources.requests.storage。
单位兼容性: Kubernetes 支持多种单位（如 Gi、Mi 等），要求 PV 的容量单位与 PVC 请求的单位兼容。

# 2. 访问模式
访问模式类型: PV 和 PVC 必须具有兼容的访问模式，如 ReadWriteOnce (RWO)、ReadOnlyMany (ROX) 和 ReadWriteMany (RWX)。
精确匹配: PVC 的 spec.accessModes 必须与 PV 的 spec.accessModes 中的至少一种匹配。

# 3. 存储类别 (StorageClass)
StorageClass 匹配: PVC 的 spec.storageClassName 必须与 PV 的 spec.storageClassName 相匹配。
默认行为: 如果 PVC 和 PV 都没有指定 storageClassName 或都设置为 ""，则它们可以互相匹配。
动态供应: 如果没有现成的 PV 与 PVC 匹配，且 PVC 指定了 storageClassName，Kubernetes 会尝试根据 StorageClass 动态创建一个 PV。

# 4. 标签和选择器
PV 标签: PV 可以有多个标签（键值对），用于描述 PV 的属性或特性。
PVC 选择器: PVC 可以使用 spec.selector 来指定必须匹配的标签。
选择器可以是一个标签的集合，PVC 只有找到匹配这些标签的 PV 才会绑定。

yaml
spec:
  selector:
    matchLabels:
      key: value

# 5. 区域和可用区
区域性匹配: 在多区域部署中，PVC 和 PV 需要在同一区域或可用区，特别是对于一些需要区域性存储的云服务。
拓扑约束: 一些存储提供者可能要求 PV 和 PVC 在同一个拓扑（如同一数据中心或可用区），这在云环境中尤为重要。

# 6. 回收策略
回收策略要求: PVC 只能绑定到回收策略与其预期相匹配的 PV。常见的回收策略有 Recycle、Retain 和 Delete。
动态绑定的策略: 动态创建的 PV 通常具有 Delete 策略，意味着当 PVC 被删除时，PV 也会自动删除。

# 7. 绑定状态
未绑定状态: 只有状态为 Available 的 PV 才能与 PVC 绑定。
绑定后状态: 一旦绑定，PVC 和 PV 的状态会分别更新为 Bound，表示已成功建立连接。

#8. 持久卷索赔元数据
PVC 元数据: 包括 PVC 的名称和命名空间，它们必须唯一且符合 Kubernetes 的命名规则。
PV 元数据: PV 包含类似的元数据，以及它与 PVC 的绑定关系。

# 9. 其他特性
PV 类型: PV 的类型（如 NFS、Ceph、AWS EBS 等）需要与 PVC 的使用要求相匹配。
性能要求: 有些存储类型可能对性能有特定要求，比如 IOPS、吞吐量等，PVC 可以通过注释等方式指定。

PVC 和 PV 的绑定是 Kubernetes 中存储资源管理的核心机制，通过对存储容量、访问模式、StorageClass、标签选择器等属性的匹配
确保 PVC 和 PV 能够准确地连接和使用。这种机制不仅提供了灵活和高效的存储管理，还简化了应用程序对存储资源的使用、使得存储管理变得更加自动化和透明化。

案例

在这个例子中，my-pvc 将与标签为 type: fast-storage 且满足容量和访问模式要求的 my-pv 进行绑定。

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
  selector:
    matchLabels:
      type: fast-storage

PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
  labels:
    type: fast-storage
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  hostPath:
    path: /mnt/data