k8s之PV、PVC和StorageClass

郑文峰的博客

使用dify对接飞书多维表格使用n8n对接飞书多维表格服务启动时出现 OOM 一次服务升级时pg表DDL执行超时失败 Go语言高效IO缓冲技术详解 Go语言延迟初始化(Lazy Initialization)最佳实践 Go语言字符串拼接性能对比与优化指南 Go语言结构体内存对齐完全指南 Go语言空结构体：零内存消耗的高效编程 Go语言堆栈分配与逃逸分析深度解析 Go语言原子操作完全指南 Go语言内存预分配完全指南 Go语言不可变数据共享：无锁并发编程实践 Go语言零拷贝技术完全指南 Go语言遍历性能深度解析：从原理到优化实践 Go语言Interface Boxing原理与性能优化指南 Go协程池深度解析：原理、实现与最佳实践使用etcd分布式锁导致的协程泄露与死锁问题基于pre-commit的Python代码规范落地实践初识 MCP Server pulsar阻塞导致logstash无法接入日志 django-prometheus使用及源码分析 kube-proxy源码分析 kubernetes service如何通过iptables转发 tcp缓存引起的日志丢失 django-apschedule定时任务异常停止理解calico容器网络通信方案原理理解flannel的三种容器网络方案原理理解Linux IPIP隧道理解VXLAN网络理解Linux TunTap设备快速了解iptables kafka中listener和advertised.listeners的作用 django rest_framework 分页 django后端服务、logstash和flink接入VictoriaMetrics指标监控 python中import原理 docker容器单机网络手动实现docker容器bridge网络模型 mysql之MVCC原理 mysql之日志使用java开发logstash的filter插件使用python实现单例模式的三种方式 redis之缓存 redis之分片集群 redis之哨兵机制 redis之主从库同步 redis之持久化 redis之五种基本数据类型 go中如何处理error pod中将代码与运行环境分离 ddt源码分析 python装饰器的使用方法读书笔记:如何阅读一本书使用ddt实现unittest的参数化测试使用kubeadm安装k8s 优化gin表单的错误提示信息 gin中validator模块的源码分析 go简单使用grpc python简单使用grpc k8s之StatefulSet k8s之DaemonSet k8s之Job和CronJob k8s之ConfigMap和Secret k8s之Service k8s之Pod k8s之Deployment 容器的本质 docker容器 python迭代器与生成器 python元编程 python垃圾回收机制 python上下文管理器 django rest_framework使用jwt django rest_framework异常处理 django rest_framework 自定义文档 django压缩文件下载 django rest_framework使用pytest单元测试 django restframework choice 自定义输出数据 django Filtering 使用 django viewset 和 Router 配合使用时报的错 django model的序列化 django中使用AbStractUser django.core.exceptions.ImproperlyConfigured Application labels aren't unique, duplicates users django 中 media配置 django 外键引用自身和on_delete参数 django 警告 while time zone support is active Flask使用flask_socketio实现websocket flask结合mongo tornado 文件上传 tornado 使用jwt完成用户异步认证 tornado 用户密码 bcrypt加密 tornado 结合wtforms使用表单操作 tornado finish和write区别 tornado 使用peewee-async 完成异步orm数据库操作 pyspark streaming简介和消费 kafka示例使用hue创建ozzie的pyspark action workflow count的性能优化 django rest_framework Authentication django celery 结合使用网站

zhengwenfeng · 2022-08-31 · via 郑文峰的博客

# PV

# 什么是PV？

PV 描述的，则是一个具体的 Volume 的属性，比如 Volume 的类型、挂载目录、远程存储服务器地址等。

# 创建PV

使用yaml来定义PV


apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-1g-pv

spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 1Gi

  nfs:
    path: /root/zwf/share
    server: 10.64.2.153

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

参数说明：

storageClassName的值为nfs，使用了NFS网络文件系统作为存储卷，
accessModes的值为ReadWriteMany，支持多个节点同时读写该共享目录
storage的值为1Gi，分配了1G的存储空间

使用yaml定义的描述文件来创建PV对象

[root@k8s-worker1 zwf]# kubectl apply -f pv.yaml -n zwf
persistentvolume/nfs-1g-pv created
[root@k8s-worker1 zwf]# kubectl get pv -n zwf
NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                           STORAGECLASS   REASON   AGE
nfs-1g-pv   1Gi        RWX            Retain           Available                                   nfs                     12s

1
2
3
4
5

# PVC

# 什么是PVC？

