Kubernetes存储中Persistent Volumes有什么用

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

这篇文章给大家分享的是有关 Kubernetes 存储中 Persistent Volumes 有什么用的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。

简介

管理存储和管理计算有着明显的不同。PersistentVolume 子系统给用户和管理员提供了一套 API，从而抽象出存储是如何提供和消耗的细节。在这里，我们介绍两种新的 API 资源：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 提供了一种方式，使得管理员能够描述他提供的存储的等级。集群管理员可以将不同的等级映射到不同的服务等级、不同的后端策略。

volume 和 claim 的生命周期

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

供给

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

静态

集群管理员创建多个 PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于 Kubernetes API 中，并可用于存储使用。

动态

当管理员创建的静态 PV 都不匹配用户的 PVC 时，集群可能会尝试专门地供给 volume 给 PVC。这种供给基于 StorageClass：PVC 必须请求这样一个等级，而管理员必须已经创建和配置过这样一个等级，以备发生这种动态供给的情况。请求等级配置为“”的 PVC，有效地禁用了它自身的动态供给功能。

绑定

用户创建一个 PVC（或者之前就已经就为动态供给创建了），指定要求存储的大小和访问模式。master 中有一个控制回路用于监控新的 PVC，查找匹配的 PV（如果有），并把 PVC 和 PV 绑定在一起。如果一个 PV 曾经动态供给到了一个新的 PVC，那么这个回路会一直绑定这个 PV 和 PVC。另外，用户总是至少能得到它们所要求的存储，但是 volume 可能超过它们的请求。一旦绑定了，PVC 绑定就是专属的，无论它们的绑定模式是什么。
如果没找到匹配的 PV，那么 PVC 会无限期得处于 unbound 未绑定状态，一旦 PV 可用了，PVC 就会又变成绑定状态。比如，如果一个供给了很多 50G 的 PV 集群，不会匹配要求 100G 的 PVC。直到 100G 的 PV 添加到该集群时，PVC 才会被绑定。

使用

Pod 使用 PVC 就像使用 volume 一样。集群检查 PVC，查找绑定的 PV，并映射 PV 给 Pod。对于支持多种访问模式的 PV，用户可以指定想用的模式。
一旦用户拥有了一个 PVC，并且 PVC 被绑定，那么只要用户还需要，PV 就一直属于这个用户。用户调度 Pod，通过在 Pod 的 volume 块中包含 PVC 来访问 PV。

释放

当用户使用 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）。动态供给的卷总是会被删除。

Recycled（再利用）

