在 k8s 中为什么要做持久化存储?

在 k8s 中部署的应用都是以 pod 容器的形式运行的，假如我们部署 MySQL、Redis 等数据库，需

要对这些数据库产生的数据做备份。因为 Pod 是有生命周期的，如果 pod 不挂载数据卷，那 pod 被删 除或重启后这些数据会随之消失，如果想要长久的保留这些数据就要用到 pod 数据持久化存储。

k8s 持久化存储方案:emptyDir

kubectl explain pods.spec.volumes

常用如下

emptyDir

hostPath

nfs persistentVolumeClaim glusterfs

cephfs configMap secret

我们想要使用存储卷，需要经历如下步骤

1、定义 pod 的 volume，这个 volume 指明它要关联到哪个存储上的 

2、在容器中要使用 volume mounts 挂载对应的存储

  经过以上两步才能正确的使用存储卷

emptyDir 类型的 Volume 是在 Pod 分配到 Node 上时被创建，Kubernetes 会在 Node 上自动 分配一个目录，因此无需指定宿主机 Node 上对应的目录文件。 这个目录的初始内容为空，当 Pod 从 Node 上移除时，emptyDir 中的数据会被永久删除。emptyDir Volume 主要用于某些应用程序无需永 久保存的临时目录，多个容器的共享目录等。

#创建一个 pod，挂载临时目录 emptyDir

cat emptydir.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-empty

spec:

  containers:

  - name: container-empty

    image: nginx

    volumeMounts:

    - mountPath: /cache

      name: cache-volume

  volumes:

  - emptyDir:

      {}

    name: cache-volume

kubectl apply -f emptydir.yaml

kubectl get pods -o wide | grep empty

#查看 pod 的 uid

kubectl get pods pod-empty -o yaml | grep uid

uid: ff865494-205a-4318-b8bc-072de1d8ea6f

工作节点看挂载目录

由上可知，临时目录在本地的/var/lib/kubelet/pods/ff865494-205a-4318-b8bc-072de1d8ea6f/volumes/kubernetes.io~empty-dir/cache-volume/下

k8s 持久化存储方案:hostPath

hostPath Volume 是指 Pod 挂载宿主机上的目录或文件。 hostPath Volume 使得容器可以使用 宿主机的文件系统进行存储，hostpath(宿主机路径):节点级别的存储卷，在 pod 被删除，这个存储 卷还是存在的，不会被删除，所以只要同一个 pod 被调度到同一个节点上来，在 pod 被删除重新被调度 到这个节点之后，对应的数据依然是存在的。

kubectl explain pods.spec.volumes.hostPath

FIELDS:

path -required-

type

tomcat.tar.gz  上传到工作节点

#创建一个 pod，挂载 hostPath 存储卷

如果文档里有#号注释复制的时候会乱.  vim打开的时候加:set paste就不会乱了

,

cat hostpath.yaml

 apiVersion: v1

kind: Pod

metadata:

  name: test-hostpath

spec:

  containers:

  - image: nginx

    name: test-nginx

    volumeMounts:

    - mountPath: /test-nginx

      name: test-volume

  - image: tomcat

    name: test-tomcat

    volumeMounts:

    - mountPath: /test-tomcat        #挂载到容器内目录

      name: test-volume

  volumes:

  - name: test-volume

    hostPath:

      path: /data1                        #挂载到节点目录

      type: DirectoryOrCreate    

# DirectoryOrCreate 表示本地有/data1 目录，就用本地的，本地没有就会在 pod 调度到的节点 自动创建一个

 kubectl apply -f hostpath.yaml

#查看 pod 调度到了哪个物理节点

kubectl get pods -o wide | grep hostpath

在 god62 上的/data1 下创建一个目录

# mkdir -p /data1/god

#测试存储卷是否可以正常使用,登录到 nginx 容器

kubectl exec -it test-hostpath -c test-nginx -- /bin/bash

#测试存储卷是否可以正常使用,登录到 tomcat 容器

