Kubernetes PV/PVC/StroageClass的持久化存储是怎样的

共计 2919 个字符，预计需要花费 8 分钟才能阅读完成。

Kubernetes PV/PVC/StroageClass 的持久化存储是怎样的，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

PersistentVolume（简称 PV）和 PersistentVolumeClaim（简称 PVC）

PersistentVolume（持久卷，简称 PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一 样，PV 也是集群中的一种资源。它也像 Volume 一样，是一种 volume 插件，但是它的生命周期却是和使用它的 Pod 相互独立的。PV 这个 API 对 象，捕获了诸如 NFS、ISCSI、或其他云存储系统的实现细节。
PersistentVolumeClaim（持久卷声明，简称 PVC）是用户的一种存储请求。它和 Pod 类似，Pod 消耗 Node 资源，而 PVC 消耗 PV 资源。Pod 能够请求特定的资源（如 CPU 和内存）。PVC 能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。
PVC 允许用户消耗抽象的存储资源，用户也经常需要各种属性（如性能）的 PV。集群管理员需要提供各种各样、不同大小、不同访问模式的 PV，而不用向用户暴露这些 volume 如何实现的细节。因为这种需求，就催生出一种 StorageClass 资源。
StorageClass 提供了一种方式，使得管理员能够描述他提供的存储的等级。集群管理员可以将不同的等级映射到不同的服务等级、不同的后端策略。

供给
PV 是集群中的资源，PVC 是对这些资源的请求，同时也是这些资源的“提取证”。PV 和 PVC 的交互遵循以下生命周期：

有两种 PV 提供的方式：静态和动态。

静态
集群管理员创建多个 PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于 Kubernetes API 中，并可用于存储使用。
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv01
  namespace: sit
spec:
  capacity:
  storage: 100Gi
  accessModes:
  – ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
  server: 10.42.0.55
  path: /opt/public
动态
当管理员创建的静态 PV 都不匹配用户的 PVC 时，集群可能会尝试专门地供给 volume 给 PVC。这种供给基于 StorageClass：PVC 必须请求这样一个等级，而管理员必须已经创建和配置过这样一个等级，以备发生这种动态供给的情况。请求等级配置为“”的 PVC，有效地禁用了它自身的动态供给功能。
Kubernetes 1.4 中加入了一个 新的 API 对象 StorageClass，可以定义多个 StorageClass 对象，并可以分别指定存储插件、设置参数，用于提供不同的存储卷。这样的设计让集群管理员能够在同一个集群内，定义和提供不同类型的、不同参数的卷（相同或者不同的存储系统）。这样的设计还确保了最终用户在无需了解太多的情况下，有能力选择不同的存储选项。
这种场景比较常见的是使用在高级的私有云分布式存储或者公有云存储情况下，大多数是集成第三方的
举例：创建一个 slow，另外一个 fast 的盘在谷歌云上
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

绑定
用户创建一个 PVC（或者之前就已经就为动态供给创建了），指定要求存储的大小和访问模式。master 中有一个控制回路用于监控新的 PVC，查找匹配的 PV（如果有），并把 PVC 和 PV 绑定在一起。如果一个 PV 曾经动态供给到了一个新的 PVC，那么这个回路会一直绑定这个 PV 和 PVC。另外，用户总是至少能得到它们所要求的存储，但是 volume 可能超过它们的请求。一旦绑定了，PVC 绑定就是专属的，无论它们的绑定模式是什么。
如果没找到匹配的 PV，那么 PVC 会无限期得处于 unbound 未绑定状态，一旦 PV 可用了，PVC 就会又变成绑定状态。比如，如果一个供给了很多 50G 的 PV 集群，不会匹配要求 100G 的 PVC。直到 100G 的 PV 添加到该集群时，PVC 才会被绑定。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-test01
  namespace:
spec:
  accessModes:
  – ReadWriteOnce
  resources:
  requests:
  storage: 100Gi
使用
Pod 使用 PVC 就像使用 volume 一样。集群检查 PVC，查找绑定的 PV，并映射 PV 给 Pod。对于支持多种访问模式的 PV，用户可以指定想用的模式。
一旦用户拥有了一个 PVC，并且 PVC 被绑定，那么只要用户还需要，PV 就一直属于这个用户。用户调度 Pod，通过在 Pod 的 volume 块中包含 PVC 来访问 PV。
kind: Pod
apiVersion: v1
metadata:
  name: task-pv-pod
spec:
  volumes:
  – name: task-pv-storage
  persistentVolumeClaim:
  claimName: pvc-test01
  containers:
  – name: task-pv-container
  image: nginx
  ports:
  – containerPort: 80
  name: http-server
  volumeMounts:
  – mountPath: /usr/share/nginx/html
  name: task-pv-storage

释放
当用户使用 PV 完毕后，他们可以通过 API 来删除 PVC 对象。当 PVC 被删除后，对应的 PV 就被认为是已经是“released”了，但还不能再给另外一个 PVC 使用。前一个 PVC 的属于还存在于该 PV 中，必须根据策略来处理掉。

回收
PV 的回收策略告诉集群，在 PV 被释放之后集群应该如何处理该 PV。当前，PV 可以被 Retained（保留）、Recycled（再利用）或者 Deleted（删除）。保留允许手动地再次声明资源。对于支持删除操作的 PV 卷，删除操作会从 Kubernetes 中移 除 PV 对象，还有对应的外部存储（如 AWS EBS，GCE PD，Azure Disk，或者 Cinder volume）。动态供给的卷总是会被删除。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。