目录
一、statfulset
StatefulSet 管理了基于相同容器定义的一组 Pod。但和 Deployment 不同的是，StatefulSet 为每个 Pod 维护了一个固定的 ID。这些 Pod 是基于相同的声明来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
① 稳定的、唯一的网络标识符，即Pod重新调度后其PodName和HostName不变（当然IP是会变的）
② 稳定的、持久的存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC实现
③ 有序的、优雅的部署和缩放
④ 有序的、自动的滚动更新
-
cat statefulset.yaml
-
apiVersion: v1
-
kind: Service
-
metadata:
-
name: nginx
-
labels:
-
app: nginx
-
spec:
-
ports:
-
- port:
80
-
name: http
-
clusterIP: None
-
selector:
-
app: nginx
-
---
-
apiVersion: apps/v1
-
kind: StatefulSet
-
metadata:
-
name: web
-
spec:
-
selector:
-
matchLabels:
-
app: nginx # has
to match .spec.template.metadata.labels
-
serviceName:
"nginx"
-
replicas:
3 #
by
default
is
1
-
template:
-
metadata:
-
labels:
-
app: nginx # has
to match .spec.selector.matchLabels
-
spec:
-
terminationGracePeriodSeconds:
10 默认
30秒
-
containers:
-
- name: nginx
-
image: registry.cn-beijing.aliyuncs.com/google_registry/nginx:
1.17
-
ports:
-
- containerPort:
80
-
name: http
-
-
kubectl apply -f statefulset.yml
1.创建顺序
在下面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序创建三个 Pod。在 web-0 进入 Running 和 Ready 状态前不会创建 web-1。在 web-1 进入 Running 和 Ready 状态前不会创建 web-2。
如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未创建，在此期间发生了 web-0 运行失败，那么 web-2 将不会被创建，要等到 web-0 创建完成并进入 Running 和 Ready 状态后，才会创建 web-2。
2.收缩顺序
如果想将示例中的 StatefulSet 收缩为 replicas=1，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除；但web-1 尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1
二、PV PVC
-
apiVersion: v1
-
kind: PersistentVolume 持久化存储卷
-
metadata:
-
name: pv0003
-
spec:
-
capacity: 指定容量
-
storage:
5Gi
-
volumeMode: Filesystem 挂载模式，可选，包含filesystem和block
-
accessModes: 访问模式
-
- ReadWriteOnce
-
persistentVolumeReclaimPolicy: Recycle 挥手策略
-
storageClassName: slow 存储类别
-
mountOptions:
-
挂载参数,将PV挂载到Node时，根据后端存储特点，需要设置挂载参数时，可使用此项
-
-
- hard
-
- nfsvers=
4.1
-
nfs:
-
path: /tmp
-
server: 主机ip NFS服务器
accessModes：PersistentVolume(PV)指定特殊的访问模式，NFS可以支持多个读/写客户端，但是特定的NFS PV可能以只读方式在服务器上导出。每个PV都有自己的一组访问模式，用于描述该特定PV的功能。
① ReadWriteOnce-该卷可以被单个节点以读写方式挂载
② ReadOnlyMany-该卷可以被许多节点以只读方式挂载
③ ReadWriteMany-该卷可以被多个节点以读写方式挂载
在CLI命令行中，访问模式缩写为
RWO-ReadWriteOnce
ROX-ReadOnlyMany
RWX-ReadWriteMany
同时一个卷一次只能使用一种访问模式挂载，即使它支持多种访问模式。
storageClassName：PV可以有一个类，通过将storageClassName属性设置为一个StorageClass的名称来指定这个类。特定类的PV只能绑定到请求该类的PVC。没有storageClassName的PV没有类，只能绑定到不请求特定类的PVC。
persistentVolumeReclaimPolicy：当前的回收政策是：Retain (保留)-手动回收、Recycle (回收)-基本擦除（rm -rf /thevolume/*）、Delete (删除)-删除相关的存储资产 (例如AWS EBS，GCE PD，Azure Disk或OpenStack Cinder卷)。
当前，仅NFS和HostPath支持回收。AWS EBS，GCE PD，Azure Disk和Cinder卷支持删除。
1.PV 状态/生命周期
卷将处于以下某种状态：
① Available：尚未绑定到声明(claim)的空闲资源
② Bound：卷已被声明绑定
③ Released：声明已被删除，但群集尚未回收该资源
④ Failed：该卷自动回收失败
CLI将显示绑定到PV的PVC的名称。
2.PVC
PVC作为用户对存储资源的需求申请,主要包括存储空间请求、访问模式、PV选择条件和存储类别等信息的设置。
-
apiVersion: v1
-
kind: PersistentVolumeClaim
-
metadata:
-
name: pvc
-
spec:
-
accessModes: 访问模式
-
- ReadWriteOnce
-
resources: 申请资源，
8Gi存储空间
-
requests:
-
storage:
8Gi
-
storageClassName: slow 存储类别
-
selector: PV选择条件
-
matchLabels:
-
release:
"stable"
-
matchExpressions:
-
- {key: environment, operator: In, values: [dev]}
3.nfs
-
yum install nfs-utils rpcbind -y
-
-
mkdir -p /data/nfs1 /data/nfs2 /data/nfs3 /data/nfs4 /data/nfs5 /data/nfs6
-
vim /etc/exports
-
/
data/nfs1 192.168.226.128/24(rw,sync,root_squash,all_squash)
-
/
data/nfs2 192.168.226.128/24(rw,sync,root_squash,all_squash)
-
/
data/nfs3 192.168.226.128/24(rw,sync,root_squash,all_squash)
-
/
data/nfs4 192.168.226.128/24(rw,sync,root_squash,all_squash)
-
/
data/nfs5 192.168.226.128/24(rw,sync,root_squash,all_squash)
-
/
data/nfs6 192.168.226.128/24(rw,sync,root_squash,all_squash)
-
-
systemctl start rpcbind.service
-
-
cat pv.yml
4.PVC
-
cat sts-pod-pvc.yaml
-
-
kubectl get pvc -o wide
-
-
echo
"pv-nfs2" > /data/nfs2/index.html
-
echo
"pv-nfs4" > /data/nfs4/index.html
-
echo
"pv-nfs6" > /data/nfs6/index.html
PVC与PV绑定时会根据storageClassName（存储类名称）和accessModes（访问模式）判断哪些PV符合绑定需求。然后再根据存储量大小判断，首先存PV储量必须大于或等于PVC声明量；其次就是PV存储量越接近PVC声明量，那么优先级就越高（PV量越小优先级越高）。
到指定node 使用curl 查看pod_ip
三、emptyDir存储卷
当Pod被分配给节点时，首先创建emptyDir卷，并且只要该Pod在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir中的数据将被永久删除。
-
mkdir /opt/volumes
-
cd /opt/volumes
-
vim pod-emptydir.yaml
-
apiVersion: v1
-
kind: Pod
-
metadata:
-
name: pod-emptydir
-
namespace:
default
-
labels:
-
app: myapp
-
tier: frontend
-
spec:
-
containers:
-
-
name: myapp
-
image: ikubernetes/myapp:v1
-
imagePullPolicy: IfNotPresent
-
ports:
-
-
name: http
-
containerPort:
80
-
定义容器挂载内容
-
volumeMounts:
-
使用的存储卷名称，如果跟下面volume字段
name值相同，则表示使用volume的这个存储卷
-
-
name: html
-
挂载至容器中哪个目录
-
mountPath: /usr/share/nginx/html/
-
-
name: busybox
-
image: busybox:latest
-
imagePullPolicy: IfNotPresent
-
volumeMounts:
-
-
name: html
-
在容器内定义挂载存储名称和挂载路径
-
mountPath: /data/
-
command: [
'/bin/sh',
'-c',
'while true;do echo $(date) >> /data/index.html;sleep 2;done']
-
定义存储卷
-
volumes:
-
定义存储卷名称
-
-
name: html
-
定义存储卷类型
-
emptyDir:
{}
-
-
-
kubectl apply -f pod-emptydir.yaml
-
-
kubectl get pods -o wide
在上面定义了2个容器，其中一个容器是输入日期到index.html中，然后验证访问nginx的html是否可以获取日期。以验证两个容器之间挂载的emptyDir实现共享。
四、hostPath存储卷
hostPath卷将 node 节点的文件系统中的文件或目录挂载到集群中。
hostPath可以实现持久存储，但是在node节点故障时，也会导致数据的丢失。
在 node01 节点上创建挂载目录
-
mkdir -p /data/pod/volume1
-
echo
'node01.ls.com' > /data/pod/volume1/index.html
在 node02 节点上创建挂载目录
-
mkdir -p /data/pod/volume1
-
echo
'node02.ls.com' > /data/pod/volume1/index.html
创建 Pod 资源
-
vim pod-hostpath.yaml
-
apiVersion: v1
-
kind: Pod
-
metadata:
-
name: pod-hostpath
-
namespace: default
-
spec:
-
containers:
-
- name: myapp
-
image: ikubernetes/myapp:v1
-
#定义容器挂载内容
-
volumeMounts:
-
#使用的存储卷名称，如果跟下面volume字段name值相同，则表示使用volume的这个存储卷
-
- name: html
-
挂载至容器中哪个目录
-
mountPath: /usr/share/nginx/html
-
读写挂载方式，默认为读写模式
false
-
readOnly:
false
-
#volumes字段定义了paues容器关联的宿主机或分布式文件系统存储卷
-
volumes:
-
#存储卷名称
-
- name: html
-
路径，为宿主机存储路径
-
hostPath:
-
在宿主机上目录的路径
-
path: /data/pod/volume1
-
定义类型，这表示如果宿主机没有此目录则会自动创建
-
type: DirectoryOrCreate
-
-
-
kubectl apply -f pod-hostpath.yaml
访问测试
kubectl get pods -o wide删除pod，再重建，验证是否依旧可以访问原来的内容
-
kubectl
delete
-f pod
-hostpath.yaml
-
kubectl apply
-f pod
-hostpath.yaml
-
-
kubectl
get pods
-o wide
五、nfs共享存储卷
在stor01节点上安装nfs，并配置nfs服务
-
mkdir /data/volumes -p
-
chmod 777 /data/volumes
-
vim /etc/
exports
-
/data/volumes 主机网段/
24(rw,no_root_squash)
-
-
systemctl start rpcbind
-
systemctl start nfs
-
-
showmount -e
-
Export list
for
stor01:
-
/data/volumes 主机网段/
24
-
-
-
//master节点操作
-
vim pod-nfs-vol.
yaml
-
apiVersion: v1
-
kind:
Pod
-
metadata:
-
name: pod-vol-nfs
-
namespace:
default
-
spec:
-
containers:
-
-
name: myapp
-
image: ikubernetes/
myapp:v1
-
volumeMounts:
-
-
name: html
-
mountPath:
/usr/share/nginx/html
-
volumes:
-
-
name: html
-
nfs:
-
path:
/data/volumes
-
server: stor01
-
-
-
kubectl apply -f pod-nfs-vol.
yaml
-
-
kubectl get pods -o wide
在nfs服务器上创建index.html
-
cd /data/volumes
-
-
vim index.html
-
<h1> nfs stor01</h1>
-
-
kubectl delete -f pod-nfs-vol.yaml 删除nfs相关pod，再重新创建，可以得到数据的持久化存储
-
-
kubectl apply -f pod-nfs-vol.yaml
六、PVC 和 PV
PV 全称叫做 Persistent Volume，持久化存储卷。它是用来描述或者说用来定义一个存储卷的，这个通常都是由运维工程师来定义。
PVC 的全称是 Persistent Volume Claim，是持久化存储的请求。它是用来描述希望使用什么样的或者说是满足什么条件的 PV 存储。
PVC 的使用逻辑：在 Pod 中定义一个存储卷（该存储卷类型为 PVC），定义的时候直接指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据配置的定义去 PV 申请，而 PV 是由存储空间创建出来的。PV 和 PVC 是 Kubernetes 抽象出来的一种存储资源。
PV和PVC模式是需要运维人员先创建好PV，然后开发人员定义好PVC进行一对一的Bond，但是如果PVC请求成千上万，那么就需要创建成千上万的PV，对于运维人员来说维护成本很高，Kubernetes提供一种自动创建PV的机制，叫StorageClass，它的作用就是创建PV的模板。
创建 StorageClass 需要定义 PV 的属性，比如存储类型、大小等；另外创建这种 PV 需要用到的存储插件，比如 Ceph 等。 有了这两部分信息，Kubernetes 就能够根据用户提交的 PVC，找到对应的 StorageClass，然后 Kubernetes 就会调用 StorageClass 声明的存储插件，自动创建需要的 PV 并进行绑定。
PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索引检查。
PV和PVC之间的相互作用遵循这个生命周期：
Provisioning（配置）→ Binding（绑定）→ Using（使用）→ Releasing（释放） → Recycling（回收）
Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
Binding，将 PV 分配给 PVC
Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制StorageProtection（1.9及以前版本为PVCProtection） 阻止删除正在使用的 PVC
Releasing，Pod 释放 Volume 并删除 PVC
Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除
PV 的状态
Available（可用）：表示可用状态，还未被任何 PVC 绑定
Bound（已绑定）：表示 PV 已经绑定到 PVC
Released（已释放）：表示 PVC 被删掉，但是资源尚未被集群回收
Failed（失败）：表示该 PV 的自动回收失败
-
kubectl explain pv 查看pv的定义方式
-
-
kubectl explain pv.spec 查看pv定义的规格
nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
capacity:（定义存储能力，一般用于设置存储空间）
storage: 2Gi （指定大小）
storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）
persistentVolumeReclaimPolicy: Retain #回收策略（Retain/Delete/Recycle）
Retain（保留）：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。
Delete（删除）：删除与PV相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持）
kubectl explain pvc 查看PVC的定义方式PV和PVC中的spec关键字段要匹配，比如存储（storage）大小、访问模式（accessModes）、存储类名称（storageClassName）
kubectl explain pvc.spec七、NFS使用PV和PVC
1.配置nfs存储
-
mkdir v{
1,
2,
3,
4,
5}
-
-
vim /etc/exports
-
/
data/volumes/v1 网段/24(rw,no_root_squash)
-
/
data/volumes/v2 网段/24(rw,no_root_squash)
-
/
data/volumes/v3 网段/24(rw,no_root_squash)
-
/
data/volumes/v4 网段/24(rw,no_root_squash)
-
/
data/volumes/v5 网段/24(rw,no_root_squash)
-
-
exportfs -arv
-
-
showmount -e
2.定义PV
这里定义5个PV，并且定义挂载的路径以及访问模式，还有PV划分的大小。
-
vim pv-demo.yaml
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: pv001
-
labels:
-
name: pv001
-
spec:
-
nfs:
-
path: /data/volumes/v1
-
server: stor01
-
accessModes: [
"ReadWriteMany",
"ReadWriteOnce"]
-
capacity:
-
storage:
1Gi
-
---
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: pv002
-
labels:
-
name: pv002
-
spec:
-
nfs:
-
path: /data/volumes/v2
-
server: stor01
-
accessModes: [
"ReadWriteOnce"]
-
capacity:
-
storage:
2Gi
-
---
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: pv003
-
labels:
-
name: pv003
-
spec:
-
nfs:
-
path: /data/volumes/v3
-
server: stor01
-
accessModes: [
"ReadWriteMany",
"ReadWriteOnce"]
-
capacity:
-
storage:
2Gi
-
---
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: pv004
-
labels:
-
name: pv004
-
spec:
-
nfs:
-
path: /data/volumes/v4
-
server: stor01
-
accessModes: [
"ReadWriteMany",
"ReadWriteOnce"]
-
capacity:
-
storage:
4Gi
-
---
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: pv005
-
labels:
-
name: pv005
-
spec:
-
nfs:
-
path: /data/volumes/v5
-
server: stor01
-
accessModes: [
"ReadWriteMany",
"ReadWriteOnce"]
-
capacity:
-
storage:
5Gi
-
-
-
kubectl apply -f pv-demo.yaml
-
-
kubectl
get pv
3.定义PVC
这里定义了pvc的访问模式为多路读写，该访问模式必须在前面pv定义的访问模式之中。定义PVC申请的大小为2Gi，此时PVC会自动去匹配多路读写且大小为2Gi的PV，匹配成功获取PVC的状态即为Bound
-
vim pod-vol-pvc.yaml
-
apiVersion: v1
-
kind: PersistentVolumeClaim
-
metadata:
-
name: mypvc
-
namespace:
default
-
spec:
-
accessModes: [
"ReadWriteMany"]
-
resources:
-
requests:
-
storage:
2Gi
-
---
-
apiVersion: v1
-
kind: Pod
-
metadata:
-
name: pod-vol-pvc
-
namespace:
default
-
spec:
-
containers:
-
- name: myapp
-
image: ikubernetes/myapp:v1
-
volumeMounts:
-
- name: html
-
mountPath: /usr/share/nginx/html
-
volumes:
-
- name: html
-
persistentVolumeClaim:
-
claimName: mypvc
-
-
-
kubectl apply -f pod-vol-pvc.yaml
-
-
kubectl
get pv
-
-
kubectl
get pvc
4.测试访问
在存储服务器上创建index.html，并写入数据，通过访问Pod进行查看，可以获取到相应的页面。
-
cd /data/volumes/v3/
-
echo
"welcome to use pv3" > index.html
-
-
kubectl get pods -o wide
StorageClass + NFS，实现 NFS 的动态 PV 创建
Kubernetes 本身支持的动态 PV 创建不包括 NFS，所以需要使用外部存储卷插件分配PV。https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
卷插件称为 Provisioner（存储分配器），NFS 使用的是 nfs-client，这个外部卷插件会使用已经配置好的 NFS 服务器自动创建 PV。
Provisioner：用于指定 Volume 插件的类型，包括内置插件（如 kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。
1）在stor01节点上安装nfs，并配置nfs服务
-
mkdir /opt/k8s
-
chmod 777 /opt/k8s/
-
-
vim /etc/exports
-
/opt/k8s 网段/24(rw,no_root_squash,
sync)
-
-
systemctl restart nfs
2）创建 Service Account，用来管理 NFS Provisioner 在 k8s 集群中运行的权限，设置 nfs-client 对 PV，PVC，StorageClass 等的规则
-
vim
nfs-client-rbac
.yaml
-
创建
Service
Account 账户，用来管理
NFS
Provisioner 在
k8s 集群中运行的权限
-
apiVersion:
v1
-
kind:
ServiceAccount
-
metadata:
-
name:
nfs-client-provisioner
-
---
-
创建集群角色
-
apiVersion:
rbac
.authorization
.k8s
.io/
v1
-
kind:
ClusterRole
-
metadata:
-
name:
nfs-client-provisioner-clusterrole
-
rules:
-
-
apiGroups:
[""]
-
resources:
["persistentvolumes"]
-
verbs:
["get", "list", "watch", "create", "delete"]
-
-
apiGroups:
[""]
-
resources:
["persistentvolumeclaims"]
-
verbs:
["get", "list", "watch", "update"]
-
-
apiGroups:
["storage.k8s.io"]
-
resources:
["storageclasses"]
-
verbs:
["get", "list", "watch"]
-
-
apiGroups:
[""]
-
resources:
["events"]
-
verbs:
["list", "watch", "create", "update", "patch"]
-
-
apiGroups:
[""]
-
resources:
["endpoints"]
-
verbs:
["create", "delete", "get", "list", "watch", "patch", "update"]
-
---
-
集群角色绑定
-
apiVersion:
rbac
.authorization
.k8s
.io/
v1
-
kind:
ClusterRoleBinding
-
metadata:
-
name:
nfs-client-provisioner-clusterrolebinding
-
subjects:
-
-
kind:
ServiceAccount
-
name:
nfs-client-provisioner
-
namespace:
default
-
roleRef:
-
kind:
ClusterRole
-
name:
nfs-client-provisioner-clusterrole
-
apiGroup:
rbac
.authorization
.k8s
.io
-
-
-
kubectl
apply
-f
nfs-client-rbac
.yaml
3）使用 Deployment 来创建 NFS Provisioner
NFS Provisione(即 nfs-client)，有两个功能：一个是在 NFS 共享目录下创建挂载点(volume)，另一个则是将 PV 与 NFS 的挂载点建立关联。
由于 1.20 版本启用了 selfLink，所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错，解决方法如下：
-
vim
/etc
/kubernetes
/manifests
/kube
-apiserver.yaml
-
spec:
-
containers:
-
- command:
-
- kube
-apiserver
-
-
--feature-gates=RemoveSelfLink=false 添加这一行
-
-
--advertise-address=192.168.80.20
-
......
-
-
kubectl apply
-f
/etc
/kubernetes
/manifests
/kube
-apiserver.yaml
-
kubectl
delete pods kube
-apiserver
-n kube
-
system
-
kubectl
get pods
-n kube
-
system
| grep apiserver
创建 NFS Provisioner
-
vim nfs-client-provisioner.yaml
-
kind: Deployment
-
apiVersion: apps/v1
-
metadata:
-
name: nfs-client-provisioner
-
spec:
-
replicas:
1
-
selector:
-
matchLabels:
-
app: nfs-client-provisioner
-
strategy:
-
type: Recreate
-
template:
-
metadata:
-
labels:
-
app: nfs-client-provisioner
-
spec:
-
serviceAccountName: nfs-client-provisioner 指定Service Account账户
-
containers:
-
-
name: nfs-client-provisioner
-
image: quay.io/external_storage/nfs-client-provisioner:latest
-
imagePullPolicy: IfNotPresent
-
volumeMounts:
-
-
name: nfs-client-root
-
mountPath: /persistentvolumes
-
env:
-
-
name: PROVISIONER_NAME
-
value: nfs-storage 配置provisioner的
Name，确保该名称与StorageClass资源中的provisioner名称保持一致
-
-
name: NFS_SERVER
-
value: stor01 配置绑定的nfs服务器
-
-
name: NFS_PATH
-
value: /opt/k8s 配置绑定的nfs服务器目录
-
volumes: 申明nfs数据卷
-
-
name: nfs-client-root
-
nfs:
-
server: stor01
-
path: /opt/k8s
-
-
-
kubectl apply -f nfs-client-provisioner.yaml
-
-
kubectl get pod
4）创建 StorageClass，负责建立 PVC 并调用 NFS provisioner 进行预定的工作，并让 PV 与 PVC 建立关联
-
vim nfs-client-storageclass.yaml
-
apiVersion: storage.k8s.io/v1
-
kind: StorageClass
-
metadata:
-
name: nfs-client-storageclass
-
provisioner: nfs-storage
-
这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
-
-
parameters:
-
archiveOnDelete:
"false"
false表示在删除PVC时不会对数据进行存档，即删除数据
-
-
-
kubectl apply -f nfs-client-storageclass.yaml
-
-
kubectl
get storageclass
5）创建 PVC 和 Pod 测试
-
vim test-pvc-pod.yaml
-
apiVersion: v1
-
kind: PersistentVolumeClaim
-
metadata:
-
name: test-nfs-pvc
-
spec:
-
accessModes:
-
- ReadWriteMany
-
storageClassName: nfs-client-storageclass #关联StorageClass对象
-
resources:
-
requests:
-
storage:
1Gi
-
---
-
apiVersion: v1
-
kind: Pod
-
metadata:
-
name: test-storageclass-pod
-
spec:
-
containers:
-
- name: busybox
-
image: busybox:latest
-
imagePullPolicy: IfNotPresent
-
command:
-
-
"/bin/sh"
-
-
"-c"
-
args:
-
-
"sleep 3600"
-
volumeMounts:
-
- name: nfs-pvc
-
mountPath: /mnt
-
restartPolicy: Never
-
volumes:
-
- name: nfs-pvc
-
persistentVolumeClaim:
-
claimName: test-nfs-pvc 与PVC名称保持一致
-
-
-
kubectl apply -f test-pvc-pod.yaml
PVC 通过 StorageClass 自动申请到空间
kubectl get pvc查看 NFS 服务器上是否生成对应的目录，自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上
ls /opt/k8s/进入 Pod 在挂载目录 /mnt 下写一个文件，然后查看 NFS 服务器上是否存在该文件
-
kubectl
exec -it test-storageclass-pod sh
-
/
# cd /mnt/
-
/mnt
# echo 'this is test file' > test.txt
发现 NFS 服务器上存在，说明验证成功
cat /opt/k8s/test.txt转载：https://blog.csdn.net/Drw_Dcm/article/details/127753410