ConfigMap描述信息
ConfigMap功能在Kubernetes1.2版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中
读取配置信息。ConfigMap API给我们提供了向容器中注入配置信息的机制,ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制的对象
ConfigMap的创建
1、使用目录创建
使用:
[root@k8s-master01 configmap]# ll /data/volume/configmap/dir/
total 8
-rw-r--r-- 1 root root 159 Jun 5 17:50 game.properties
-rw-r--r-- 1 root root 84 Jun 5 17:52 ui.properties
[root@k8s-master01 configmap]# cat ./dir/
game.properties ui.properties
[root@k8s-master01 configmap]# cat ./dir/*
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
kubectl create configmap game-config --from-file=./dir/
2、使用文件创建
kubectl create configmap game-config2 --from-file=./dir/game.properties
3、使用字面值创建
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
Pod中使用ConfigMap
a、使用ConfigMap来替代环境变量
1、先将cm写好(special-config上文、env-config)
kubctl apply -f env-config.yaml
[root@k8s-master01 configmap]# cat env/env-config.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
2、Pod调用环境变量
[root@k8s-master01 configmap]# cat pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: depi-test-pod
spec:
containers:
- name: test-container
image: wangyanglinux/myapp:v1
command: [ "/bin/sh","-c","env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.type
envFrom:
- configMapRef:
name: env-config
restartPolicy: Never
b、用ConfigMap设置命令行参数(延用special-config、env-config)
[root@k8s-master01 configmap]# cat pod1.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod1
spec:
containers:
- name: test-container
image: wangyanglinux/myapp:v1
command: [ "/bin/sh","-c","echo $(SPECIAL_LEVEL_KEY),$(SPECIAL_TYPE_KEY)" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: SPECIAL_TYPE_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.type
restartPolicy: Never
C、通过数据卷插件使用ConfigMap
[root@k8s-master01 configmap]# cat pod2.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod2
spec:
containers:
- name: test-container
image: wangyanglinux/myapp:v1
command: [ "/bin/sh","-c","cat /etc/config/special.how" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
restartPolicy: Never
ConfigMap的热更新
配置文件:
[root@k8s-master01 configmap]# cat configmap.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: log-config
data:
log_level: INFO
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 2
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: wangyanglinux/myapp:v1
ports:
- containerPort: 80
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: log-config
[root@k8s-master01 configmap]# kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-74b5f4d6d8-dc2x4 1/1 Running 0 76s
my-nginx-74b5f4d6d8-llgnb 1/1 Running 0 75s
[root@k8s-master01 configmap]# kubectl exec my-nginx-74b5f4d6d8-dc2x4 -it -- cat /etc/config/log_level
INFO
2、修改ConfigMap
[root@k8s-master01 configmap]# kubectl edit configmap log-config
configmap/log-config edited
[root@k8s-master01 configmap]# kubectl exec my-nginx-74b5f4d6d8-dc2x4 -it -- cat /etc/config/log_level
DEBUG
ConfigMap更新后滚动更新Pod
通过修改pod annotations的方式强制触发滚动更新
kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "2020605" }}}}}'
这个例子在.spec.template.metadata.annotataions中添加version/config,每次通过修改version/config来触发滚动更新
Secret存在意义
Secret解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者Pod Spec中。
Secret可以以Volume或者环境变量的方式使用
Secret有三种类型:
- Service Account:用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的
/run/secret/kubernetes.io/serviceaccount目录中
- Opaque:base64编码格式的Secret,用来存储密码、密钥等
- Kubernetes.io/dockerconfigjson:用来存储私有docker registry的认证信息
Service Account
Opaque Secret
1、创建说明
Opaque类型的数据是一个map类型,要求value是base64编码格式:
[root@k8s-master01 ~]# echo -n "Aa123456" | base64
QWExMjM0NTY=
[root@k8s-master01 ~]# echo -n "admin" | base64
YWRtaW4=
2、yaml文件
---
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: QWExMjM0NTY=
username: YWRtaW4=
使用方式
1、将Secret挂载到Volume中
---
apiVersion: v1
kind: Pod
metadata:
name: secret-test
labels:
name: secret-test
spec:
volumes:
- name: secrets
secret:
secretName: mysecret
containers:
- image: wangyanglinux/myapp:v1
name: db
volumeMounts:
- name: secrets
mountPath: "/etc/secrets"
readOnly: true
2、将Secret导出到环境变量中
[root@k8s-master01 secret]# cat env.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: pod-deployment
labels:
name: secret-test
spec:
replicas: 2
selector:
matchLabels:
app: pod-deployment
template:
metadata:
labels:
app: pod-deployment
spec:
containers:
- name: pod-1
image: wangyanglinux/myapp:v1
ports:
- containerPort: 80
command: [ "/bin/sh","-c","echo $(TEST_USER),$(TEST_PASSWORD)" ]
env:
- name: TEST_USER
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: TEST_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
kubernetes.io/dockerconfigjson
使用kubectl创建docker registry认证的secret
kubectl create secret docker-registry myregistrykey --docker-server=test.k8s.com --docker-username=admin --docker-password=Harbor12345 --docker-email=[eamiladress]
yaml文件:
[root@k8s-master01 secret]# cat reg.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: registry-test
spec:
containers:
- name: registry1
image: test.k8s.com/test/myapp:v2
imagePullSecrets:
- name: myregistrykey
Volume
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet
会重启它,但是容器中的文件将丢失------容器以干净的状态(镜像最初的状态)重新启动。其次,在`Pod`中同时运行多个
容器时,这些容器之间通常需要共享文件。kubernetes中的`Volume`抽象就很好的解决了这些问题
背景
Kubernetes中的卷有明确的寿命----与封装它的Pod相同。所以,卷的生命比Pod中的所有容器都长,当这个容器重启时数据仍然
得以保存。当然,当Pod不在存在时,卷也将不复存在。还有更重要的是,Kubernetes支持多种类型的卷,Pod可以同时使用任意数量的卷
卷的类型:
Kubernetes支持以下类型的卷:
- awsElasticBlockStore、azureDisk、azureFile、cephfs、cinder、configMap、csi
- downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker、gcePersistentDisk
- gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim
- projected、portworxVolume、quobyte、rbd、scaleIO、secret、storageos、vsphereVolume
emptyDir
当Pod被分配给节点时,首先创建`emptyDir`卷,并且只要该Pod在该节点上运行,该卷就会存在。正如卷的
名字所述,它最初是空的。Pod中的容器可以读取和写入`emptyDir`卷中的相同文件,尽管该卷可以挂载到
每个容器中的相同或不同路径上。当出于任何原因从节点中删除Pod时,`emptyDir`中的数据将被永久删除
注:容器崩溃不会从节点中移除pod,因此`emptyDir`卷中的数据在容器崩溃时是安全的
emptyDir的用法有:
- 暂存空间,例如用于基于磁盘的合并排序
- 用作长时间计算崩溃恢复时的检查点
- Web服务器容器提供数据时,保存内容管理器容器提取的文件
[root@k8s-master01 volume]# cat emptydir.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: test-pd1
spec:
containers:
- image: wangyanglinux/myapp:v1
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
- name: liveness-exec-container
image: library/busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","sleep 3600"]
volumeMounts:
- mountPath: /test
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
分别在Pod内查看两个容器
kubectl exec test-pd1 -c liveness-exec-container -it -- /bin/sh
kubectl exec test-pd1 -c test-container -it -- /bin/sh
分别echo内容进目录的同一文件,查看验证
/cache # date >> index.html
/cache # cat index.html
Sat Jun 6 14:57:14 UTC 2020
Sat Jun 6 14:58:08 UTC 2020
Sat Jun 6 15:01:44 UTC 2020
/test # date >> index.html
/test # cat index.html
Sat Jun 6 14:57:14 UTC 2020
Sat Jun 6 14:58:08 UTC 2020
Sat Jun 6 15:01:44 UTC 2020
Sat Jun 6 15:02:15 UTC 2020
hostPath
将主机节点的文件系统中的文件或目录挂载到集群中
hostPath的用途:
- 运行需要访问Docker内部的容器;使用`/var/lib/docker`的`hostPath`
- 在容器中运行CAdvisor;使用/dev/cgroups的hostPath
除了所需的Path属性之外,用户还可以为hostPath卷指定type

