kubernetes | PV\PVC\StorageClass

卷（Volume）

介绍

PersistentVolume和PersistentVolumeClaim是为了将存储如何供应的细节从其如何被使用中抽象出来才设计出来的API。持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。他们具有：脱离pod生命周期、用户可管理、存储抽象设计、灵活性更强的特点。

持久卷声明（PersistentVolumeClaim，PVC）表达的是用户对存储的要求。概念上与pod类似。pod会耗用节点资源，而PVC会耗用PV的资源。pod可以请求特定数量的资源（CPU和内存）；同样PVC也可以申请特定的大小和访问模式的PV。（例如，可以要求PV卷能够以ReadWriteOnce、ReadWriteMany或者ReadonlyMany模式之一来挂载）

尽管PersistentVolumeClaim允许用户消耗抽象的存储资源，常见的情况通常是：针对不同需求的用户申请具有不同属性的PersistentVolume，集群管理员通常需要能够提供不同性质的PersistentVolume，并且这些PV之间的差别不仅限于卷的大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户，于是就有了存储类（StorageClass）资源。

Kubernetes容器存储能力介绍

  • 临时存储

    • EmptyDir

      当pod分配到某个node上时，emptyDir卷会被创建，它一开始是空的，并且在pod在该节点上运行期间，卷一直都在。当pod因为某些原因被节点删除时，emptyDir卷中的数据可能会被永久删除。（容器崩溃不会导致pod从节点移除，因此emptyDir卷中的数据是安全的）[Qos]

      emptyDir 的一些用途：

      • 缓存空间，例如基于磁盘的归并排序。

      • 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。

      • 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。

    • Hostpath（Hostpath是将节点本地文件系统的路径映射到pod容器中，供程序使用。pod删除后，hostpath中的数据不会被k8s清除，）除了必需的 path 属性之外，用户可以选择性地为 hostPath 卷指定 type。

  • 持久存储声明

    • PersistentVolumeClaim（具有独立的生命周期）

 

与临时存储相比，持久化存储PV具有：每个存储卷拥有独立的生命周期，不再跟随pod创建和销毁；存储卷中的数据可以随着pod在集群迁移；多个不同的pod可以共享同一个存储卷。

 

  • 实验：配置Pod以使用PersistentVolume作为存储。

  • 步骤：

    • 作为集群管理员来创建由物理内存支持的PersistentVolume

    • 以开发人员或者集群用户的角色创建一个PersistentVolumeClaim，它将自动绑定到合适的PVC

    • 创建一个使用PVC作为存储的Pod

  • 清理

  • 访问控制

    使用GID配置的存储仅允许Pod使用相同的GID进行写入。GID不匹配或缺失将会导致无法访问错误，为了减少与用户的协调，管理员可以对PV添加GID注解。这样GID就能自动添加到使用PV的任何Pod中。

    使用 pv.beta.kubernetes.io/gid 注解的方法如下所示：

     
    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: pv1
      annotations:
        pv.beta.kubernetes.io/gid: "1234"
     

    当Pod使用带有GID注解的PV时，注解的GID会被应用于Pod中的所有容器，停用的方法与Pod的安全上下文中指定的GID相同。每个GID，无论是来自PV注解还是Pod规约，都会被用与每个容器中运行的第一个进程。

    Pod的安全上下文中指定的GID指的是：

    安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。 安全上下文包括但不限于：自主访问控制（Discretionary Access Control）：基于 用户 ID（UID）和组 ID（GID）. 来判定对对象（例如文件）的访问权限。

一、（1）创建PersistentVolume

以创建一个hostpath类型的PersistentVolume为例，hostpath类型的PersistentVolume使用节点上的文件或者目录来模拟网络附加存储。

NAS是网络附加存储。顾名思义，NAS通常通过路由器或网络交换机通过以太网端口连接到您的计算机，并允许多台计算机同时连接到您的NAS设备。

