K8S 存储卷-PV、PVC、NFS 和 StorageClass 深度讲解 (上)

2024-06-13 19:29:26 ⋅ 1133 ⋅ 0 ⋅ 0

一 数据持久化介绍

我们知道，Pod是由容器组成的，而容器宕机或停止之后，数据就随之丢了，那么这也就意味着我们在做Kubernetes集群的时候就不得不考虑存储的问题，而存储卷就是为了Pod保存数据而生的。存储卷的类型有很多，我们常用到一般有以下几种：

  • 1、emptyDir（临时目录）:Pod删除，数据也会被清除，这种存储成为emptyDir，用于数据的临时存储。
  • 2、hostPath(宿主机目录映射)
  • 3、本地的SAN(iSCSI,FC)、NAS(nfs,cifs,http)存储
  • 4、分布式存储（glusterfs，rbd，cephfs）
  • 5、云存储（EBS，Azure Disk）

查看k8s支持的存储类型

[root@master01 ~]# kubectl explain pod.spec.volumes

二 PV与PVC

2.1 PV与PVC

提到存储就不得不说K8S中的PV和PVC了，pv和pvc是kubernetes抽象出来的一种存储资源，具体解释如下

  • PV：PersistentVolume，持久化卷
  • PVC：PersistentVolumeClaim，存储卷创建申请

PV说白了就是一层存储的抽象，底层的存储可以是本地磁盘，也可以是网络磁盘比如NFS、Ceph之类，既然有了PV那为什么又要搞一个PVC呢？

PVC其实在Pod和PV之前又增加了一层抽象，这样做的目的在于将Pod的存储行为于具体的存储设备解耦，试想一下，假设哪天NFS网络存储的IP地址变化了，如果没有PVC，就需要每个Pod都改一下IP的声明，那得多累，有PVC来屏蔽这些细节之后只用改PV即可！

file

pv有pvc的绑定与生命周期

PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索赔检查。 #1、PV和PVC之间的相互作用遵循这个生命周期：
Provisioning（配置）---> Binding（绑定）--->Using（使用）---> Releasing（释放） ---> Recycling（回收）
Provisioning

#2、这里有两种PV的提供方式:静态或者动态
静态-->直接固定存储空间：
    集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中，可用于消费。

动态-->通过存储类进行动态创建存储空间：
    当管理员创建的静态 PV 都不匹配用户的 PVC 时，集群可能会尝试动态地为 PVC 配置卷。此配置基于 StorageClasses：PVC 必须请求存储类，并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。

#3、Binding
在动态配置的情况下，用户创建或已经创建了具有特定数量的存储请求和特定访问模式的PersistentVolumeClaim。 主机中的控制回路监视新的PVC，找到匹配的PV（如果可能），并将 PVC 和 PV 绑定在一起。 如果为新的PVC动态配置PV，则循环将始终将该PV绑定到PVC。 否则，用户总是至少得到他们要求的内容，但是卷可能超出了要求。 一旦绑定，PersistentVolumeClaim绑定是排他的，不管用于绑定它们的模式。

如果匹配的卷不存在，PVC将保持无限期。 随着匹配卷变得可用，PVC将被绑定。 例如，提供许多50Gi PV的集群将不匹配要求100Gi的PVC。 当集群中添加100Gi PV时，可以绑定PVC。

#4、Using
Pod使用PVC作为卷。 集群检查声明以找到绑定的卷并挂载该卷的卷。 对于支持多种访问模式的卷，用户在将其声明用作pod中的卷时指定所需的模式。

一旦用户有声明并且该声明被绑定，绑定的PV属于用户，只要他们需要它。 用户通过在其Pod的卷块中包含PersistentVolumeClaim来安排Pods并访问其声明的PV。

#5、Releasing
当用户完成卷时，他们可以从允许资源回收的API中删除PVC对象。 当声明被删除时，卷被认为是“释放的”，但是它还不能用于另一个声明。 以前的索赔人的数据仍然保留在必须根据政策处理的卷上.

#6、Reclaiming
PersistentVolume的回收策略告诉集群在释放其声明后，该卷应该如何处理。 目前，卷可以是保留，回收或删除。 保留可以手动回收资源。 对于那些支持它的卷插件，删除将从Kubernetes中删除PersistentVolume对象，以及删除外部基础架构（如AWS EBS，GCE PD，Azure Disk或Cinder卷）中关联的存储资产。 动态配置的卷始终被删除

Recycling
如果受适当的卷插件支持，回收将对卷执行基本的擦除（rm -rf / thevolume / *），并使其再次可用于新的声明。

如此，便可以极大地解开了耦合，管理分工明确:
file

总结：
k8s要使用存储卷，需要2步：
1、在pod定义volume，并指明关联到哪个存储设备
2、在容器使用volume mount进行挂载

二 emptyDir存储卷

emptyDir ： 是pod调度到节点上时创建的一个空目录，当pod被删除时，emptyDir中的数据也随即被删除，emptyDir长用于容器间共享文件，或者用于创建临时目录。
注：emptyDir不能够用来做数据持久化

[root@master01 ~]# cat emptydir_demo.yaml 
kind: Deployment
apiVersion: apps/v1
metadata:
  name: emptydir
