k8s pv与pvc_deployment 使用pvc

1.前言

PV 是 Kubernetes 集群中的一种资源对象，它代表着一块物理存储设备，例如磁盘、网络存储或云存储等。PV 可以被多个 Pod 共享，并且可以独立于 Pod 存在。PV 可以配置不同的访问模式 (Access Modes)，例如 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany，以确定 PV 可以被多少个 Pod 同时挂载以及这些 Pod 是否可以进行读写操作。PV 还可以配置不同的回收策略 (Reclaim Policy)，例如 Retain、Delete 或 Recycle，以确定 PV 在被释放后如何进行清理，PVC 是 Kubernetes 集群中的另一种资源对象，它代表着一个 Pod 对 PV 的请求。PVC 可以指定所需的存储容量和访问模式，以及所需的 PV 的属性，例如存储类、访问模式和标签等。当 Pod 需要使用持久化存储时，它可以通过 PVC 来请求 PV。如果没有匹配的 PV 可用，则 Kubernetes 将自动创建一个新的 PV 来满足 PVC 的要求

2.配置存储

本实验搭建nfs存储来做为pv的存储

用master节点搭建nfs服务端

yum -y install nfs-common nfs-utils

创建nfs共享目录

mkdir /k8s-master

授权共享目录

chmod 666 /k8s-master

配置exports文件

cat > /etc/exports << EOF

/k8s-data *(rw,no_root_squash,no_all_squash,sync)

EOF

启动nfs服务

systemctl strart rpcbind

systemctl start nfs

在所有node节点也需要按照nfs客户端，不然使用pv时挂载不了

yum -y install nfs-utils

3.静态pv

3.1先来说一下pv中的几个参数配置项

persistentVolumeReclaimPolicy配置pv回收策略，有以下三个参数

Retain：此回收策略在删除pvc时，不会清除pv中的数据，并且pv也不会自动回收，需要手动删除pv重建，pv才会变成可用状态，当然重建后pv路径中的数据依然还存在

Recycle：删除pvc后，自动清除pv挂载路径下的数据，pv变为可被绑定状态，但是此策略已经在k8s 1.22.0版本中被废弃了

Delete： 删除 Storage Provider上对应的存储资源，但是NFS不支持Delete策略，只有使用其它的存储才支持，例如 AWS EBS等

accessModes配置访问模式，有以下三个参数

ReadWriteOnce：pv可以被一个节点以读写的方式挂载

ReadOnlyMany：pv可以被多个节点以只读的方式挂载

ReadWriteMany：pv可以被多个节点以读写的方式挂载

限制多节点和单节点的挂载对NFS存储无效，NFS 存储插件支持多次挂载，即使 accessModes 属性设置为 ReadWriteOnce，也可以被多个 Pod 挂载

3.2 创建pv

我这边因为有nas存储所以就没用master作为服务器

因为使用的是nfs网络共享存储服务，所以所有k8s节点都需要提前安装nfs服务,不然挂载会出现报错

yum -y install nfs-utils

创建pv yaml文件

vi pv1.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 1Gi    #配置容量大小
  accessModes:
    - ReadWriteOnce     #配置访问策略为只允许一个节点读写
  persistentVolumeReclaimPolicy: Retain  #配置回收策略，Retain为手动回收
  storageClassName: nfs       #配置为nfs
  nfs:
    path: /volume2/k8s-data/pv1   #配置nfs服务端的共享路径
    server: 10.1.13.99    #配置nfs服务器地址

使用yaml文件生成pv

kubectl create -f pv1.yaml

kubectl get pv

 可以看到已经按yaml文件中的要求创建了一个pv，状态为availabel，此状态为可绑定状态

在这里也介绍一下pv的几个状态

Available：PV 可以被 PVC 请求并绑定

Bound：PV 已经被 PVC 绑定，并且可以被 Pod 挂载和使用

Released：PVC 已经释放了 PV，但是 PV 中的数据仍然存在，可以被其他 PVC 请求并绑定

Failed：PV 的状态出现了错误，可能是由于存储设备故障或者其他原因导致的

3.3创建pvc

vi pvc1.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs

执行yaml文件创建pvc

kubectl create -f pvc1.yaml

kubectl get pvc

 可以看到已经创建出了pvc，并且状态为绑定状态，再来查看一下pv的状态

kubectl get pv

可以看到pv也是bound状态，接下来创建一个deployment来使用这个pvc 

3.4创建deployement

vi deployment-nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata: 
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        volumeMounts:        #配置在pod上的挂载目录
        - mountPath: "/data"
          name: data
      volumes:      #配置使用pvc
        - name: data
          persistentVolumeClaim:
            claimName: pvc1

现在来执行一下这个yaml

kubectl create -f deployment-nginx.yaml 

kubectl describe deployment nginx

查看deployment的详细信息可以看到我们配置的挂载，进入pod的挂载目录创建一下文件看看效果

 kubectl get pod -l app=nginx

kubectl exec -it nginx-848ccb9994-8hkx7 /bin/sh

可以看到我们在挂载的目录中创建了一个123.txt的文件，在nfs服务端路径中查看一下效果

 

可以看到在nfs服务端的路径中同步创建出了123.txt文件，现在我们把deployment和pvc都删除掉看看会怎么样

kubectl delete deployment nginx

kubectl delete pvc pvc1

kubectl get pv

 可以看到我们把pvc删除后pv变成了released状态数据也依然存在，这是因为配置了回收策略为retain，需要手动删除数据，可以把pv删除后重建就会变回available状态，即使把pv删除，路径中的数据依然存在

kubectl delete -f pv1.yaml

kubectl create -f pv1.yaml

kubectl get pv

ls /dev/nas/pv1

 因为使用的是nfs的原因也展示不了其它的回收策略和写入策略的功能

4.动态pv

当使用pv比较多的时候，使用自动创建pv是比较方便的

因为使用的是nfs的原因需要额外安装一个NFS Client Provisioner插件

4.1安装插件并授权

vi nfs-rbac.yaml

#配置插件rabc权限yaml
kind: ServiceAccount
apiVersion: v1
metadata:
  name: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
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: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
 
#创建nfs插件yaml
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nfs-client-provisioner
  namespace: default
  labels:
    app: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: gmoney23/nfs-client-provisioner   #插件镜像
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: nfs-client
            - name: NFS_SERVER
              value: 10.1.13.99   #配置nfs服务地址
            - name: NFS_PATH
              value: /volume2/k8s-data  #配置nfs服务的共享路径
      volumes:
        - name: nfs-client-root  
          nfs:
            server: 10.1.13.99  #配置nfs服务地址
            path: /volume2/k8s-data  #配置nfs服务的共享路径
 
 
#配置自动创建pv的模板yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: nfs-client
parameters:
  archiveOnDelete: "true"

我这边为了方便直接把配置pv自动创建模板的yaml也写到了一起，接下来执行一下这个yaml文件

 kubectl create -f nfs-rbac.yaml

kubectl get storageclass

这边来创建pvc测试一下，看看是否会自动生成pv

vi pvc1.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  storageClassName: nfs-storage  #写入pv模板的名称

执行一下yaml看看是否有自动生成pv

kubectl get pv

kubectl create -f pvc1.yaml

kubectl get pvc

kubectl get pv

 可以看到自动创建出了符合pvc要求的pv，并且状态也是已绑定状态

现在删除一下pvc看看，pv是什么状态

kubectl delete pvc pvc1

kubectl get pvc

kubectl get pv

可以看到删除pvc后，pv也自动被删除了