网络附加存储是一种专用文件存储系统，可以同时连接到许多不同的设备，并允许访问同一磁盘。 NAS设备具有自己的文件服务器功能，可以存储和管理文件访问，但没有任何键盘或显示界面，并且可以从连接的计算机/计算机进行管理。

 

在生产集群中，不会使用 hostPath。 集群管理员会提供网络存储资源，比如 Google Compute Engine 持久盘卷、NFS 共享卷或 Amazon Elastic Block Store 卷。 集群管理员还可以使用 StorageClasses 来设置动态提供存储。 【这个稍后再介绍】

hostPath PersistentVolume 的配置文件：

 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
 

利用 kubectl get pv task-pv-volume 命令查看：

 

 

（2）创建一个 PersistentVolumeClaim。 Pod 使用 PersistentVolumeClaim 来请求物理存储。

PersistentVolumeClaim 的配置文件： 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi 

利用命令 kubectl get pv task-pv-volume 再次查看PersistentVolume的信息，显示：

 

 

利用命令kubectl get pvc task-pv-claim 查看PersistentVolumeClaim，显示：

 

 

（3）最后再创建一个pod，该pod使用前面的PVC来作为存储卷。

下面是pod的配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage
 

利用命令 kubectl get pod task-pv-pod确保容器运行正常以后，打开一个shell来访问pod中的容器:

kubectl exec -it task-pv-pod -- /bin/bash

然后在shell中，验证nginx是否正在从hostpath卷提供index.html，获得的结果为：

 

 

看到此消息，则证明已经成功地配置了 Pod 使用 PersistentVolumeClaim 的存储。

并且查看在pod中挂载的位置：

 

 

二 （1）删除Pod

（2）删除PVC

（3）删除PV

 

 

由此可见，删除了pod和PVC之后，PV都依然存在于相应的路径下面，此时，如果想删除相应的文件，需要在shell中执行rm 命令。

总结：

（1）PersistentVolume： 作为一种存储，为云原生应用提供一种拥有独立生命周期的，用户可管理的存储抽象设计。

（2）PersistentVolumeClaim：持久化存储生命，是k8s解耦云原生应用和数据存储而设计的，通过PVC可以让资源管控更加灵活，应用模版更加通用。

（3）StorageClass：存储类，是k8s平台为存储提供商提供存储接入的一种声明。与动态分配存储卷有关。

动态卷：资源管控比较宽松；

静态卷：资源管控较为严格。

  • 静态卷中PV的状态转换：

     

     

  • 当我们k8s业务上来的时候，大量的pvc,此时我们人工创建匹配的话，工作量就会非常大了，需要动态的自动挂载相应的存储。这个时候就需要StorageClass，来对接存储，StorageClass 相当于一个创建 PV 的模板，用户通过 PVC 申请存储卷，StorageClass 通过模板自动创建 PV，然后和 PVC 进行绑定，是没有PV的基础上由SC来创建，不需要人工干预。【再找一下相关的实例】

 

引入PVC/SC后，带来的收益：开发人员只需要关注存储需求(IO/容量/访问模式等)，不需要关注存储类型，以statefuleSet为例：考虑如何理解稳定的持久化存储

  • 每个Pod对应一个PVC，PVC的名称是这样组成的:$(volumeClaimTemplates.name)-$(pod's hostname),跟对应的Pod是一一对应的。

  • 当Pod发生re-schedule（其实是recreate）后，它所对应的PVC所Bound的PV仍然会自动的挂载到新的Pod中。

  • Kubernetes会按照VolumeClaimTemplate创建N(N为期望副本数)个PVC，由PVCs根据指定的StorageClass自动创建PVs。

  • 当通过级联删除StatefulSet时并不会自动删除对应的PVCs，所以PVC需要手动删除。

  • 当通过级联删除StatefulSet或者直接删除对应Pods时，对应的PVs并不会自动删除。需要你手动的去删除PV。

  •  

posted @ 2022-01-06 20:10  Tammyhaha  阅读(188)  评论(0)    收藏  举报