kubectl exec -it test-hostpath -c test-tomcat -- /bin/bash root@test-hostpath:/usr/local/tomcat# cd /test-tomcat/ #/test-tomcat/目录存在，说明已经把宿主机目录挂载到了容器里 root@test-hostpath:/test-tomcat# ls

#通过上面测试可以看到，同一个 pod 里的 test-nginx 和 test-tomcat 这两个容器是共享存储卷 的。

hostpath 存储卷缺点:

单节点

pod 删除之后重新创建必须调度到同一个 node 节点，数据才不会丢失

可以用分布式存储: nfs，cephfs，glusterfs

k8s 持久化存储方案:NFS

hostPath 存储，存在单点故障，pod 挂载 hostPath 时，只有调度到同一个节点，数据 才不会丢失。那可以使用 nfs 作为持久化存储。

1、搭建 nfs 服务

#以 k8s 的控制节点作为 NFS 服务端

yum install nfs-utils -y 

#在宿主机创建 NFS 需要的共享目录

 mkdir /data/volumes -pv 

mkdir: created directory ‘/data’

mkdir: created directory ‘/data/volumes’

#配置 nfs 共享服务器上的/data/volumes 目录 

# systemctl start nfs 

# vim /etc/exports 

/data/volumes  192.168.1.0/24(rw,no_root_squash) 

#no_root_squash: 用户具有根目录的完全管理访问权限 #使 NFS 配置生效

# exportfs -arv

exporting 192.168.172.0/24:/data/volumes

]# service nfs start

Redirecting to /bin/systemctl start nfs.service 

#设置成开机自启动

]# systemctl enable nfs

#查看 nfs 是否启动成功

systemctl status nfs Active: active

看到 nfs 是 active，说明 nfs 正常启动了 #god62 和 god64 上也安装 nfs 驱动 

yum install nfs-utils -y

service nfs start && systemctl enable nfs

在 god62 上手动挂载试试:

mount -t nfs 192.168.172.63:/data/volumes /data1

df -h 看一哈

#手动卸载:

 umount /data1/

#创建 Pod，挂载 NFS 共享出来的目录

cat nfs.yaml

apiVersion: v1

kind: Pod

metadata:

  name: test-nfs-volume

spec:

  containers:

  - name: test-nfs

    image: nginx

    ports:

    - containerPort: 80

      protocol: TCP

    volumeMounts:

    - mountPath: /usr/share/nginx/html

      name: nfs-volumes

  volumes:

  - name: nfs-volumes

    nfs:

      server: 192.168.172.163

      path:  /data/volumes

注:path: /data/volumes #nfs 的共享目录

server:192.168.172.63 是 god63 机器的 ip，这个是安装 nfs 服务的地址

kubectl get pods -o wide | grep nfs

test-nfs-volume        1/1    Running    0          59s    10.244.187.124  god62  <none>          <no

#登录到 nfs 服务器(master)，在共享目录创建一个 index.html

cd /data/volumes/

echo "hello,welcome to pod" > inde.html

curl 10.244.187.124

hello,welcome to pod

#通过上面可以看到，在共享目录创建的 index.html 已经被 pod 挂载了

#登录到 pod 验证下

# kubectl exec -it test-nfs-volume -- /bin/bash root@test-nfs-volume:/# cat /usr/share/nginx/html/index.html

hello, Welcome to pod

 #上面说明挂载 nfs 存储卷成功了，nfs 支持多个客户端挂载，可以创建多个 pod，挂载同一个 nfs 服务器共享出来的目录;但是 nfs 如果宕机了，数据也就丢失了，所以需要使用分布式存储，常见的分布 式存储有 glusterfs 和 cephfs

k8s 持久化存储方案: PVC

参考官网：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

k8s PV 是什么? 

PersistentVolume(PV)是群集中的一块存储，由管理员配置或使用存储类动态配置。 它是集群中的资源，就像 pod 是 k8s 集群资源一样。 PV 是容量插件，如 Volumes，其生命周期独立于使用 PV 的任何单个 pod。