如果 PV 卷支持再利用，再利用会在 PV 卷上执行一个基础的擦除操作（rm -rf /thevolume/*），使得它可以再次被其他 PVC 声明利用。
管理员可以通过 Kubernetes controller manager 的命令行工具（点击查看），来配置自定义的再利用 Pod 模板。自定义的再利用 Pod 模板必须包含 PV 卷的详细内容，如下示例：

apiVersion: v1
kind: Pod
metadata:
 name: pv-recycler-
 namespace: default
spec:
 restartPolicy: Never
 volumes:
 - name: vol
 hostPath:
 path: /any/path/it/will/be/replaced
 containers:
 - name: pv-recycler
 image:  gcr.io/google_containers/busybox 
 command: [/bin/sh ,  -c ,  test -e /scrub   rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*   test -z \ $(ls -A /scrub)\  || exit 1 ]
 volumeMounts:
 - name: vol
 mountPath: /scrub

如上，在 volumes 部分的指定路径，应该被替换为 PV 卷需要再利用的路径。

PV 类型

PV 类型使用插件的形式来实现。Kubernetes 现在支持以下插件：
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (Fibre Channel)
Flocker
NFS
iSCSI
RBD (Ceph Block Device)
CephFS
Cinder (OpenStack block storage)
Glusterfs
VsphereVolume
Quobyte Volumes
HostPath (仅测试过单节点的情况——不支持任何形式的本地存储，多节点集群中不能工作)
VMware Photon
Portworx Volumes
ScaleIO Volumes

PV 介绍

每个 PV 都包含一个 spec 和状态，即说明书和 PV 卷的状态。

 apiVersion: v1
 kind: PersistentVolume
 metadata:
 name: pv0003
 spec:
 capacity:
 storage: 5Gi
 accessModes:
 - ReadWriteOnce
 persistentVolumeReclaimPolicy: Recycle
 storageClassName: slow
 nfs:
 path: /tmp
 server: 172.17.0.2

Capacity（容量）

一般来说，PV 会指定存储的容量，使用 PV 的 capacity 属性来设置。查看 Kubernetes 的 Resource Model 来了解 capacity。
当前，存储大小是唯一能被设置或请求的资源。未来可能包含 IOPS，吞吐率等属性。

访问模式

PV 可以使用存储资源提供商支持的任何方法来映射到 host 中。如下的表格中所示，提供商有着不同的功能，每个 PV 的访问模式被设置为卷支持的指定模式。比如，NFS 可以支持多个读 / 写的客户端，但可以在服务器上指定一个只读的 NFS PV。每个 PV 有它自己的访问模式。
访问模式包括：
▷ ReadWriteOnce —— 该 volume 只能被单个节点以读写的方式映射
▷ ReadOnlyMany —— 该 volume 可以被多个节点以只读方式映射
▷ ReadWriteMany —— 该 volume 只能被多个节点以读写的方式映射
在 CLI 中，访问模式可以简写为：
▷ RWO – ReadWriteOnce
▷ ROX – ReadOnlyMany
▷ RWX – ReadWriteMany
注意：即使 volume 支持很多种访问模式，但它同时只能使用一种方式来映射。比如，GCEPersistentDisk 可以被单个节点映射为 ReadWriteOnce，或者多个节点映射为 ReadOnlyMany，但不能同时使用这两种方式来映射。

Volume PluginReadWriteOnceReadOnlyManyReadWriteManyAWSElasticBlockStore✓–AzureFile✓✓✓AzureDisk✓–CephFS✓✓✓Cinder✓–FC✓✓-FlexVolume✓✓-Flocker✓–GCEPersistentDisk✓✓-Glusterfs✓✓✓HostPath✓–iSCSI✓✓-PhotonPersistentDisk✓–Quobyte✓✓✓NFS✓✓✓RBD✓✓-VsphereVolume✓–PortworxVolume✓-✓ScaleIO✓✓-Class

一个 PV 可以有一种 class，通过设置 storageClassName 属性来选择指定的 StorageClass。有指定 class 的 PV 只能绑定给请求该 class 的 PVC。没有设置 storageClassName 属性的 PV 只能绑定给未请求 class 的 PVC。
过去，使用 volume.beta.kubernetes.io/storage-class 注解，而不是 storageClassName 属性。该注解现在依然可以工作，但在 Kubernetes 的未来版本中已经被完全弃用了。

回收策略

当前的回收策略有：
▷ Retain：手动回收
▷ Recycle：需要擦出后才能再使用
▷ Delete：相关联的存储资产，如 AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder 卷都会被删除
当前，只有 NFS 和 HostPath 支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder 卷支持删除操作。

阶段

一个 volume 卷处于以下几个阶段之一：
▷ Available：空闲的资源，未绑定给 PVC
▷ Bound：绑定给了某个 PVC
▷ Released：PVC 已经删除了，但是 PV 还没有被集群回收
▷ Failed：PV 在自动回收中失败了
CLI 可以显示 PV 绑定的 PVC 名称。

映射选项

当 PV 被映射到一个 node 上时，Kubernetes 管理员可以指定额外的映射选项。可以通过使用标注 volume.beta.kubernetes.io/mount-options 来指定 PV 的映射选项。
比如：

apiVersion:  v1 
kind:  PersistentVolume 
metadata:
 name: gce-disk-1
 annotations:
 volume.beta.kubernetes.io/mount-options:  discard 
spec:
 capacity:
 storage:  10Gi 
 accessModes:
 -  ReadWriteOnce 
 gcePersistentDisk:
 fsType:  ext4 
 pdName:  gce-disk-1

映射选项是当映射 PV 到磁盘时，一个可以被递增地添加和使用的字符串。
注意，并非所有的 PV 类型都支持映射选项。在 Kubernetes v1.6 中，以下的 PV 类型支持映射选项。
● GCEPersistentDisk
● AWSElasticBlockStore
● AzureFile
● AzureDisk
● NFS
● iSCSI
● RBD (Ceph Block Device)
● CephFS
● Cinder (OpenStack block storage)
● Glusterfs
● VsphereVolume
● Quobyte Volumes
● VMware Photon

PersistentVolumeClaims（PVC）

每个 PVC 都包含一个 spec 和 status，即该 PVC 的规则说明和状态。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 name: myclaim
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 8Gi
 storageClassName: slow
 selector:
 matchLabels:
 release:  stable 
 matchExpressions:
 - {key: environment, operator: In, values: [dev]}

访问模式

当请求指定访问模式的存储时，PVC 使用的规则和 PV 相同。

资源

PVC，就像 pod 一样，可以请求指定数量的资源。请求资源时，PV 和 PVC 都使用相同的资源样式。

选择器（Selector）

PVC 可以指定标签选择器进行更深度的过滤 PV，只有匹配了选择器标签的 PV 才能绑定给 PVC。选择器包含两个字段：
● matchLabels（匹配标签）– PV 必须有一个包含该值得标签
● matchExpressions（匹配表达式）– 一个请求列表，包含指定的键、值的列表、关联键和值的操作符。合法的操作符包含 In，NotIn，Exists，和 DoesNotExist。
所有来自 matchLabels 和 matchExpressions 的请求，都是逻辑与关系的，它们必须全部满足才能匹配上。

等级（Class）

PVC 可以使用属性 storageClassName 来指定 StorageClass 的名称，从而请求指定的等级。只有满足请求等级的 PV，即那些包含了和 PVC 相同 storageClassName 的 PV，才能与 PVC 绑定。
PVC 并非必须要请求一个等级。设置 storageClassName 为“”的 PVC 总是被理解为请求一个无等级的 PV，因此它只能被绑定到无等级的 PV（未设置对应的标注，或者设置为“”）。未设置 storageClassName 的 PVC 不太相同，DefaultStorageClass 的权限插件打开与否，集群也会区别处理 PVC。
• 如果权限插件被打开，管理员可能会指定一个默认的 StorageClass。所有没有指定 StorageClassName 的 PVC 只能被绑定到默认等级的 PV。要指定默认的 StorageClass，需要在 StorageClass 对象中将标注 storageclass.kubernetes.io/is-default-class 设置为“true”。如果管理员没有指定这个默认值，集群对 PVC 创建请求的回应就和权限插件被关闭时一样。如果指定了多个默认等级，那么权限插件禁止 PVC 创建请求。
• 如果权限插件被关闭，那么久没有默认 StorageClass 的概念。所有没有设置 StorageClassName 的 PVC 都只能绑定到没有等级的 PV。因此，没有设置 StorageClassName 的 PVC 就如同设置 StorageClassName 为“”的 PVC 一样被对待。
根据安装方法的不同，默认的 StorageClass 可能会在安装过程中被插件管理默认的部署在 Kubernetes 集群中。
当 PVC 指定 selector 来请求 StorageClass 时，所有请求都是与操作的。只有满足了指定等级和标签的 PV 才可能绑定给 PVC。当前，一个非空 selector 的 PVC 不能使用 PV 动态供给。
过去，使用 volume.beta.kubernetes.io/storage-class 注解，而不是 storageClassName 属性。该注解现在依然可以工作，但在 Kubernetes 的未来版本中已经被完全弃用了。

使用 PVC

Pod 通过使用 PVC（使用方式和 volume 一样）来访问存储。PVC 必须和使用它的 pod 在同一个命名空间，集群发现 pod 命名空间的 PVC，根据 PVC 得到其后端的 PV，然后 PV 被映射到 host 中，再提供给 pod。

kind: Pod
apiVersion: v1
metadata:
 name: mypod
spec:
 containers:
 - name: myfrontend
 image: dockerfile/nginx
 volumeMounts:
 - mountPath:  /var/www/html 
 name: mypd
 volumes:
 - name: mypd
 persistentVolumeClaim:
 claimName: myclaim

命名空间注意事项

PV 绑定是独有的，因为 PVC 是命名空间对象，映射 PVC 时只能在同一个命名空间中使用多种模式（ROX，RWX）。

StorageClass

每个 StorageClass 都包含字段 provisioner 和 parameters，在所属的 PV 需要动态供给时使用这些字段。
StorageClass 对象的命名是非常重要的，它是用户请求指定等级的方式。当创建 StorageClass 对象时，管理员设置等级的名称和其他参数，但对象不会在创建后马上就被更新。
管理员可以指定一个默认的 StorageClass，用于绑定到那些未请求指定等级的 PVC。详细信息可参考 PersistentVolumeClaim 章节。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
 type: gp2

Provisioner

StorageClass 都有存储供应商 provisioner，用来决定哪种 volume 插件提供给 PV 使用。必须制定该字段。
你不限于指定此处列出的“内部”供应商（其名称前缀为“kubernetes.io”并与 Kubernetes 一起分发）。你还可以运行和指定外部供应商，它们是遵循 Kubernetes 定义的规范的独立程序。外部提供者的作者对代码的生命周期，供应商的分发方式，运行状况以及使用的卷插件（包括 Flex）等都有充分的自主权。库 kubernetes-incubator/external-storage 存放了一个库，用于编写外部存储供应商，而这些提供者实现了大量的规范，并且是各种社区维护的。

参数

StorageClass 有一些参数用于描述归属于该 StorageClass 的 volume。不同的存储提供商可能需要不同的参数。比如，参数 type 对应的值 io1，还有参数 iopsPerGB，都是 EBS 专用的参数。当参数省略时，就会使用它的默认值。

AWS

…

GCE

…

Glusterfs

…

OpenStack Cinder

…

vSphere

…

Ceph RBD

 apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
 name: fast
 provisioner: kubernetes.io/rbd
 parameters:
 monitors: 10.16.153.105:6789
 adminId: kube
 adminSecretName: ceph-secret
 adminSecretNamespace: kube-system
 pool: kube
 userId: kube
 userSecretName: ceph-secret-user

● monitors：Ceph 的 monitor，逗号分隔。该参数是必须的。
● adminId：Ceph 的客户端 ID，可在 pool 中创建镜像。默认的是“admin”。
● adminSecretNamespace：adminSecret 的命名空间，默认值是“default”。
● adminSecretName：adminId 的 Secret Name。改参数是必须的，提供的秘钥必须有类型“kubernetes.io/rbd”。
● pool：Ceph 的 RBD pool，默认值是“rbd”。
● userId：Ceph 的客户 ID，用于映射 RBD 镜像的，默认值和 adminId 参数相同。
● userSecretName：Ceph Secret 的名称，userId 用该参数来映射 RBD 镜像。它必须和 PVC 在相同的命名空间。该参数也是必须的。提供的秘钥必须有类型“kubernetes.io/rbd”。比如，按照下面的方式来创建：

$ kubectl create secret generic ceph-secret --type= kubernetes.io/rbd  --from-literal=key= QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==  --namespace=kube-system

Quobyte

…

Azure Disk

…

Portworx Volume

…

ScaleIO

…

配置

如果你在写配置模板和示例，用于在需要持久化存储的集群中使用，那么，我们建议你使用以下的一些模式：
● 在你的捆绑配置（如 Deployment、ConfigMap 胖）中包含 PVC 对象。
● 在配置中不要包含 PersistentVolume 对象，因为实例化配置的用户可能没有创建 PersistentVolumes 的权限
● 当用户提供实例化模板时，给用户提供存储类名称的选项。
▷ 如果用户提供了一个 StorageClass 名称，并且 Kubernetes 版本是 1.4 及以上，那么将该值设置在 PVC 的 volume.beta.kubernetes.io/storage-class 标注上。这会使得 PVC 匹配到正确的 StorageClass。
▷ 如果用户没有提供 StorageClass 名称，或者集群版本是 1.3，那么久需要在 PVC 配置中设置 volume.alpha.kubernetes.io/storage-class: default 标注。
☞ 这会使得在一些默认配置健全的集群中，PV 可以动态的提供给用户。
☞ 尽管在名称中包含了 alpha 单词，但是该标注对应的代码有着 beta 级别的支持。
☞ 不要使用 volume.beta.kubernetes.io/storage-class，无论设置什么值，甚至是空字符串。因为它会阻止 DefaultStorageClass 许可控制器。
● 在你的工具中，要监视那些一段时间后还没有获得绑定的 PVC，并且展示给用户。因为这可能表明集群没有支持动态存储（此时我们应该创建匹配的 PV），或者集群没有存储系统（此时用户不能部署需要 PVC 的情况）。
● 未来，我们期望大多数集群都可以使能 DefaultStorageClass，并且能有一些可用的存储形式。然而，可能没有行在所有集群都能运的 StorageClass，所以默认情况下不要只设置一种。在某些时候，alpha 标注将不再具有意义，但复位 PVC 的 storageClass 字段将具有所需的效果。

感谢各位的阅读！关于“Kubernetes 存储中 Persistent Volumes 有什么用”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！