标签：存储 PV Kubernetes 绑定 PVC StorageClass Pod

一、概念解析

1. PV 与 PVC

　　为了能够屏蔽底层存储实现的细节，让用户方便使用及管理员方便管理， Kubemetes 从 1.0 版本开始引入了 Persistent Volume（PV）与 Persistent Volume Claim（PVC）资源对象来实 现存储管理子系统。 　　PV 是对存储资源的抽象，将存储定义为一种容器应用可以使用的资源。PV 由管理员创建和配置，它与存储提供商的具体实现直接相关，例如 GlusterFS、iSCS、RBD 或 GCE 或 AWS 公有云提供的共享存储，通过插件式的机制进行管理，供应用访问和使用。除了 EmptyDir 类型的存储卷，PV 的生命周期独立于使用它的 Pod。 　　PVC 则是用户对存储资源的一个申请。就像 Pod 消耗 Node 的资源一样，PVC 消耗 PV 资源。 PVC 可以申请存储空间的大小和访问模式（例如 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany)。

2. StorageClass

　　使用 PVC 申请的存储空间可能仍然不满足应用对存储设备的各种需求。在很多情况下，应用程序对存储设备的特性和性能都有不同的要求，包括读写速度、并发性能、数据冗余等要求，Kubernetes 从 1.4 版本开始引入了一个新的资源对象 StorageClass，用千标记存储资源的特性和性能，根据 PVC 的需求动态供给合适的 PV 资源。到 Kubemetes 1.6 版本时，StorageClass 和存储资源动态供应的机制得到完善，实现了存储卷的按需创建，在共享存储的自动化管理进程中实现了重要的一步。 　　通过 StorageClass 的定义，管理员可以将存储资源定义为某种类别（Class），正如存储设备对于自身的配置描述，例如快速存储、慢速存储、有数据冗余、无数据冗余等。用户根据StorageCiass 的描述就可以直观地得知各种存储资源的特性，根据应用对存储资源的需求去申请存储资源了。

3. CSI

　　Kubernetes 从 1.9 版本开始引入容器存储接口 Container Storage Interface（CSI）机制，目标是在 Kubernetes 和外部存储系统之间建立一套标准的存储管理接口，具体的存储驱动程序由存储提供商在 Kubernetes 之外提供，并通过该标准接口为容器提供存储服务，类似 CRI（容器运行时接口）和 CNI（容器网络接口），目的是将 Kubernetes 代码与存储相关代码解耦。    

二、PV 和 PVC 的工作原理

　　我们可以将 PV 看作可用的存储资源，PVC 则是对存储资源的需求。 PV 和 PVC 的生命周期如下： 　　主要包括资源供应（Provisioning）、资源绑定（Binding）、资源使用（Using）、资源回收（Reclaiming）几个阶段。

1. 资源供应

　　Kubernetes 支持两种资源供应模式：静态模式（Static）和动态模式（Dynamic），资源供应的结果就是将适合的 PV 与 PVC 成功绑定。

（1）静态模式

　　集群管理员预先创建许多 PV，在 PV 的定义中能够体现存储资源的特性。 　　原理图示：（通过 PV 和 PVC 完成绑定，供 Pod 使用）

（2）动态模式

　　集群管理员无须预先创建 PV，而是通过 StorageClass 的设置对后端存储资源进行描述，标记存储的类型和特性。用户通过创建 PVC 对存储类型进行申请，系统将自动完成 PV 的创建及与 PVC 绑定。 　　如果 PVC 声明的 Class 为空 ”“，则说明 PVC 不使用动态模式 。另外，Kubernetes 支持设置集群范围内默认的 StorageClass，通过 kube-apiserver 开启准入控制器 DefaultStorageClass，可以为用户创建的 PVC 设置一个默认的存储类 StorageClass。 　　原理图示：（通过 StorageClass 和 PVC 完成资源动态绑定，系统自动生成 PV 并与 PVC 绑定，供 Pod 使用）

2. 资源绑定