k8s PVC 是什么?

PersistentVolumeClaim(PVC)是一个持久化存储卷，我们在创建 pod 时可以定义这个类型的存储卷。 它类似于一个 pod。 Pod 消耗节点资源，PVC 消耗 PV 资源。 Pod 可以请求特定级别的资源 (CPU 和内存)。 pvc 在申请 pv 的时候也可以请求特定的大小和访问模式(例如，可以一次读写或多次 只读)。

k8s PVC 和 PV 工作原理

PV 是群集中的资源。 PVC 是对这些资源的请求。

 PV 和 PVC 之间的相互作用遵循以下生命周期:

(1)pv 的供应方式 可以通过两种方式配置 PV:静态或动态。

静态的:

集群管理员创建了许多 PV。它们包含可供群集用户使用的实际存储的详细信息。它们存在于Kubernetes API 中，可供使用。

动态的:

当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，群集可能会尝试为 PVC 专门动态配置卷。此配置基于 StorageClasses，PVC 必须请求存储类，管理员必须创建并配置该类，以便 进行动态配置。

2)绑定

用户创建 

pvc 并指定需要的资源和访问模式。在找到可用 pv 之前，pvc 会保持未绑定状态

3)使用

a)需要找一个存储服务器，把它划分成多个存储空间;

b)k8s 管理员可以把这些存储空间定义成多个 pv;

c)在 pod 中使用 pvc 类型的存储卷之前需要先创建 pvc，通过定义需要使用的 pv 的大小和对应 的访问模式，找到合适的 pv;

d)pvc 被创建之后，就可以当成存储卷来使用了，我们在定义 pod 时就可以使用这个 pvc 的存 储卷

e)pvc 和 pv 它们是一一对应的关系，pv 如果被 pvc 绑定了，就不能被其他 pvc 使用了; f)我们在创建 pvc 的时候，应该确保和底下的 pv 能绑定，如果没有合适的 pv，那么 pvc 就会 处于 pending 状态。

4)回收策略

当我们创建 pod 时如果使用 pvc 做为存储卷，那么它会和 pv 绑定，当删除 pod，pvc 和 pv 绑定

就会解除，解除之后和 pvc 绑定的 pv 卷里的数据需要怎么处理，目前，卷可以保留，回收或删除: Retain

Recycle (不推荐使用，1.15 可能被废弃了) Delete

1、Retain

当删除 pvc 的时候，pv 仍然存在，处于 released 状态，但是它不能被其他 pvc 绑定使用，里面的 数据还是存在的，当我们下次再使用的时候，数据还是存在的，这个是默认的回收策略

Delete

删除 pvc 时即会从 Kubernetes 中移除 PV，也会从相关的外部设施中删除存储资产

创建 pod，使用 pvc 作为持久化存储卷 

1、创建 nfs 共享目录

#在宿主机创建 NFS 需要的共享目录

# mkdir /data/volume_test/v{1,2,3,4,5,6,7,8,9,10} -p

#配置 nfs 共享宿主机上的/data/volume_test/v1..v10 目录

cat /etc/exports

/data/volumes 192.168.172.0/24(rw,no_root_squash)

/data/volumes 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v1 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v2 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v3 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v4 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v5 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v6 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v7 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v8 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v9 192.168.172.0/24(rw,no_root_squash)

/data/volume_test/v10 192.168.172.0/24(rw,no_root_squash)

# 冒号替换一下保存

:1,$s/192.168.1.0/192.168.172.0/g

#重新加载配置，使配置成效

exportfs -arv

systemctl restart nfs

#查看定义 pv 需要的字段

kubectl explain pv.spec.nfs

path <string> -required-

readOnly <boolean>

server <string> -required-

3、创建 pv

存取模式

PersistentVolume可以通过资源提供者支持的任何方式安装在主机上。如下表所示，提供商将具有不同的功能，并且每个PV的访问模式都将设置为该特定卷支持的特定模式。例如，NFS可以支持多个读/写客户端，但是特定的NFS PV可能以只读方式在服务器上导出。每个PV都有自己的一组访问模式，用于描述该特定PV的功能。