提供给应用开发获取存储资源的对象，开发将pod与PVC进行绑定可以达到持久化的存储状态，而PVC会与相对应的PV相绑定，提供具体的存储空间。

PV和PVC有什么区别？

实际上类似于“接口”和“实现”的思想。开发者只要知道并会使用“接口”，即：PVC；而运维人员则负责给“接口”绑定具体的实现，即：PV。

# 创建PVC

有了pv之后，创建申请存储的PVC对象，yaml定义如下，定义的内容和PV基本相同，但是不包含NFS的存储细节。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-static-pvc

spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany

  resources:
    requests:
      storage: 1Gi

1
2
3
4
5
6
7
8
9
10
11
12
13

创建pvc对象，并且可以看到VOLUME的值是上面创建的pv对象，这样两者就进行绑定了。

[root@k8s-worker1 zwf]# kubectl apply -f pvc.yaml -n zwf
persistentvolumeclaim/nfs-static-pvc created
[root@k8s-worker1 zwf]# 
[root@k8s-worker1 zwf]# kubectl get pvc -n zwf
NAME             STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-static-pvc   Bound    nfs-1g-pv   1Gi        RWX            nfs            9s

1
2
3
4
5
6

我们再pvc文件中并没有填写pv的任何信息，它是如何知道该绑定那个pv对象的呢？这是因为pvc会根据自身需要的容量去找到对应的pv进行匹配绑定。

# 在Pod中申请PVC

Pod的yaml定义如下，使用volumes定义了存储卷使用上面创建的pvc对象nfs-static-pvc，在containers中使用vlumeMounts在pod中挂载了/tmp目录在该存储卷中。


apiVersion: v1
kind: Pod
metadata:
  name: nfs-static-pod

spec:
  volumes:
  - name: nfs-pvc-vol
    persistentVolumeClaim:
      claimName: nfs-static-pvc

  containers:
    - name: nfs-pvc-test
      image: nginx:alpine
      ports:
      - containerPort: 80

      volumeMounts:
        - name: nfs-pvc-vol
          mountPath: /tmp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

创建pod后，我们进入pod中在/tmp写入数据

[root@k8s-worker1 zwf]# kubectl apply -f pod_pvc.yaml -n zwf
pod/nfs-static-pod created

[root@k8s-worker1 zwf]# kubectl exec -it nfs-static-pod -n zwf -- /bin/sh
/ # cd /tmp
/tmp # echo 222 > 2.txt

1
2
3
4
5
6

在nfs服务器中的/root/zwf/share中，我们也可以看到上面写的数据

[root@k8s-worker2 share]# pwd
/root/zwf/share
[root@k8s-worker2 share]# ls
2.txt
[root@k8s-worker2 share]# cat 2.txt
222

1
2
3
4
5
6

Pod、PVC、PV 和 NFS 存储的关系可以用下图来形象地表示：

# StorageClass

上面的PV是需要管理员手动创建的，每一次的开发都需要根据需求逐个创建PV，并且还需要精确创建空间大小，导致工作量巨大。所以我们需要在开发中可以动态的创建PV。

StoreageClass可以用来绑定Provisioner对象，而这个Provisioner就是一个能够自动管理存储、创建 PV 的应用，代替了原来系统管理员的手工劳动。

# 通过StorageClass配置NFS Provisioner

k8s中每一类的存储设备都有相应的Provisioner，这里我们使用的是NFS Provisioner(https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)

在 GitHub 的 deploy 目录里是部署它所需的 YAML 文件，一共有三个，分别是 rbac.yaml、class.yaml和 deployment.yaml。

首先将rbac.yaml的namespace改成kube-system
在修改deployment.yaml的namespace也改为kube-system，再修改其中的volumes 和 env 里的 IP 地址和共享目录名，与NFS服务器保持一致.


spec:
  template:
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
      ...
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 192.168.10.208        #改IP地址
            - name: NFS_PATH
              value: /tmp/nfs              #改共享目录名
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.10.208         #改IP地址
            Path: /tmp/nfs                 #改共享目录名

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

再将k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2改成chronolaw/nfs-subdir-external-provisioner:v4.0.2

最后创建NFS Provisioner

kubectl apply -f rbac.yaml
kubectl apply -f class.yaml
kubectl apply -f deployment.yaml

1
2
3

查看kube-system的pod可以看到nfs的provisioner。

[root@k8s-worker1 zwf]# kubectl get pods -n kube-system
NAME                                      READY   STATUS    RESTARTS      AGE
nfs-client-provisioner-57789d96b7-42q67   1/1     Running   0             22h

