kuberbetes-PVC与PV的创建 和绑定
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