访问方式为：

ReadWriteOnce-可以通过单个节点以读写方式安装该卷

ReadOnlyMany-该卷可以被许多节点只读挂载

ReadWriteMany-该卷可以被许多节点读写安装

在CLI中，访问模式缩写为：

RWO-ReadWriteOnce

ROX-ReadOnlyMany

RWX-ReadWriteMany

重要的！即使一次卷支持多个卷，也只能一次使用一种访问模式挂载该卷。例如，GCEPersistentDisk可以由单个节点安装为ReadWriteOnce，也可以由多个节点安装为ReadOnlyMany，但不能同时安装。

cat pv.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

  name: v1

spec:

  capacity:

    storage: 1Gi    #pv的存储空间容量 

  accessModes: ["ReadWriteOnce"]

  nfs:

    path: /data/volume_test/v1 #把nfs的存储空间创建成pv

    server: 192.168.172.163    #nfs服务器的地址

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v2

spec:

  capacity:

      storage: 2Gi

  accessModes: ["ReadWriteMany"]

  nfs:

    path: /data/volume_test/v2

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v3

spec:

  capacity:

      storage: 3Gi

  accessModes: ["ReadOnlyMany"]

  nfs:

    path: /data/volume_test/v3

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v4

spec:

  capacity:

      storage: 4Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v4

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v5

spec:

  capacity:

      storage: 5Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v5

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v6

spec:

  capacity:

      storage: 6Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v6

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v7

spec:

  capacity:

      storage: 7Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v7

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v8

spec:

  capacity:

      storage: 8Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v8

    server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v9

spec:

  capacity:

      storage: 9Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v9

    server: 192.168.172.163

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name:  v10

spec:

  capacity:    #pv的存储空间容量

      storage: 10Gi

  accessModes: ["ReadWriteOnce","ReadWriteMany"]

  nfs:

    path: /data/volume_test/v10  #把nfs的存储空间创建成pv

    server: 192.168.172.163

---

#更新资源清单文件

]# kubectl apply -f pv.yaml

#查看 pv 资源

#STATUS 是 Available，表示 pv 是可用的

创建 pvc，和符合条件的 pv 绑定

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: my-pvc

spec:

  accessModes: ["ReadWriteMany"]

  resources:

    requests:

      storage: 2Gi

kubectl apply -f pvc.yaml

#查看 pv 和 pvc

# kubectl get pv

#STATUS是Bound，表示这个pv已经被my-pvc绑定了

kubectl get pvc

NAME    STATUS  VOLUME  CAPACITY  ACCESS MODES  STORAGECLASS  AGE

my-pvc  Bound         v2      2Gi        RWX                          2m25s

#. pvc 的名字-绑定到 pv-绑定的是 v2 这个 pv-pvc 可使用的容量是 2G#

5、创建 pod，挂载 pvc

cat pod_pvc.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-pvc

spec:   

  containers:

  - name: nginx

    image: nginx

    volumeMounts:

    - name: nginx-html

      mountPath: /usr/share/nginx/html

  volumes:

  - name: nginx-html

    persistentVolumeClaim:

      claimName: my-pvc

kubectl get pods | grep pod-pvc

pod-pvc                1/1    Running    0          71s

#通过上面可以看到 pod 处于 running 状态，正常运行

注:使用 pvc 和 pv 的注意事项

1、我们每次创建 pvc 的时候，需要事先有划分好的 pv，这样可能不方便，那么可以在创建 pvc 的 时候直接动态创建一个 pv 这个存储类，pv 事先是不存在的

2、pvc 和 pv 绑定，如果使用默认的回收策略 retain，那么删除 pvc 之后，pv 会处于 released 状 态，我们想要继续使用这个 pv，需要手动删除 pv，kubectl delete pv pv_name，删除 pv，不会删除 pv 里的数据，当我们重新创建 pvc 时还会和这个最匹配的 pv 绑定，数据还是原来数据，不会丢失。