　　在用户定义好 PVC 之后，系统将根据 PVC 对存储资源的请求（存储空间和访问模式）在已存在的 PV 中选择一个满足 PVC 要求的 PV ，一旦找到，就将该 PV 与用户定义的 PVC 绑定，用户的应用就可以使用这个 PVC 了。如果在系统中没有满足 PVC 要求的 PV，PVC 则会无限期处于 Pending 状态，直到系统管理员创建了一个符合其要求的 PV。 　　PV 一旦与某个 PVC 上完成绑定，就会被这个 PVC 独占，不能再与其他 PVC 绑定了。PVC 与 PV 的绑定关系是一对一的，不会存在一对多的情况。如果 PVC 申请的存储空间比 PV 拥有的空间少，则整个 PV 的空间都能为 PVC 所用，可能造成资源的浪费。 　　如果资源供应使用的是动态模式，则系统在为 PVC 找到合适的 StorageClass 后，将自动创建一个 PV 并完成与 PVC 的绑定。

3. 资源使用

（1）资源使用

　　Pod 需要使用存储资源时，需要在 Volume 的定义中引用 PVC 类型的存储卷，将 PVC 挂载到容器内的某个路径下进行使用。Volume 的类型字段为“persistentVolumeClaim"。 　　Pod 在挂载 PVC 后，就能使用存储资源了 。同一个 PVC 还可以被多个 Pod 同时挂载使用，在这种情况下，应用程序需要处理好多个进程访问同一个存储的问题。

（2）使用中的存储对象的保护机制（Storage Object in Use Protection）

　　存储资源（PV、PVC）相对于容器应用（Pod）是独立管理的资源，可以单独删除。在做删除操作的时候，系统会检测存储资源当前是否正在被使用，如果仍被使用，则对相关资源对象的删除操作将被推迟，直到没被使用才会执行删除操作，这样可以确保资源仍被使用的情况下不会被直接删除而导致数据丢失。 <1>对 PVC 的删除操作将等到使用它的 Pod 被删除之后再执行，此时状态为 “Terminating"，系统为其设置的 Finalizer 为“kubernetes.io/pvc-protection"。 <2>对 PV 的删除操作将等到绑定它的 PVC 被删除之后再执行，此时状态为 “Terminating"，系统为其设置的 Finalizer 为“kubernetes.io/pv-protection"。

4. 资源回收

　　用户在使用存储资源完毕后，可以删除 PVC。与该 PVC 绑定的 PV 将被标记为＂已释放”，但还不能立刻与其他 PVC 绑定。通过之前 PVC 写入的数据可能还被留在存储设备上，只有在清除这些数据之后，该 PV 才能再次使用。 　　管理员可以对 PV 设置资源回收策略（Reclaim Policy），可以设置三种回收策略：Retain、Delete 和 Recycle。

（1）Retain（保留数据）

　　Retain 策略表示在删除 PVC 之后，与之绑定的 PV 不会被删除，仅被标记为己释放（release）。PV 中的数据仍然存在，在清空之前不能被新 PVC 使用，需要管理员手工清理之后才能继续使用，清理步骤如下： <1>删除 PV 资源对象，此时与该 PV 关联的某些外部存储提供商的后端存储资产中的数据仍然存在。 <2>手工清理 PV 后端存储资产中的数据。 <3>手工删除后端存储资产。如果希望重用该存储资产，则可以创建一个新的 PV 与之关联。

（2）Delete（删除数据）

　　Delete 策略表示自动删除 PV 资源对象和相关后端存储资产，并不是所有类型的存储提供商都支持 Delete 策略，目前支待 Delete 策略的存储提供商包括 AWSElasticBlockStore、GCEPersistentDisk、Azure Disk、Cinder 等。 　　通过动态供应机制创建的 PV 将继承 StorageClass 的回收策略，默认为 Delete 策略。管理员应该基于用户的需求设置 StorageClass 回收策略，或者在创建 PV 后手工更新其回收策略。

（3）Recycle（回收，已被弃用）