spec:
  selector:
    matchLabels:
      app: emptydir
  template:
    metadata:
      labels:
        app: emptydir
    spec:
      containers:
        - name: nginx
          image: nginx
          volumeMounts:  # 在容器内定义挂载存储名称和挂载路径
            - mountPath:  /usr/share/nginx/html/
              name: test-emptydir
        - name: busybox
          image: busybox:latest
          volumeMounts:
            - mountPath:  /egon_data
              name: test-emptydir
          command: ['/bin/sh','-c','while true;do echo $(date) >> /egon_data/index.html;sleep 1;done']
      volumes:  # 定义存储卷
        - name: test-emptydir  # 定义存储卷名称
          emptyDir: {}  # 定义存储卷类型

应用:

[root@master01 ~]# kubectl apply -f emptydir_demo.yaml 
deployment.apps/emptydir created
[root@master01 ~]# kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
emptydir-6b6d9b8fbb-pjwpv   2/2     Running   0          52s
[root@master01 ~]# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
emptydir-6b6d9b8fbb-pjwpv   2/2     Running   0          54s   10.2.43.177   10.1.1.104   <none>           <none>

验证：

在上面，我们定义了2个容器，其中一个容器是输入日期到index.html中，然后验证访问nginx的html是否可以获取日期。以验证两个容器之间挂载的emptyDir实现共享。如下访问验证:

跑到一台安装有kubelet的节点上，访问pod ip：10.2.43.177

[root@node01 ~]# curl 10.2.43.177 
Wed Sep 1 05:15:47 UTC 2021
Wed Sep 1 05:15:49 UTC 2021
Wed Sep 1 05:15:50 UTC 2021
Wed Sep 1 05:15:51 UTC 2021
Wed Sep 1 05:15:52 UTC 2021
Wed Sep 1 05:15:53 UTC 2021

三 hostPath

本地存储即对应K8S中的hostPath， hostPath类似于docker -v参数，将宿主主机中的文件挂载pod中，但是hostPath比docker -v参数更强大，（Pod调度到哪个节点，则直接挂载到当前节点上），

所以说，hostPath可以实现持久存储，但是在node节点故障时，也会导致数据的丢失

========创建PV：首先声明一个PV.yaml，内容如下，声明的本地存储路径为/data/hostpath

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
  labels:
    type: local
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  hostPath: # 声明本地存储
    path: /data/hostpath

kubectl apply -f PV.yaml创建之

kubectl apply -f PV.yaml

通过kubectl get pv查看

[root@master01 ~]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
my-pv   1Gi        RWX            Retain           Available           manual                  39s

可以看到创建成功，并且状态是Available，说明还没有被PVC绑定，注意声明的hostPath并不是只有Master节点才有，所有的节点都有！

Capacity（存储能力）：一般来说，一个 PV 对象都要指定一个存储能力，通过 PV 的 capacity 属性来设置的，目前只支持存储空间的设置，就是我们这里的 storage=1Gi，不过未来可能会加入 IOPS、吞吐量等指标的配置。
AccessModes（访问模式）：用来对 PV 进行访问模式的设置，用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：

  • ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
  • ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
  • ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
    　　可以指定列表：accessModes: ["ReadWriteMany","ReadWriteOnce"]

========创建PVC：再声明一个PVC.yaml，内容如下

这里定义了pvc的访问模式为多路读写，该访问模式必须在前面pv定义的访问模式之中。定义PVC申请的大小为1Gi，此时PVC会自动去匹配多路读写且大小为1Gi的PV，匹配成功获取PVC的状态即为Bound

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

kubectl apply -f PVC.yaml创建之

kubectl apply -f PVC.yaml

通过kubectl get pvc查看

persistentvolumeclaim/my-pvc created
[root@master01 ~]# kubectl get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc   Bound    my-pv    1Gi        RWX            manual         13s
[root@master01 ~]# kubectl get pv
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
my-pv   1Gi        RWX            Retain           Bound    default/my-pvc   manual                  3m36s
[root@master01 ~]#

可以看到PV的状态变成了Bound，说明PV被PVC绑定了（注意：创建 PVC 之后，Kubernetes 就会去查找满足我们声明要求的 PV，如果满足要求就会将 PV 和 PVC 绑定在一起，目前 PV 和 PVC 之间是一对一绑定的关系，也就是说一个 PV 只能被一个 PVC 绑定）

========最后通过如下web-test.yaml声明创建deploy

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web-test
  name: web-test
spec: 
  replicas: 1
  selector: 
    matchLabels:
      app: web-test             
  strategy: {}
  template:                
    metadata:
      labels:
        app: web-test
    spec:                  
      containers:
      - image: nginx:1.14
        name: nginx
        # 挂载到容器内
        volumeMounts:
          - name: wwwroot
            mountPath: /usr/share/nginx/html
      # PVC声明     
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: my-pvc
status: {}

应用：

kubectl apply -f web-test.yaml

此声明将Pod内的/usr/share/nginx/html绑定到主机的/data/hostpath（通过PV声明的），如果此时访问一下nginx会报403 Forbidden错误，因为主机内的/data/hostpath/index.html并没有，先创建一个（注意：Pod在哪个节点上就在哪个节点上创建）

========创建本地路径：（注意：Pod在哪个节点上就在哪个节点上创建）

相关文章：
K8S 存储卷-PV、PVC、NFS 和 StorageClass 深度讲解 (下)
Kubernetes学习之路（十九）存储卷资源

为者常成，行者常至

自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）