k8s 存储类:storageclass

上面介绍的 PV 和 PVC 模式都是需要先创建好 PV，然后定义好 PVC 和 pv 进行一对一的 Bond， 但是如果 PVC 请求成千上万，那么就需要创建成千上万的 PV，对于运维人员来说维护成本很高， Kubernetes 提供一种自动创建 PV 的机制，叫 StorageClass，它的作用就是创建 PV 的模板。k8s 集 群管理员通过创建 storageclass 可以动态生成一个存储卷 pv 供 k8s pvc 使用。

每个 StorageClass 都包含字段 provisioner，parameters 和 reclaimPolicy。

具体来说，StorageClass 会定义以下两部分:

1、PV 的属性 ，比如存储的大小、类型等;

2、创建这种 PV 需要使用到的存储插件，比如 Ceph、NFS 等

有了这两部分信息，Kubernetes 就能够根据用户提交的 PVC，找到对应的 StorageClass，然后 Kubernetes 就会调用 StorageClass 声明的存储插件，创建出需要的 PV。

kubectl explain storageclass

allowVolumeExpansion <boolean>

allowedTopologies <[]Object>

mountOptions <[]string>

parameters <map[string]string>

provisioner <string> -required-

reclaimPolicy <string>

volumeBindingMode <string>

provisioner:供应商，storageclass 需要有一个供应者，用来确定我们使用什么样的存储来创 建 pv，常见的 provisioner 如下

