k8s pv & pvc
综述
持久化卷（Persistent Volume, PV）允许用户将外部存储映射到集群，而持久化卷申请（Persistent Volume Claim, PVC）则类似于许可证，使有授权的应用（Pod）可以使用PV。
●持久化卷（Persistent Volume，PV）。
●持久化卷申请（Persistent Volume Claim，PVC）。
●存储类（Storage Class，SC）。
概括地说，PV代表的是Kubernetes中的存储；PVC就像许可证，赋予Pod访问PV的权限；CS则使分配过程是动态的。
概念
PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明，PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。
k8s pvc的使用
ka get pv
ka get pvc
ka get pod
ka get svc/service
为什么要引入PV和PVC
- Pod本身具有生命周期，故其内部运行的容器及其相关数据自身均无法持久存在。Docker支持配置容器使用存储卷将数据持久存储于容器自身文件系统之外的存储空间中，它们可以是节点文件系统或网络文件系统之上的存储空间。相应地，Kubernetes也支持类似的存储卷功能，不过，其存储卷是与Pod资源绑定而非容器。简单来说，存储卷是定义在Pod资源之上、可被其内部的所有容器挂载的共享目录，它关联至某外部的存储设备之上的存储空间，从而独立于容器自身的文件系统，而数据是否具有持久能力则取决于存储卷自身是否支持持久机制。
存储卷类型
- Kubernetes支持非常丰富的存储卷类型，包括本地存储（节点）和网络存储系统中的诸多存储机制，甚至还支持Secret和ConfigMap这样的特殊存储资源。对于Pod来说，卷类型主要是为关联相关的存储系统时提供相关的配置参数，例如，关联节点本地的存储目录与关联GlusterFS存储系统所需要的配置参数差异巨大，因此指定存储卷类型时也就限定了其关联到的后端存储设备。
emptyDir & hostPath & NFS & Ceph & GlusterFS
- emptyDir与hostPath属于节点级别的卷类型，emptyDir的生命周期与Pod资源相同，而使用了hostPath卷的Pod一旦被重新调度至其他节点，那么它将无法再使用此前的数据。因此，这两种类型都不具有持久性。要想使用持久类型的存储卷，就得使用网络存储系统，如NFS、Ceph、GlusterFS等，或者云端存储，如gcePersistentDisk、awsElasticBlockStore等。
Kubernetes为此专门设计了一种集群级别的资源PersistentVolume（简称PV），它借由管理员配置存储系统，而后由用户通过“persistentVolumeClaim”（简称PVC）存储卷直接申请使用的机制大大简化了终端存储用户的配置过程，有效降低了使用难度。
Secret
- Secret用于向Pod传递敏感信息，如密码、私钥、证书文件等，这些信息如果直接定义在镜像中很容易导致泄露，有了Secret资源，用户可以将这些信息存储于集群中而后由Pod进行挂载，从而实现将敏感数据与系统解耦。
ConfigMap
- ConfigMap资源则用于向Pod注入非敏感数据，使用时，用户将数据直接存储于ConfigMap对象中，而后直接在Pod中使用ConfigMap卷引用它即可，它可以帮助实现容器配置文件集中化定义和管理。
volumesMounts
- name ：指定要挂载的存储的名称，必选字段。
- mountPath ：挂载点路径，容器文件系统上的路径，必选字段。
- readOnly ：是否挂载为只读卷。
- subPath ：挂载存储卷时使用的子路径，即在mountPath指定的路径下使用一个子路径作为其挂载点。
存储卷概述
挂载模式
- ReadWriteOnce（RWO）：限制一个PV只能以读写方式被挂载或绑定到一个PVC。尝试将其绑定到多个PVC的话会失败。块存储通常只支持RWO
- ReadWriteMany（RWM）：则允许一个PV能够以读写方式被绑定到多个PVC上。这种模式通常只支持诸如NFS这样的文件或对象存储。
- ReadOnlyMany（ROM）：允许PV以只读方式绑定到多个PVC。
清理模式
- Delete：Delete是更危险的方式，也是在使用存储类动态创建PV时的默认策略。这一策略会删除对应的PV对象以及外部存储系统中关联的存储资源，从而可能导致数据丢失！因此必须谨慎使用该策略。
- Retain：Retain则会保留对应的PV对象，以及外部存储系统中的资源。不过，也会导致其他PVC无法继续使用该PV。如果想要继续使用保留的PV，则需要执行如下3个步骤。1.手动删除该PV。2.格式化外部存储系统中相对应的存储资源。3.重新创建PV。注意，在实验环境中，非常容易忘记还需要执行以上3个步骤来尝试重新使用一个旧的已删除的设置为retain策略的PV。
pvc 如何匹配 pv
PersistentVolumeClaim（PVC）通过与 PersistentVolume（PV）的标签选择器匹配来请求存储资源。PV 是集群中的存储资源，PVC 是对 PV 的请求。匹配是通过 PVC 的 spec.selector 字段中定义的标签选择器进行的。PVC 会查找标记为 spec.selector.matchLabels 的 PV，并将其与 PVC 绑定。
例如，如果 PVC 的 spec.selector.matchLabels 字段为 {app: my-app, tier: frontend}，则它会匹配标记为 app=my-app 和 tier=frontend 的 PV。如果有多个 PV 匹配 PVC 的标签选择器，则 Kubernetes 会根据其可用性和请求的大小等因素选择一个 PV，并将其绑定到 PVC。
需要注意的是，PVC 与 PV 的标签选择器必须匹配，否则 PVC 将无法找到匹配的 PV。
如果 PVC 的 spec.selector.matchLabels 字段没有设置，则 PVC 会尝试与所有可用的 PV 进行绑定，无论它们是否有标签。这种情况下，PVC 只会考虑 PV 的 spec.storageClassName 字段是否匹配 PVC 的 spec.storageClassName 字段。
如果存在多个可用的 PV，PVC 会选择一个 PV 并将其绑定到 PVC。选择的 PV 取决于 PV 的可用性和 PVC 的请求大小。如果没有可用的 PV，则 PVC 会一直等待，直到有 PV 可用或者 PVC 被删除。
需要注意的是，如果 PVC 没有设置标签选择器，将会限制 PVC 与 PV 的绑定。因为 PV 可能有不同的标签或者没有标签，所以 PVC 可能无法绑定到想要的 PV。因此，建议在 PVC 中设置正确的标签选择器，以确保 PVC 能够正确地匹配到所需的 PV。
persistentvolume-controller waiting for first consumer to be created before binding
persistentvolume-controller waiting for first consumer to be created before binding 是 Kubernetes 控制器的一条日志信息，它表示 PersistentVolume（PV）控制器正在等待第一个使用 PersistentVolumeClaim（PVC）的 Pod 创建，然后才会将该 PVC 绑定到 PV 上。
当 Kubernetes 集群中创建一个 PVC 时，PV 控制器会尝试将该 PVC 绑定到一个可用的 PV 上。如果没有可用的 PV，则 PV 控制器会等待，直到有一个 PV 可用或者 PVC 被删除。
当 PV 控制器找到一个可用的 PV 后，它会将该 PV 绑定到 PVC 上，并将状态更新为“已绑定”。然后，Kubernetes 将 PV 挂载到 Pod 中，以供 Pod 使用。
但是，在某些情况下，当 PVC 和 PV 被创建时，PV 控制器可能会等待一段时间才将它们绑定在一起。这通常是因为没有 Pod 使用该 PVC，因此 PV 控制器不会立即将 PVC 绑定到 PV 上，以避免资源浪费。因此，PV 控制器会等待第一个使用该 PVC 的 Pod 创建，然后才会将该 PVC 绑定到 PV 上。
当 PV 控制器等待第一个使用该 PVC 的 Pod 创建时，它会输出 persistentvolume-controller waiting for first consumer to be created before binding 这条日志信息，以告诉您正在等待 Pod 的创建。一旦 Pod 创建成功，PV 控制器将会自动将 PVC 绑定到可用的 PV 上，然后将状态更新为“已绑定”。