　　目前只有 HostPort 和 NFS 类型的 Volume 支持 Recycle 策略，其实现机制为运行 rm -rf /thevolume/* 命令，删除 Volume 目录下的全部文件，使得 PV 可以被新的 PVC 使用。 　　注意：Recycle 策略巳被弃用，推荐以动态供应机制管理容器所需存诸资源。

5. PVC 资源扩容

　　PVC 在首次创建成功之后，还应该能够在使用过程中实现空间的扩容，对 PVC 扩容机制的支待到 Kubernetes 1.11 版本时达到 Beta 阶段。

（1）扩容支持前提

　　PVC 扩容支持的前提是底层存储驱动支持扩容操作。

（2）扩容操作步骤

<1>在 PVC 对应的 StorageClass 定义中设置 allowVolumeExpansion=true； <2>修改 PVC 的定义，将 resources.requests.storage 设置为一个更大的值，系统将会基于 PVC 新设置的存储空间触发后端 PV 的扩容操作，而不会创建一个新的 PV 资源对象。

（3）扩容失败恢复步骤

<1>设置与 PVC 绑定的 PV 资源的回收策略为 Retain； <2>删除 PVC，此时 PV 的数据仍然存在； <3>删除 PV 中的 claimRef 定义，使得 PV 的状态为“Available”，这样新的 PVC 可以与之绑定； <4>新建一个 PVC，设置比 PV 小的存储空间申请，同时设置 volumeName 字段为 PV 的名称，结果将使得 PVC 与 PV 完成绑定； <5>恢复 PV 的原回收策略。    

三、PV 详解

　　PV 作为对存储资源的定义，主要涉及存储能力、访问模式、存储类型、回收策略、后端存储类型等关键信息的设置。

1. 存储容量（Capacity）

　　描述存储的容量，目前仅支持对存储空间的设置，未来可能加入 IOPS、吞吐率等设置。

2. 存储卷模式（Volume Modes）

　　可以设置的选项包括 Filesystem（文件系统，默认值）和 Block（块设备）。 　　文件系统模式的 PV 将以目录形式挂载到 Pod 内。 　　如果模式为块设备，但是设备是空的，则 Kubernetes 会自动在块设备上创建一个文件系统。支持块设备的存储类型会以裸设备（Raw Block Device）的形式挂载到容器内，并且不会创建任何文件系统，适用于需要直接操作裸设备（速度最快）的应用程序。

3. 访问模式（Access Modes）

　　PV 存储卷在挂载到宿主机系统上时，可以设置不同的访问模式（Access Modes）。PV支持哪些访问模式由存储提供商提供支持，例如 NFS 可以支持多个客户端同时读写（ReadWriteMany）模式，但一个特定的 NFS PV 也可以以只读（Read-only）模式导出到服务器上。 　　Kubernetes 支持的访问模式如下： （1）ReadWriteOnce（RWO）：读写权限，并且只能被单个 Node 挂载。 （2）ReadOnlyMany（ROX) ：只读权限，允许被多个 Node 挂载。 （3）ReadWriteMany（RWX） ：读写权限，允许被多个 Node 挂载。 某些 PV 可能支持多种访问模式，但 PV 在挂载时只能使用一种访问模式，多种访问模式不能同时生效。

4. 存储类别（Class）

　　PV 可以设定其存储的类别，通过 storageClassName 参数指定一个 StorageClass 资源对象的名称。具有特定类别的 PV 只能与请求了该类别的 PVC 绑定。未设定类别的 PV 则只能与不请求任何类别的 PVC 绑定。

5. 回收策略（Reclaim Policy）

　　通过 PV 定义 persistentVolumeReclaimPolicy 字段进行设置，可选项如下： （1）Retain：保留数据， 需要手工处理。 （2）Delete：与 PV 相连的后端存储完成 Volume 的删除操作。 （3）Recycle：简单清除文件的操作（例如运行 rm -rf evolu ＊命令）。 　　目前只有 NFS 和 HostPath 两种类型的 PV 支持 Recycle 策略；AWSElasticBlockStore、GCEPersistentDisk、AzureDisk 和 Cinder 类型的 PV 支持 Delete 策略。

6. 挂载选项（Mount Options）

　　在将 PV 挂载到一个 Node 上时，根据后端存储的特点，可能需要设置额外的挂载选项的参数 ，这个可以在 PV 定义中的 mountOptions 字段进行设置。 　　注意：Kubemetes 不会对挂载选项进行验证，如果设置了错误 的挂载选项，则挂载将会失败。

7. 节点亲和性（Node Affinity）

　　PV 可以设置节点亲和性来限制只能通过某些 Node 访问 Volume，可以在 PV 定义的 nodeAffinity 字段中进行设置。使用这些 Volume 的 Pod 将被调度到满足条件的 Node 上。

8. 状态

　　某个 PV 在生命周期中可能处千以下 4 个阶段之一： （1）Available：可用状态，还未与某个 PVC 绑定。 （2）Bound：已与某个 PVC 绑定。 （3）Release：与之绑定的 PVC 已被删除，但未完成资源回收，不能被其他 PVC 使用。 （4）Failed：自动资源回收失败。    

四、PVC 详解

　　PVC 作为用户对存储资源的需求申请，主要涉及存储空间请求 、访问模式、 PV 选择条件和存储类别等信息的设置。

1. 资源请求（Resources）

　　描述对存储资源的请求，通过 resources.requests.storage 字段设置需要的存储空间大小。

2. 访问模式（Access Modes）

　　PVC 也可以设置访问模式，用于描述用户应用对存储资源的访问权限。其三种访问模式的设置与 PV 设置相同。

3. 存储卷模式（Volume Modes）

　　PVC 也可 以设置存储卷模式，用于描述希望使用的 PV 存储卷模式，包括文件系统（Filesystem）和块设备（Block）。PVC 设置的存储卷模式应该与 PV 存储卷模式相同，以实现绑定；如果不同，则可能出现不同的绑定结果。

4. PV 选择条件（Selector）

　　通过 Label Selector 的设置，可使 PV 对于系统中已存在的各种 PV 进行筛选。系统将根据标签选出合适的 PV 与该 PVC 进行绑定。对选择条件可以使用 matchLabels 和 malchExpressions 进行设置，如果两个字段都已设置，则 Selector 的逻辑将是两组条件同时满足才能完成匹配。

5. 存储类别（Class）

　　PVC 在定义时可以设定需要的后端存储的类别（通过 storageClassName 字段指定），以减少对后端存储特性的详细信息的依赖。只有设置了该 Class 的 PV 才能被系统选出，并与该 PVC 进行绑定。 PVC 也可以不设置 Class 需求，如果 storageClassName 字段值被设置为空（storageClassName=""），则表示该 PVC 不要求特定的 Class, 系统将只选择未设定 Class 的 PV 与之匹配和绑定。PVC 也可以完全不设置 storageClassName 字段，此时将根据系统是否启用了名为 DefaultStorageClass 的 admission controller 进行相应的操作。 　　当 Selector 和 Class 都进行了设置时，系统将选择两个条件同时满足的 PV 与之匹配。另外，如果 PVC 设置了 Selector, 系统无法使用动态供给模式为其分配 PV。    

五、Pod 使用 PVC

　　在 PVC 创建成功之后，Pod 就可以以存储卷的方式使用 PVC 的存储资源了。PVC 受限于命名空间，Pod 在使用 PVC 时必须与 PVC 处于同一个命名空间。 　　Kubemetes 为 Pod 挂载 PVC 的过程如下：系统在 Pod 所在的命名空间口找到其配置的 PVC，然后找到 PVC 绑定的后端 PV，PV 存储挂载到 Pod 所在 Node 的目录下，最后将 Node 的目录挂载到 Pod 的容器内。 　　实践操作示例：

（1）创建两个 PV

　　PV 属性：存储空间为 10GB，存储卷模式为 Filesystem，访问模式为 ReadWriteOnce，回收策略为 Retain，后端存储类型为 nfs。 　　PV 属性：存储空间为 20GB，存储卷模式为 Filesystem，访问模式为 ReadWriteMany，回收策略为 Retain，后端存储类型为 nfs。

（2）创建 PVC

　　PVC 属性：访问模式为 ReadWriteMany，存储卷模式为 Filesystem，存储空间需求为 18GB。 　　已创建的两个 PV 中，wjt-pv2 的卷访问模式和存储空间都符合 PVC wjt-pvc 的需求，而 PV wjt-pv1 不符合，所以 PVC wjt-pvc 与 PV wjt-pv2 进行了绑定。

（3）在 Pod 中使用 PVC

　　在 Pod 所在 Node 上能看到 Kubernetes 已经挂载了 PV 对应的卷： 　　Pod 上也将 PV 对应的卷挂载到了指定的目录下：    

六、StorageClass 详解

　　StorageClass 作为对存储资源的抽象定义，对用户设置的 PVC 申请屏蔽后端存储的细节，一方面减少了用户对于存储资源细节的关注，另一方面减轻了管理员手工管理 PV 的工作，由系统自动完成 PV 的创建和绑定，实现动态的资源供应。基于 StorageClass 的动态资源供应模式将逐步成为云平台的标准存储管理模式。 　　StorageClass 资源对象的定义主要包括名称、后端存储的提供者（provisioner） 、后端存储的相关参数配置和回收策略。StorageClass 名称尤为重要，将在创建 PVC 时引用，管理员应该准确命名具有不同存储特性的 StorageClass。 　　StorageClass 一旦被创建，则无法修改。如需更改，则只能删除原 StorageClass 资源对象并重新创建。

1. 配置参数

（1）存储提供者（Provisioner）

　　描述存储资源的提供者，用于提供具体的 PV 资源，也可以将其看作后端存储驱动。

（2）资源回收策略（Reclaim Policy）

　　通过动态资源供应模式创建的 PV 将继承在 StorageClass 资源对象上设置的回收策略，配置字段名称为 “reclaimPolicy"，可以设置的选项包括 Delete（删除）和 Retain（保留） 　　如果 StorageClass 没有指 reclaimPolicy，则默认值为 Delete。 　　对于管理员手工创建的仍被 StorageClass 管理的 PV 将使用创建 PV 时设置的资源回收策略。

（3）是否允许存储扩容（Allow Volume Expansion）

　　PV 可以被配置为允许扩容，当 StorageClass 资源对象的 allowVolumeExpansion 字段被设置为 true 时，将允许用户通过编辑 PVC 的存储空间自动完成 PV 的扩容。

（4）挂载选项（Mount Options）

　　通过 StorageClass 资源对象的 mountOptions 字段，系统将为动态创建的 PV 设置挂载选项。并不是所有 PV 类型都支持挂载选项，如果 PV 不支持但 StorageClass 设置了该字段，则 PV 将会创建失败。另外，系统不会对挂载选项进行验证，如果设置了错误的选项，则容器在挂载存储时将直接失败。

（5）存储绑定模式（Volume Binding Mode）

　　StorageClass 资源对象的 volumeBindingMode 字段设置用于控制何时将 PVC 与动态创建的 PV 绑定。目前支持的绑定模式包括 Immediate 和 WaitForFirstComumer。 　　存储绑定模式的默认值为 Immediate，表示当一个 PVC 创建出来时，就动态创建 PV 并进行 PVC 与 PV 的绑定操作。需要注意的是，对于拓扑受限或无法从全部 Node 访问的后端存储，将在不了解 Pod 调度需求的情况下完成 PV 的绑定操作，这可能会导致某些 Pod 无法完成调度。 　　WaitForFirstConsumer 绑定模式表示 PVC 与 PV 的绑定操作延迟到第一个使用 PVC 的 Pod 创建出来时再进行。系统将根据 Pod 的调度需求，在 Pod 所在的 Node 上创建 PV。

（6）存储参数（Parameters）

　　后端存储资源提供者的参数设置，不同的 Provisioner 可能提供不同的参数设置。

2. 实践示例

　　本例以 NFS 作为后端存储。

（1）搭建 NFS 共享存储服务

　　在某个 master 节点启动 NFS 服务，将其某个本地目录共享给 Kubernetes 所有节点读写。其他节点也需要安装一下 nfs。

（2）部署 NFS Provisioner

　　接下来需要部署一个自动创建 PV 的自动配置程序。 <1>创建 ServiceAccount <2>部署 NFS Provisioner 　　这里的 Service Account 指定上一个步骤中创建的 ServiceAccount 名称。同时需要设置 NFS 共享服务的信息和 PROVISIONER_NAME 等常量。

（3）创建 StorageClass

　　Provisioner 指定上一个步骤设置的 PROVISIONER_NAME 常量的值。

（4）创建 PVC

　　storageClassName 指定上一个步骤创建的 StorageClass 的名称。

　　PVC 创建完成以后，由于 StorageClass 的 VolumeBindingMode 为 Immediate，NFS Provisioner 立即自动为 PVC 创建 PV，并完成 PV 与 PVC 的绑定。可以看到，NFS 共享目录下为该 PV 创建了一个子目录。

（5）Pod 使用 PVC

　　claimName 指定上一个步骤创建的 PVC 的名称。 　　PV 挂载成功，写入成功。  

七、CSI 存储机制详解

　　Kubernetes 从 1.9 版本开始引入容器存储接口 Container Storage Interface（CSI）机制，用于在 Kubernetes 和外部存储系统之间建立一套标准的存储管理接口，通过该接口为容器提供存储服务。存储提供方只需基于标准接口进行存储插件的实现，就能使用 Kubernetes 的原生存储机制为容器提供存储服务了。在 CSI 成为 Kubernetes 的存储供应标准之后，存储提供方的代码与 Kubernetes 代码彻底解耦，部署也与 Kubernetes 核心组件分离。 　　CSI 的核心组件和部署架构： 其中主要包括两类组件：CSI Controller 和 CSI Node。

（1）CSI Controller

　　CSI Controller 的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。在 Kubernetes 中建议将其部署为单实例 Pod，可以使用 StatefuISet 或 Deployment 控制器进行部署，设置副本数最为，保证一种存储插件只运行一个控制器实例。 　　在这个 Pod 内部署两个容器： <1>与 Master（kube-controller-mapager）通信的辅助 sidecar 容器。sidecar 容器内又可以包含以下容器： 　　external-attacher：监控 VolumeAttachment 资源对象的变更，触发针对 CSI 端点的ControllerPublish 和 ControllerUnpublish 操作。 　　external-provisioner：监控 PersistentVolumeClaim 资源对象的变更，触发针对 CSI 端点的 CreateVolume 和 DeleteVolume 操作。 <2>CSI Driver 存储驱动容器，由第三方存储提供商提供，需要实现上述接口。 　　这两个容器通过本地 Socket（Unix Domain Socket，UDS），并使用 gPRC 协议进行通信。 sidecar 容器通过 Socket 调用 CSI Driver 容器的 CSI 接口，CSI Driver 容器负责具体的存储卷操作。

（2）CSI Node

　　CSI Node 的主要功能是对主机（Node）上的 Volume 进行管理和操作。Kubemetes 中建议将其部署为 DaemonSet，在需要提供存储资源的各个 Node 上都运行一个 Pod。 　　在这个 Pod 内部署两个容器： <1>与 kubelet 通信的辅助 sidecar 容器 node-driver-registrar，主要功能是将存储驱动注册到 kubelet 中。 <2>CSI Driver 存储驱动容器，由第三方存储提供商提供，主要功能是接收 kubelet 的调用，需要实现一系列与 Node 相关的 CSI 接口，例如 NodePublishVolume 接口，用于将 Volume 挂载到 容器内的目标路径）、 NodeUnpublishVolume 接口（用于从容器中卸载 Volume) ，等等。 　　node-driver-registrar 容器与 kubelet 通过 Node 一个 hostPath 目录下的 unix socket 进行通信。CSI Driver 容器与 kubelet 通过 Node 主机另一个 hostPath 目录下的 unix socket 进行通信，同时需要将 kubelet 的工作目录（默认为/var/lib/kubelet）挂载给 CSI Driver 容器，用于为 Pod 进行 Volume 管理操作（包括 mount umount 等）。         参考： 《Kubernetes 权威指南第 5 版》 https://blog.csdn.net/u011837804/article/details/128692744 https://developer.aliyun.com/article/1381187 https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner    

标签：存储,PV,Kubernetes,绑定,PVC,StorageClass,Pod
From： https://www.cnblogs.com/wujuntian/p/18105368