(https://kubernetes.io/zh/docs/concepts/storage/storage-classes/):

provisioner 既可以由内部供应商提供，也可以由外部供应商提供，如果是外部供应商可以参考 https://github.com/kubernetes-incubator/external-storage/下提供的方法创建。

以 NFS 为例，要想使用 NFS，我们需要一个 nfs-client 的自动装载程序，称之为 provisioner，这 个程序会使用我们已经配置好的 NFS 服务器自动创建持久卷，也就是自动帮我们创建 PV。

reclaimPolicy:回收策略

allowVolumeExpansion:允许卷扩展，PersistentVolume 可以配置成可扩展。将此功能设置为

true 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。当基础存储类的 allowVolumeExpansion 字段设置为 true 时，以下类型的卷支持卷扩展。

注意:此功能仅用于扩容卷，不能用于缩小卷。

安装 nfs provisioner，用于配合存储类动态生成 pv

#把 nfs-provisioner-v1.tar.gz 工作节点上上，手动解压

1、创建运行 nfs-provisioner 需要的 sa 账号

cat serviceaccount.yaml

apiVersion: v1

kind: ServiceAccount

metadata:

  name: nfs-provisioner

kubectl apply -f serviceaccount.yaml

what.   sa?

sa 的全称是 serviceaccount。

serviceaccount 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的。指定了 serviceaccount 之后，我们把 pod 创建出来了，我们在使用这个 pod 时，这个 pod 就 有了我们指定的账户的权限了。

2、对 sa 授权

#kubectl create clusterrolebinding nfs-provisioner --clusterrole=cluster-admin --serviceaccount=default:nfs-provisioner

3、k8s1.20 版本通过 nfs provisioner 动态生成 pv 会报错

Unexpected error getting claim reference to claim "default/test-claim1": selfLink was empty, can't make reference，报错原因是 1.20 版本仅用了 selfLink，解决方法如下;

vim /etc/kubernetes/manifests/kube-apiserver.yaml

在这里:

spec:

containers: - command:

- kube-apiserver 添加这一行:

- --feature-gates=RemoveSelfLink=false

然后应用它，即可:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

二进制安装的 k8s，按如下修改:

vi /etc/systemd/system/kube-apiserver.service

--feature-gates=RemoveSelfLink=false \

--v=2

systemctl datemon-reload

systemctl restart apiserver

4、安装 nfs-provisioner 程序

# mkdir /data/nfs_pro -p

#把/data/nfs_pro 变成 nfs 共享的目录

cat /etc/exports

/data/nfs_pro 192.168.172.0/24(rw,no_root_squash)

#exportfs -arv

systemctl restart nfs

cat nfs-deployment.yaml

kind: Deployment

apiVersion: apps/v1

metadata:

  name: nfs-provisioner

spec:

  selector:

    matchLabels:

      app: nfs-provisioner

  replicas: 1

  strategy:

    type: Recreate

  template:

    metadata:

      labels:

        app: nfs-provisioner

    spec:

      serviceAccount: nfs-provisioner

      containers:

        - name: nfs-provisioner

          image: registry.cn-hangzhou.aliyuncs.com/god/nfs-client-provisioner:v1

          volumeMounts:

            - name: nfs-client-root

              mountPath: /persistentvolumes

          env:

            - name: PROVISIONER_NAME

              value: example.com/nfs           #提供人表示提供人的类型。

            - name: NFS_SERVER

              value: 192.168.172.163

            - name: NFS_PATH

              value: /data/nfs_pro/

      volumes:

        - name: nfs-client-root

          nfs:

            server: 192.168.172.163

            path: /data/nfs_pro/

kubectl apply -f nfs-deployment.yaml

1,$s/文档内容/替换内容/g

#查看 nfs-provisioner 是否正常运行

kubectl get pods | grep nfs

nfs-provisioner-6cb84f5d49-nwvtj  1/1    Running    0          22s

创建 storageclass，动态供给 pv

cat nfs-storageclass.yaml

apiVersion: storage.k8s.io/v1

kind:  StorageClass

metadata:

  name: nfs

provisioner: example.com/nfs

kubectl apply -f nfs-storageclass.yaml

#查看 storageclass 是否创建成功

kubectl get storageclass

NAME  PROVISIONER      RECLAIMPOLICY  VOLUMEBINDINGMODE  ALLOWVOLUMEEXPANSION  AGE

nfs    example.com/nfs  Delete          Immediate          false                  2s

注意:provisioner 处写的 example.com/nfs 应该跟安装 nfs provisioner 时候的 env 下的 PROVISIONER_NAME 的 value 值保持一致，如下:

env:

- name: PROVISIONER_NAME 

   value: example.com/nfs

创建 pvc，通过 storageclass 动态生成 pv

cat claim.yaml

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

  name: test-claim1

  annotations:

    volume.beta.kubernetes.io/storage-class: "nfs"

spec:

  accessModes:  ["ReadWriteMany"]

  resources:

    requests:

      storage: 1Gi

  storageClassName:  nfs

kubectl apply -f claim.yaml

#查看是否动态生成了 pv，pvc 是否创建成功，并和 pv 绑定

kubectl get pvc

NAME          STATUS  VOLUME                                    CAPACITY  ACCESS MODES  STORAGECLASS  AGE

my-pvc        Bound    v2                                        2Gi        RWX                          22h

test-claim1  Bound    pvc-b03288b7-13f8-4e6d-aba7-ff6d23a5c500  1Gi        RWX            nfs            7m16s

#通过上面可以看到 test-claim1 的 pvc 已经成功创建了，绑定的 pv 是 pvc-b03288b7-13f8-4e6d-aba7-ff6d23a5c500，这个 pv 是由 storageclass 调用 nfs provisioner 自动生成的。

总结:

1、供应商:创建一个 nfs provisioner

2、创建 storageclass，storageclass 指定刚才创建的供应商 

3、创建 pvc，这个 pvc 指定 storageclass

创建 pod，挂载 storageclass 动态生成的 pvc:test-claim1

cat read-pod.yaml

apiVersion: v1

kind: Pod

metadata:

  name: read-pod

spec:

  containers:

  - name: read-pod

    image: nginx

    volumeMounts:

      - name: nfs-pvc

        mountPath: /usr/share/nginx/html

  restartPolicy:

  volumes:

    - name: nfs-pvc

      persistentVolumeClaim:

        claimName: test-claim1

#查看 pod 是否创建成功

kubectl get pods | grep read

read-pod                          1/1    Running    0          29s