使用这种卷类型
- 具有相同配置(例如从 podTemplate 创建)的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
- 当 Kubernetes 按照计划添加资源感知的调度时,这类调度机制将无法考虑由 hostPath 使用的资源。
- 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运行进程,或者修改主机上的文件权限以便容器能够写入 hostPath 卷。
1、在所有node上创建/data目录后再启用yaml
[root@k8s-master01 volume]# cat hostPath.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: wangyanglinux/myapp:v1
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on hots
path: /data
# this field is optional
type: Directory
验证:
在Pod的/test-pd目录下创建文件,然后在node上的/data目录看是否存在;在/data目录里面创建也可在Pod内生效
存储PV和PVC
PV
是由管理员设置的存储,它是集群的一部分。就像节点是集群中的资源一样,PV也是集群中的资源。PV是Volume之类的
卷插件,但具有独立于使用PV的Pod的生命周期。此API对象包含存储实现的细节,即NFS、iSCSI或特定于与供应商的存储系统
PVC
是用户存储的请求。它与Pod相似。Pod消耗节点资源,PVC消耗PV资源。Pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问模式(例如,可以以读/写一次或只读多次模式挂载)
静态
集群管理员创建一些PV。它们带有可供集群用户使用的实际存储的细节。它们存在于Kubernetes API中,可用于消费
动态
当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时,集群可能会尝试动态的为PVC创建卷。此配置基于
StorageClasses:PVC必须请求[存储类],并且管理员必须创建并配置该类才能进行动态创建。声明该类为""可以有效的
禁用其动态配置
要启用基于存储级别的动态存储配置,集群管理员需要启用API server上的DefaultStorageClass[准入控制器]。例如:
通过确保DefaultStorageClass位于API server组件的 --admission-control标志,使用逗号分隔的有序值列表中,
可以完成此操作
绑定
master中的控制环路监视新的PVC,寻找匹配的PV(如果可能),并将它们绑定在一起。如果为新的PVC动态调配PV,
则该环路将始终将PV绑定到PVC。否则,用户总会得到他们所请求的存储,但是容量可能超出要求的数量。一旦PV和PVC
绑定后,PersistentVolumeClaim绑定是排他性的,不管它们是如何绑定的。PVC跟PV绑定是一对一的映射
使用中保护 Storage Object in Use Protection
使用中保护(Storage Object in Use Protection)的目的是确保正在被容器组使用的 PersistentVolumeClaim 以及其绑定的 PersistentVolume 不能被系统删除,以避免可能的数据丢失。
如果用户删除一个正在使用中的 PersistentVolumeClaim,则该 PVC 不会立即被移除掉,而是推迟到该 PVC 不在被任何容器组使用时才移除;同样的如果管理员删除了一个已经绑定到 PVC 的 PersistentVolume,则该 PV 也不会立刻被移除掉,而是推迟到其绑定的 PVC 被删除后才移除掉。
存储卷类型
Kubernetes 支持 20 种存储卷类型(可参考 Types of Persistent Volumes),如下所示:
- 非持久性存储
- emptyDir
- HostPath (只在单节点集群上用做测试目的)
- 网络连接性存储
- SAN:iSCSI、ScaleIO Volumes、FC (Fibre Channel)
- NFS:nfs,cfs
- 分布式存储
- Glusterfs
- RBD (Ceph Block Device)
- CephFS
- Portworx Volumes
- Quobyte Volumes
- 云端存储
- GCEPersistentDisk
- AWSElasticBlockStore
- AzureFile
- AzureDisk
- Cinder (OpenStack block storage)
- VsphereVolume
- StorageOS
- 自定义存储
- FlexVolume
- 不推荐
- Flocker (最近更新2016年 https://github.com/ClusterHQ/flocker/)
PV访问模式
PV可以以资源提供者支持的任何方式挂载到主机上,如下表所示,供应商具有不同的功能,每个PV的访问模式都将被设置为该卷支持
的特定模式。例如,NFS可以支持多个读/写客户端,但特定的NFS PV可能以只读方式导出到服务器上。每个PV都有一套自己的用来
描述特定功能的访问模式
- 可被单节点读写-ReadWriteOnce
- 可被多节点只读-ReadOnlyMany
- 可被多节点读写-ReadWriteMany
Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
AWSElasticBlockStore | ✓ | - | - |
AzureFile | ✓ | ✓ | ✓ |
AzureDisk | ✓ | - | - |
CephFS | ✓ | ✓ | ✓ |
Cinder | ✓ | - | - |
CSI | depends on the driver | depends on the driver | depends on the driver |
FC | ✓ | ✓ | - |
FlexVolume | ✓ | ✓ | depends on the driver |
Flocker | ✓ | - | - |
GCEPersistentDisk | ✓ | ✓ | - |
Glusterfs | ✓ | ✓ | ✓ |
HostPath | ✓ | - | - |
iSCSI | ✓ | ✓ | - |
Quobyte | ✓ | ✓ | ✓ |
NFS | ✓ | ✓ | ✓ |
RBD | ✓ | ✓ | - |
VsphereVolume | ✓ | - | - (works when Pods are collocated) |
PortworxVolume | ✓ | - | ✓ |
ScaleIO | ✓ | ✓ | - |
StorageOS | ✓ | - | - |
回收策略
- 保留 Retain – 手工回收
- 再利用 Recycle – 清除后重新可用 (rm -rf /thevolume/*)
- 删除 Delete – 删除 PV 及存储介质
状态
卷可以处于以下的某种状态:
- Available – 可用的 PV,尚未绑定到 PVC
- Bound – 已经绑定到 PVC
- Released – PVC 已经被删除,但是资源还未被集群回收
- Failed – 自动回收失败
持久化演示:
1、安装NFS服务器(harbor上安装)
yum install -y nfs-common nfs-utils rpcbind
mkdir /nfsdata
chmod 666 /nfsdata/
chown nfsnobody /nfsdata/
cat /etc/exports
/nfsdata *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl enable rpcbind
systemctl start nfs
systemctl enable nfs
2、安装NFS客户端(所有节点)
yum install -y nfs-utils rpcbind
验证是否可用
showmount -e
mount -t nfs 192.168.137.198:/nfsdata /data/test
vim /data/test/1.html
umount -lf /data/test/
2、部署PV
[root@k8s-master01 pv]# cat pv2.yaml
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv2
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /nfsdata1
server: 192.168.137.198
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv3
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /nfsdata2
server: 192.168.137.198
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv4
spec:
capacity:
storage: 1Gi
volumeMode: Filesystem
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /nfsdata3
server: 192.168.137.198
[root@k8s-master01 pv]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfspv1 10Gi RWO Recycle Bound default/www-web-0 nfs 45m
nfspv2 5Gi ROX Recycle Available nfs 30m
nfspv3 5Gi RWX Recycle Available slow 30m
nfspv4 1Gi ROX Recycle Available nfs 30m
创建服务并启用pvc
[root@k8s-master01 pv]# cat pvc.yaml
---
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: wangyanglinux/myapp:v2
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "nfs"
resources:
requests:
storage: 1Gi
创建完成后会发现:处于Pending状态
[root@k8s-master01 pv]# kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 7m1s
web-1 0/1 Pending 0 6m54s
kubectl describe web-1
…
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 3s (x8 over 8m43s) default-scheduler running "VolumeBinding" filter plugin for pod "web-1": pod has unbound immediate PersistentVolumeClaims
查看原因为:只有一个pv的mode是RWO
将pv重新创建 将storageclass和access modes 修改后即可使用

关于statefulset有下面几点说明:
pod的名称为<statefulset名称>-<序列号>,序列号为0到n-1
headless service为每个pod创建了一个独立的域名,格式为<pod_name>.<headless_service_name>.NAMESPACE.svc.cluster.local
pvc的命名规则为<pvc_name>-<pod_name>
删除pod不会删除其pvc,手动删除pvc会自动删除pv
彻底删除
不管是删除pod还是statefulset,持久化的数据都不会消失。那么如果有一天真的想彻底销毁这些数据该如何操作呢?
首先删除statefulset,直接利用yaml文件即可
[root@k8s-master pv]# kubectl delete -f pvc.yaml
service "nginx" deleted
statefulset.apps "web" deleted
[root@k8s-master pv]# kubectl get pod
No resources found.
[root@k8s-master pv]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
但是此时pv和pvc都还在
[root@k8s-master pv]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
test-pv-nfs1 5Gi RWO Retain Bound default/www-test-statefulset-1 gold 8h
test-pv-nfs2 8Gi RWO Retain Bound default/www-test-statefulset-2 gold 8h
test-pv-nfs3 10Gi RWO Retain Bound default/www-test-statefulset-0 gold 8h
[root@k8s-master pv]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
www-web-0 Bound nfspv4 2Gi RWO nfs 66m
www-web-1 Bound nfspv3 5Gi RWO nfs 66m
www-web-2 Bound nfspv1 10Gi RWO nfs 66m
然后删除pvc,之后pv变为Released状态
[root@k8s-master pv]# kubectl delete pvc --all
persistentvolumeclaim "www-web-0" deleted
persistentvolumeclaim "www-web-1" deleted
persistentvolumeclaim "www-web-2" deleted
[root@k8s-master01 pv]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfspv1 10Gi RWO Recycle Available nfs 71m
nfspv2 5Gi ROX Recycle Available nfs 71m
nfspv3 5Gi RWO Recycle Available nfs 67m
nfspv4 2Gi RWO Recycle Available nfs 67m
若此时这些pv还不能变为Available,需要手动删除pv中的pvc信息,也就是claimRef部分
[root@k8s-master pv]# kubectl edit pv/test-pv-nfs1
persistentvolume/test-pv-nfs1 edited
[root@k8s-master pv]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
test-pv-nfs1 5Gi RWO Retain Available gold 8h
test-pv-nfs2 8Gi RWO Retain Released default/www-test-statefulset-2 gold 8h
test-pv-nfs3 10Gi RWO Retain Released default/www-test-statefulset-0 gold 8h
依次删除3个pv中的pvc信息一直到都为Available状态
[root@k8s-master pv]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfspv1 10Gi RWO Recycle Available nfs 164m
nfspv2 5Gi ROX Recycle Available nfs 164m
nfspv3 5Gi RWO Recycle Available nfs 160m
nfspv4 2Gi RWO Recycle Available nfs 160m
Comments NOTHING