1
2
3

# 使用NFS动态存储卷

创建StrogeClass对象，onDelete: "remain"代表着即使Pod被删除，也会保留分配的存储，之后再手动删除。


apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client

provisioner: k8s-sigs.io/nfs-subdir-external-provisioner 
parameters:
  onDelete: "remain"

1
2
3
4
5
6
7
8
9

创建StrageClass对象，并可以看到PROVISIONER已经绑定了我们上面创建的nfs-provisioner了。

[root@k8s-worker1 zwf]# kubectl apply -f pvc_dyn.yaml -n zwf
storageclass.storage.k8s.io/nfs-client-retained created

[root@k8s-worker1 zwf]# kubectl get sc -n zwf
NAME                  PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-client   k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate           false                  21h

1
2
3
4
5
6

定义PVC，配置storageClassName:nfs-client与上面的StrageClass对象相绑定。


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-dyn-10m-pvc

spec:
  storageClassName: nfs-client
  accessModes:
    - ReadWriteMany

  resources:
    requests:
      storage: 10Mi

1
2
3
4
5
6
7
8
9
10
11
12
13
14

创建PVC，然后你会发现STATUS的状态为Bound，已经自动的创建了PV，并且已经相互绑定。

[root@k8s-worker1 zwf]# kubectl get pvc -n zwf
NAME              STATUS    VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-dyn-10m-pvc   Pending                                         nfs-client     25s

[root@k8s-worker1 zwf]# kubectl get pvc -n zwf
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-dyn-10m-pvc   Bound    pvc-292cfed3-bec8-4425-aeac-697e3740c76c   10Mi       RWX            nfs-client     9s

[root@k8s-worker1 zwf]# kubectl get pv -n zwf
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                           STORAGECLASS   REASON   AGE
pvc-292cfed3-bec8-4425-aeac-697e3740c76c   10Mi       RWX            Delete           Bound    zwf/nfs-dyn-10m-pvc             nfs-client              47s

1
2
3
4
5
6
7
8
9
10
11

去NFS文件服务器的共享目录中查看，可以看到多出来了一个目录，目录名称为命名空间-pvc名称-pvc名称

[root@k8s-worker2 share]# pwd
/root/zwf/share
[root@k8s-worker2 share]# ls
zwf-nfs-dyn-10m-pvc-pvc-292cfed3-bec8-4425-aeac-697e3740c76c

1
2
3
4

定义Pod，挂载上面创建的PVC到容器的/tmp目录中

apiVersion: v1
kind: Pod
metadata:
  name: nfs-dyn-pod

spec:
  volumes:
  - name: nfs-dyn-10m-vol
    persistentVolumeClaim:
      claimName: nfs-dyn-10m-pvc

  containers:
    - name: nfs-dyn-test
      image: nginx:alpine

      volumeMounts:
        - name: nfs-dyn-10m-vol
          mountPath: /tmp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

创建Pod成功

[root@k8s-worker1 zwf]# kubectl apply -f pod_strageclass.yaml -n zwf
pod/nfs-dyn-pod created
[root@k8s-worker1 zwf]# kubectl get pods -n zwf
NAME          READY   STATUS    RESTARTS   AGE
nfs-dyn-pod   1/1     Running   0          10s

1
2
3
4
5

进入到挂载了pvc的pod，然后在/tmp目录下写一个文件

kubectl exec -it nfs-dyn-pod -n zwf -- /bin/sh
/ # cd /tmp
/tmp # echo 111 > 3.txt

1
2
3

再到NFS服务器上的共享目录对应的pv目录下，能看到之前写的文件。

[root@k8s-worker2 zwf-nfs-dyn-10m-pvc-pvc-292cfed3-bec8-4425-aeac-697e3740c76c]# pwd
/root/zwf/share/zwf-nfs-dyn-10m-pvc-pvc-292cfed3-bec8-4425-aeac-697e3740c76c

[root@k8s-worker2 zwf-nfs-dyn-10m-pvc-pvc-292cfed3-bec8-4425-aeac-697e3740c76c]# cat 3.txt 
111

1
2
3
4
5

关系图如下：

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

郑文峰的博客

# PV

# 什么是PV？

# 创建PV

# PVC

# 什么是PVC？

# 创建PVC

# 在Pod中申请PVC

# StorageClass

# 通过StorageClass配置NFS Provisioner

# 使用NFS动态存储卷