在 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:

spec:

containers:

- name: container-empty

image: nginx

volumeMounts:

- mountPath: /cache

volumes:

- emptyDir:

{}

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:

spec:

containers:

- image: nginx

volumeMounts:

- mountPath: /test-nginx

- image: tomcat

volumeMounts:

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

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:

spec:

containers:

- name: test-nfs

image: nginx

ports:

- containerPort: 80

protocol: TCP

volumeMounts:

- mountPath: /usr/share/nginx/html

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

#登录到 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/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 -required-

readOnly

server -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:

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:

spec:

capacity:

storage: 2Gi

accessModes: ["ReadWriteMany"]

nfs:

path: /data/volume_test/v2

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 3Gi

accessModes: ["ReadOnlyMany"]

nfs:

path: /data/volume_test/v3

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 4Gi

accessModes: ["ReadWriteOnce","ReadWriteMany"]

nfs:

path: /data/volume_test/v4

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 5Gi

accessModes: ["ReadWriteOnce","ReadWriteMany"]

nfs:

path: /data/volume_test/v5

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 6Gi

accessModes: ["ReadWriteOnce","ReadWriteMany"]

nfs:

path: /data/volume_test/v6

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 7Gi

accessModes: ["ReadWriteOnce","ReadWriteMany"]

nfs:

path: /data/volume_test/v7

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 8Gi

accessModes: ["ReadWriteOnce","ReadWriteMany"]

nfs:

path: /data/volume_test/v8

server: 192.168.40.130

---

apiVersion: v1

kind: PersistentVolume

metadata:

spec:

capacity:

storage: 9Gi

accessModes: ["ReadWriteOnce","ReadWriteMany"]

nfs:

path: /data/volume_test/v9

server: 192.168.172.163

---

apiVersion: v1

kind: PersistentVolume

metadata:

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:

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:

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

allowedTopologies <[]Object>

mountOptions <[]string>

parameters

provisioner -required-

reclaimPolicy

volumeBindingMode

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:

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:

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:

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:

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:

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

k8s 持久化存储卷

k8s 持久化存储方案:emptyDir

k8s 持久化存储方案:hostPath

k8s 持久化存储方案:NFS

k8s 持久化存储方案: PVC

3、创建 pv

存取模式

k8s 存储类:storageclass

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

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

创建 storageclass，动态供给 pv

你可能感兴趣的:(k8s 持久化存储卷)