9、Kubernetes核心技术 - Volume
目录
一、概述
二、卷的类型
三、emptyDir
四、hostPath
五、NFS
5.1、master服务器上搭建nfs服务器
5.2、各个slave节点上安装nfs客户端
5.3、创建Pod
六、PV和PVC
6.1、PV
6.1.1、PV资源清单文件示例
6.1.2、PV属性说明
6.1.3、PV的状态
6.2、PVC
6.2.1、PVC资源清单文件示例
6.3、PV/PVC的使用
6.4、hostPath的PV与PVC案例演示
6.4.1、创建PV
6.4.2、创建PVC
6.4.3、创建Pod
6.4.4、节点添加内容
6.4.5、pod查看内容
6.5、NFS的PV与PVC案例演示
6.5.1、master服务器上搭建nfs服务器
6.5.2、各个slave节点上安装nfs客户端
6.5.3、创建PV
6.5.4、创建PVC
6.5.5、创建Pod
6.5.6、进入pod中，添加相关内容
6.5.7、进入nfs服务器中查看对应内容
一、概述
Kubernetes中的volume抽象主要用来解决两个问题：
- 1、容器中的文件在磁盘上是临时存放的，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失，因为容器会以干净的状态（镜像最初的状态）重新启动【持久化存储】；
- 2、当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件【多容器数据共享】；
Kubernetes 支持很多类型的卷。 Pod 可以同时使用任意数目的卷类型。 临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。 当 Pod 不再存在时，Kubernetes 也会销毁临时卷；不过 Kubernetes 不会销毁持久卷。 对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。
二、卷的类型
k8s 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。
查看k8s支持哪些类型的卷：
$ kubectl explain pods.spec.volumes
KIND: Pod
VERSION: v1
RESOURCE: volumes <[]Object>
DESCRIPTION:
List of volumes that can be mounted by containers belonging to the pod.
More info: https://kubernetes.io/docs/concepts/storage/volumes
Volume represents a named volume in a pod that may be accessed by any
container in the pod.
FIELDS:
awsElasticBlockStore 从上面的帮助信息，可以看到支持大多数的存储系统，包括云存储、节点本地存储、分布式存储、网络存储、临时存储等，比如awsElasticBlockStore、azureDisk、azureFile划分为云存储，glusterfs、rbd这些划分为分布式存储；nfs、iscsi、fc这些划分为网络存储；emptyDir划分为临时存储；hostPath、local划分为本地存储；自定义存储csi；特殊存储configMap、secret、downwardAPId；持久卷申请persistentVolumeClaim等等。
使用卷时, Pod 声明中需要提供卷的类型 (.spec.volumes 字段)和卷挂载的位置 (.spec.containers.volumeMounts 字段)。
三、emptyDir
当 Pod 指定到某个节点上时，首先创建的是一个 emptyDir 卷，并且只要 Pod 在该节点上运行，卷就一直存在，卷最初是空的。 尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，但是这些容器都可以读写 emptyDir 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会永久删除。emptyDir 主要用于某些应用程序无需永久保存的临时目录，多个容器的共享目录等。
注意：容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃期间 emptyDir 卷中的数据是安全的。
下面我们演示emptyDir。创建资源清单：vim pod-emptydir-test.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-emptydir-test
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
volumeMounts:
- mountPath: /data
name: emptydir-test-volume
- image: busybox
name: busybox
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- sleep 3600
volumeMounts:
- mountPath: /data #指定Volume在容器中的挂载路径
name: emptydir-test-volume #指定使用哪个Volume
volumes:
- name: emptydir-test-volume #volume名称
emptyDir: {}这里创建了两个容器，将数据挂载到同一个目录/data下。创建pod：
[root@localhost /]# kubectl create -f pod-emptydir-test.yaml
pod/pod-emptydir-test created
[root@localhost /]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-emptydir-test 2/2 Running 0 23s接下来，我们进入nginx容器中，在/data文件夹下写入创建一个文件a.txt并写入数据："hello emptydir"
[root@localhost /]# kubectl exec -it pod-emptydir-test -c nginx bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@pod-emptydir-test:/# cd /data/
root@pod-emptydir-test:/data# touch a.txt
root@pod-emptydir-test:/data# echo "hello emptydir" >> a.txt
root@pod-emptydir-test:/data# cat a.txt
hello emptydir然后，我们查看busybox的/data是否存在数据a.txt文件：
[root@localhost /]# kubectl exec -it pod-emptydir-test -c busybox sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # cd /data/
/data # ls
a.txt
/data # cat a.txt
hello emptydir以上，就是一个通过emptyDir实现多个容器之间共享数据的例子。
四、hostPath
hostPath 卷能将主机节点文件系统上的文件或目录挂载到pod中，使容器可以使用宿主机上的目录或文件，在pod被删除，这个目录还是存在的，不会被删除。但是需要注意的是，pod删除之后重新创建后，必须调度到同一个node节点上，数据才不会丢失，因为如果调度到其它节点，其它节点可能压根没有这个目录，所以数据就丢了。
注意：HostPath 卷存在许多安全风险，最佳做法是尽可能避免使用 HostPath。 当必须使用 HostPath 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。
下面我们演示hostPath。创建资源清单：vim pod-hostpath-test.yaml
# 使用hostPath，将主机的/data1目录，挂载到pod的/data目录
apiVersion: v1
kind: Pod
metadata:
name: pod-hostpath-test
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
volumeMounts:
- mountPath: /data # 容器内的目录
name: hostpath-test-volumea
volumes:
- name: hostpath-test-volume
hostPath: # 存储类型
path: /data1 # Pod被调度到的主机节点上的目录
type: DirectoryOrCreate # 指定如果该路径不存在，将如何处理创建pod，可以看到pod被调度到node02节点：
[root@localhost /]# kubectl create -f pod-hostpath-test.yaml
pod/pod-hostpath-test created
[root@localhost /]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-hostpath-test 1/1 Running 0 9s 10.244.140.68 node02 接下来，我们需要在node02节点上/data1目录创建一个a.txt：
[root@localhost /]# ls
bin boot data1 dev etc home java lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
[root@localhost /]# cd /data1/
[root@localhost data1]# touch a.txt
[root@localhost data1]# echo "hello hostPath" >> a.txt
[root@localhost data1]# cat a.txt
hello hostPath然后，我们进入pod-hostpath-test这个pod的挂载的路径下是否存在a.txt：
[root@localhost /]# kubectl exec pod-hostpath-test cat /data/a.txt
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
hello hostPath可以看到，pod调度之后所在的主机node02上/data1目录就跟pod里面的/data目录对应起来了，只要我们修改了主机目录上的a.txt，在pod里面就能看到a.txt为更新后的内容。如下图：
hostPath的type属性用来指定当宿主机上的指定的路径不存在时该怎么办，支持的 type 值如下：
- 空字符串（默认）
默认选项，意味着在挂载hostPath 卷之前不会执行任何检查。
- DirectoryOrCreate
如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 Kubelet 相同的组和所有权。
- Directory
在给定路径上必须存在的目录。
- FileOrCreate
如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 Kubelet 相同的组和所有权。
- File
在给定路径上必须存在的文件。
- Socket
在给定路径上必须存在的 UNIX 套接字。
- CharDevice
在给定路径上必须存在的字符设备。
- BlockDevice
在给定路径上必须存在的块设备。
五、NFS
nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。
5.1、master服务器上搭建nfs服务器
[root@localhost /]# yum -y install nfs-utils rpcbind
# 共享目录
[root@localhost /]# mkdir -p /data/volumes && chmod 755 /data/volumes
# 授予所有连接访问/data/volumes目录的权限
[root@localhost /]# echo '/data/volumes *(insecure,rw,sync,no_root_squash)'>> /etc/exports
# 启动服务与设置开机启动
[root@localhost /]# systemctl enable rpcbind && systemctl start rpcbind
[root@localhost /]# systemctl enable nfs && systemctl start nfs
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.5.2、各个slave节点上安装nfs客户端
这里是node01、node02节点需要执行。
# 安装nfs客户端
[root@localhost /]# yum -y install nfs-utils rpcbind
[root@localhost /]# mkdir /mntdata
[root@localhost /]# mount -t nfs 10.0.88.133:/data/volumes /mntdata
# 能够正常看到nfs服务器共享出来的目录，并且也能正常挂载使用
[root@localhost ~]# mount | grep /data/volumes
10.0.88.133:/data/volumes on /mntdata type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.89.1,local_lock=none,addr=10.0.88.133)5.3、创建Pod
资源清单文件：vim nfs-volume-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nfs-volume-pod
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
volumeMounts:
- name: nfs-volume
mountPath: /usr/share/nginx/html
volumes:
- name: nfs-volume
nfs:
path: /data/volumes # 指定nfs文件系统的导出文件路径
server: 10.0.88.133 # 指定nfs服务器地址创建Pod:
[root@localhost /]# kubectl apply -f nfs-volume-pod.yaml
pod/nfs-volume-pod created
[root@localhost /]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-volume-pod 1/1 Running 0 22s 10.244.140.72 node02
[root@localhost /]# curl 10.244.140.72
403 Forbidden
403 Forbidden
nginx/1.21.5
# 在nfs服务器的/data/volumes/目录下创建一个index.html文件
[root@localhost /]# cd /data/volumes/
[root@localhost volumes]# echo "hello nfs volume..." > index.html
# nfs服务器的/data/volumes目录已经挂载到Pod的/usr/share/nginx/html目录，pod能够访问到对应文件内容
[root@localhost volumes]# curl 10.244.140.72
hello nfs volume...
# 可以看到对应pod里以读写方式挂载了nfs-volume存储卷，对应nfs-volume存储卷类型为NFS，对应的nfs服务器的挂载目录是/data/volumes，pod里挂载目录是/usr/share/nginx/html
[root@localhost /]# kubectl describe pod/nfs-volume-pod
Name: nfs-volume-pod
Namespace: default
Priority: 0
Node: node02/10.0.89.2
Start Time: Wed, 04 Jan 2023 15:09:40 +0800
Labels:
Annotations: cni.projectcalico.org/podIP: 10.244.140.72/32
cni.projectcalico.org/podIPs: 10.244.140.72/32
Status: Running
IP: 10.244.140.72
IPs:
IP: 10.244.140.72
Containers:
nginx:
Container ID: docker://b73887bd7c41c29b0f269fd97b6f32197d467da2e4c498fe3b3e97f568561a98
Image: nginx
Image ID: docker-pullable://nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 04 Jan 2023 15:09:59 +0800
Ready: True
Restart Count: 0
Environment:
Mounts:
/usr/share/nginx/html from nfs-volume (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-b6tdl (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
nfs-volume:
Type: NFS (an NFS mount that lasts the lifetime of a pod)
Server: 10.0.88.133
Path: /data/volumes
ReadOnly: false
kube-api-access-b6tdl:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional:
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors:
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events: 六、PV和PVC
6.1、PV
PV全称是PersistentVolume（持久化卷）。PV是由管理员设置的存储，是集群层面可用的资源，没有namespace这一说，集群内所有资源都可以用。
我们知道，Pod中声明的Volume，生命周期与Pod相同，这样一来，当Pod被删除之后，Volume也就被删除了。
于是，k8s引入了PV，它可以将存储和计算分离，通过不同的组件来管理存储资源和计算资源，解耦Pod和Volume之间生命周期的关联，使得PV的生命周期独立于使用它的任何Pod。
6.1.1、PV资源清单文件示例
apiVersion: v1
kind: PersistentVolume # PV固定为PersistentVolume
metadata: # PV建立不要加名称空间，因为PV属于集群级别的
name: pv-demo # PV名称
spec:
storageClassName: manual # 存储类
capacity:
storage: 1Gi # 存储空间大小
accessModes: # 访问模式
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain # PV回收策略
hostPath: # 卷类型
path: "/mnt/data" # 挂载路径6.1.2、PV属性说明
- capacity
存储能力， 目前只支持存储空间的设置， 就是我们这里的 storage=1Gi，不过未来可能会加入 IOPS、吞吐量等指标的配置。
- accessModes
访问模式， 是用来对 PV 进行访问模式的设置，用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
1)、ReadWriteOnce（RWO）：可以被单节点以读写模式挂载；
2)、ReadOnlyMany（ROX）：可以被多个节点以只读模式挂载；
3)、ReadWriteMany（RWX）：可以被多个节点以读写模式挂载；
- persistentVolumeReclaimPolicy
PV的回收策略, 目前只有 NFS 和 HostPath 两种类型支持回收策略。当用户使用完卷时，可以从api中删除PVC对象，从而允许回收资源，回收资源会告诉PV如何处理该卷，目前卷可以保留，回收或删除：
1)、Retain（保留）- 允许手动回收资源，当删除PVC时，PV仍然存在，volume被视为已释放，管理员可以手动回收卷；
2)、Recycle（回收）- 清除 PV 中的数据，效果相当于执行rm -rf删除PV；
3)、Delete（删除）- 删除PVC时会同时删除PV，常见于云服务商的存储服务，比如 ASW EBS；
- storageClassName
PV的类，一个特定类型的PV只能绑定特定类型的PVC；
因为PV是直接对接底层存储的，就像集群中的Node可以为Pod提供计算资源（CPU和内存）一样，PV可以为Pod提供存储资源。因此PV不是namespaced的资源，属于集群层面可用的资源。Pod如果想使用该PV，需要通过创建PVC挂载到Pod中。
6.1.3、PV的状态
- 创建的pv会有一下几种状态：
- Available（可用）：没有被PVC绑定的空间资源
- Bound (已绑定)：已经被PVC绑定
- Released (已释放)：PVC被删除，但是资源还未被重新使用
- Failed (失败)：自动回收失败
6.2、PVC
PVC全写是PersistentVolumeClaim（持久化卷声明），PVC 是用户对存储的请求，创建完成后，可以和PV实现一对一绑定。对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可。
6.2.1、PVC资源清单文件示例
apiVersion: v1
kind: PersistentVolumeClaim # PVC固定为PersistentVolumeClaim
metadata:
name: pvc-demo # PVC名称
namespace: default # PVC需要定义所属空间，与所挂载的POD属于同一个空间
spec:
accessModes:
- ReadWriteOnce # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
resources: # 定义资源要求PV满足这个PVC的要求，PV才会被匹配到
requests:
storage: 1Gi # 与所需挂载的PV大小，不可超过需要注意的是，各个方面都符合要求PVC才能和PV进行绑定，比如accessModes、storageClassName、volumeMode都需要相同才能进行绑定。
6.3、PV/PVC的使用
a）、需要找一个存储服务器，把它划分成多个存储空间；
b）、k8s管理员可以把这些存储空间定义成多个pv；
c）、在pod中使用pvc类型的存储卷之前需要先创建pvc，通过定义需要使用的pv的大小和对应的访问模式，找到合适的pv；
d）、pvc被创建之后，就可以当成存储卷来使用了，我们在定义pod时就可以使用这个pvc的存储卷；
e）、pvc和pv它们是一 一对应的关系，pv如果被被pvc绑定了，就不能被其他pvc使用了；
f）、我们在创建pvc的时候，应该确保和底下的pv能匹配绑定，否则pvc就会处于pending状态；
6.4、hostPath的PV与PVC案例演示
6.4.1、创建PV
创建资源清单文件：vim pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata: # PV建立不要加名称空间，因为PV属于集群级别的，集群内所有资源可用
name: my-pv # PV名称
labels: # 这些labels可以不定义
type: local
spec:
storageClassName: manual
capacity: # 设置存储空间大小
storage: 100Mi
persistentVolumeReclaimPolicy: Retain # PV回收策略
accessModes: # 设置访问模式
- ReadWriteOnce #单路读写，卷只能被单一集群节点挂载读写
hostPath:
path: "/pvctest/data" # 挂载路径[root@localhost /]# kubectl apply -f pv.yaml
persistentvolume/my-pv created
[root@localhost /]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
my-pv 100Mi RWO Retain Available manual 5s创建完PV后，可以看到初始状态为Available（可用）。
6.4.2、创建PVC
创建资源清单文件：vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc # PVC的名称
spec:
storageClassName: manual
accessModes: # PVC也需要定义访问模式，不过它的模式一定是和现有PV相同或者是它的子集，否则匹配不到PV
- ReadWriteOnce
resources: # 定义资源要求，只有PV满足这个PVC的要求才会被匹配到
requests:
storage: 100Mi # 定义要求有多大空间[root@localhost /]# kubectl apply -f pvc.yaml
persistentvolumeclaim/my-pvc created
[root@localhost /]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-pvc Bound my-pv 100Mi RWO manual 5s创建完PVC后，可以看到PVC的状态已经变成Bound（绑定）状态，并且根据访问模式、申请资源的大小，自动绑定了my-pv这个PV。
6.4.3、创建Pod
创建资源清单文件：vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
volumes:
- name: pv-storage-volume # volume的名称
persistentVolumeClaim: # 定义volume的时候，指定了前面我们定义的PVC：my-pvc
claimName: my-pvc # 需跟前面定义的PVC名称保持一致
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html" # 容器内挂载路径
name: pv-storage-volume # 引用前面定义的volume的名称[root@localhost /]# kubectl apply -f pod.yaml
pod/my-pod created
[root@localhost /]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-pod 1/1 Running 0 25s 10.244.140.70 node02 可以看到，当前pod被调度到node02节点，然后我们从pv的资源清单文件中可以看到，pv的挂载路径是主机节点的/pvctest/data目录。
6.4.4、节点添加内容
接下来我们在node02主机节点的/pvctest/data目录创建一个index.html文件：
[root@localhost /]# cd /pvctest/data/
[root@localhost data]# pwd
/pvctest/data
[root@localhost data]# echo "hello nginx, this is from pv/pvc" > index.html
[root@localhost data]# cat index.html
hello nginx, this is from pv/pvc6.4.5、pod查看内容
从pod的资源清单文件中，挂载路径是/usr/share/nginx/html，所以我们查看pod中这个目录：
[root@localhost /]# kubectl get pod
NAME READY STATUS RESTARTS AGE
my-pod 1/1 Running 0 4m8s
[root@localhost /]# kubectl exec my-pod -it bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@my-pod:/# cd /usr/share/nginx/html
root@my-pod:/usr/share/nginx/html# ls
index.html
root@my-pod:/usr/share/nginx/html# cat index.html
hello nginx, this is from pv/pvc如上，容器中的/usr/share/nginx/html目录已经跟主机节点上的/pvc/data目录对应起来了，主要我们修改其中一个地方的文件内容，在另外一边都能及时查看到更新后的内容。如下图：
当然，因为nginx的静态文件目录就是/usr/share/nginx/html，我们也可以通过curl查看nginx：
[root@localhost /]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-pod 1/1 Running 0 6m54s 10.244.140.70 node02
[root@localhost /]# curl 10.244.140.70
hello nginx, this is from pv/pvc 可以看到，已经能够读取到主机节点/pvctest/data/index.html的内容。
6.5、NFS的PV与PVC案例演示
6.5.1、master服务器上搭建nfs服务器
[root@localhost /]# yum -y install nfs-utils rpcbind
# 共享目录
[root@localhost /]# mkdir -p /data/k8s && chmod 755 /data/k8s
# 授予所有连接访问权限
[root@localhost /]# echo '/data/k8s *(insecure,rw,sync,no_root_squash)'>>/etc/exports
# 启动服务与设置开机启动
[root@localhost /]# systemctl enable rpcbind && systemctl start rpcbind
[root@localhost /]# systemctl enable nfs && systemctl start nfs
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.6.5.2、各个slave节点上安装nfs客户端
这里是node01、node02节点需要执行。
# 安装nfs客户端
[root@localhost /]# yum -y install nfs-utils rpcbind
[root@localhost /]# mkdir /nfsdata
[root@localhost /]# mount -t nfs 10.0.88.133:/data/k8s /nfsdata6.5.3、创建PV
资源清单文件如下： vim nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
storageClassName: manual
capacity:
storage: 100Mi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
nfs:
path: /data/k8s
server: 10.0.88.133 #nfs服务器节点的IP地址，这里是master的IP地址：10.0.88.133[root@localhost /]# kubectl apply -f nfs-pv.yaml
persistentvolume/nfs-pv created
[root@localhost /]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv 100Mi RWO Retain Available manual 7s6.5.4、创建PVC
资源清单文件如下： vim nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
namespace: default
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Mi[root@localhost /]# kubectl apply -f nfs-pvc.yaml
persistentvolumeclaim/nfs-pvc created
# pvc已自动绑定到nfs-pv上，状态为Bound
[root@localhost /]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nfs-pvc Bound nfs-pv 100Mi RWO manual 6s
# 再次查看pv, 状态也变为Bound，并且可以看到绑定的pvc就是default命名空间下的nfs-pvc
[root@localhost /]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv 100Mi RWO Retain Bound default/nfs-pvc manual 90s6.5.5、创建Pod
资源清单文件如下： vim nfs-pod.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-pod
namespace: default #必须与所挂载的pvc相同的命名空间
spec:
replicas: 1
selector: #指定Pod的选择器
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:alpine
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: web
volumeMounts: #挂载容器中的目录到pvc nfs中的目录
- name: nfs-volume
mountPath: /usr/share/nginx/html
volumes:
- name: nfs-volume
persistentVolumeClaim: #指定pvc
claimName: nfs-pvc[root@localhost /]# kubectl apply -f nfs-pod.yaml
deployment.apps/nfs-pod created
[root@localhost /]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-pod-dc97b99d6-bhwck 1/1 Running 0 36s 10.244.140.71 node02 6.5.6、进入pod中，添加相关内容
[root@localhost /]# kubectl exec -it nfs-pod-dc97b99d6-bhwck sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # cd /usr/share/nginx/html
/usr/share/nginx/html # echo "hello, this is fron nfs pv/pvc" > index.html
/usr/share/nginx/html # cat index.html
hello, this is fron nfs pv/pvc6.5.7、进入nfs服务器中查看对应内容
本例中，我们的nfs服务器就是master节点，我们nfs服务器的共享目录/data/k8s中：
[root@localhost /]# cd /data/k8s/
[root@localhost k8s]# ls
index.html
[root@localhost k8s]# cat index.html
hello, this is fron nfs pv/pvc可以看到，容器中的相关内容，在nfs服务器上也可以看到了，如果我们需要将容器的日志自定义输出到某个地方，不妨可以试试nfs这种方式。