【云原生-Kubernetes篇】K8s的存储卷/数据卷+PV与PVC

一、Kubernetes中的存储卷

1.1 为什么需要存储卷？

容器部署过程中一般有以下三种数据：

• 启动时需要的初始数据：例如配置文件 （init container）

• 启动过程中产生的临时数据：该临时数据需要多个容器间共享

• 启动过程中产生的持久化数据：例如MySQL的data目录 (业务数据–很重要)

而容器中的文件在磁盘上是临时存放的，这给容器中运行比较重要的应用程序带来一些问题

问题1： 数据持久化问题，当容器升级或者崩溃时，kubelet会重建容器，容器内文件会丢失。

问题2： 数据共享问题，一个Pod中运行多个容器并需要共享文件。

Kubernetes中的数据卷（Volume），也可以称为存储卷，能够解决这两个问题。

1.2 存储卷概述

1.2.1 简介

存储卷是用于持久化存储容器中数据的一种机制，可以提供容器内持久化存储的能力，使容器可以在不同的生命周期中保留数据。

数据卷与容器相互独立，并且具有自己的生命周期。

当容器被销毁或重启时，数据卷的内容仍然保持不变，从而确保了容器内数据的持久性（解决了问题1）。

数据卷可以与一个或多个容器进行绑定，使它们可以共享数据（解决了问题2）。

1.2.2 volume字段

Kubernetes中的Volume提供了在容器中挂载外部存储的能力

Pod需要设置卷来源（volume）和挂载点（volumeMounts）两个信息后才可以使用相应的Volume。

kubectl explain pod.spec.volumes

常用字段名	描述
name	指定数据卷的名称，用于标识该数据卷
<不同类型的数据卷>	Kubernetes 支持不同类型的数据卷，如 NFS、GCE Persistent Disk、AWS EBS等，用于满足特定的存储需求

kubectl explain pod.spec.containers.volumeMounts

常用字段名	描述
name	指定要挂载的数据卷的名称
mountPath	指定挂载点的路径，即将数据卷挂载到容器内的哪个目录
readOnly	指定挂载点是否为只读模式。如果设置为 true，则容器只能读取挂载的数据，不能写入

1.3 常用的存储卷类型

1.3.1 emptyDir（临时存储卷）

简介

emptyDir 卷可实现Pod中的容器之间共享目录数据，但没有持久化数据的能力，存储卷会随着Pod生命周期结束而一起删除。

emptyDir`的一些用途

• 缓存空间，例如基于磁盘的归并排序。
• 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
• 在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件。

字段

kubectl explain pod.spec.volumes.emptyDir

emptyDir.medium 字段用于控制 emptyDir 卷的存储位置，有两个值：Memory和Default。

值	描述
Memory	表示将 emptyDir 卷存储在主机的内存中 数据只存在于 Pod 的生命周期内，并且不会被持久化到磁盘上
Default	表示将 emptyDir 卷存储在主机的磁盘中 数据会在 Pod 重新启动时保留，但不会在节点之间持久化

emptyDir.sizeLimit字段用于来限制卷的容量大小，但是不会自动调整底层存储的大小。

因此，如果设置的大小限制超过节点上的可用磁盘空间，可能会导致 Pod 失败启动或运行时出现错误。

emptyDir 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

1.3.2 hostPath（节点存储卷）

hostPath 卷将node节点上的目录/文件挂载到Pod容器的指定目录上。

有持久化数据的能力，但只能在单个node节点上持久化数据，不能实现跨node节点的Pod共享数据

hostPath卷配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # 宿主机上目录位置
      path: /data
      # 此字段为可选
      type: Directory

支持的 type 值如下：

取值	行为
	空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。
DirectoryOrCreate	如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 kubelet 相同的组和属主信息。
Directory	在给定路径上必须存在的目录。
FileOrCreate	如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 kubelet 相同的组和所有权。
File	在给定路径上必须存在的文件。
Socket	在给定路径上必须存在的 UNIX 套接字。
CharDevice	在给定路径上必须存在的字符设备。
BlockDevice	在给定路径上必须存在的块设备。

补充：FileOrCreate模式

FileOrCreate 模式不会负责创建文件的父目录。

如果欲挂载的文件的父目录不存在，Pod 启动会失败。

为了确保这种模式能够工作，可以尝试把文件和它对应的目录分开挂载，如 FileOrCreate 配置所示。

apiVersion: v1
kind: Pod
metadata:
  name: test-webserver
spec:
  containers:
  - name: test-webserver
    image: registry.k8s.io/test-webserver:latest
    volumeMounts:
    - mountPath: /var/local/aaa
      name: mydir
    - mountPath: /var/local/aaa/1.txt
      name: myfile
  volumes:
  - name: mydir
    hostPath:
      # 确保文件所在目录成功创建。
      path: /var/local/aaa
      type: DirectoryOrCreate
  - name: myfile
    hostPath:
      path: /var/local/aaa/1.txt
      type: FileOrCreate

1.3.3 nfs

nfs卷使用nfs服务将存储卷挂载到Pod容器的指定目录上。

有持久化数据的能力，且也能实现跨node节点的Pod共享数据。

nfs卷的配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /my-nfs-data
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: my-nfs-server.example.com
      path: /my-nfs-volume
      readOnly: true

注意：不能在 Pod spec 中指定 NFS 挂载可选项。

可以选择设置服务端的挂载可选项，或者使用 /etc/nfsmount.conf。

此外，还可以通过允许设置挂载可选项的持久卷挂载 NFS 卷。

1.3.4 cephfs

cephfs 卷允许将现存的 CephFS 卷挂载到 Pod 中。

cephfs 卷可以被预先填充数据，且这些数据可以在 Pod 之间共享，同一 cephfs 卷可同时被多个挂载。

apiVersion: v1
kind: Pod
metadata:
  name: cephfs
spec:
  containers:
  - name: cephfs-rw
    image: kubernetes/pause
    volumeMounts:
    - mountPath: "/mnt/cephfs"
      name: cephfs
  volumes:
  - name: cephfs
    cephfs:
      monitors:
      - 10.16.154.78:6789
      - 10.16.154.82:6789
      - 10.16.154.83:6789
      # by default the path is /, but you can override and mount a specific path of the filesystem by using the path attribute
      # path: /some/path/in/side/cephfs
      user: admin
      secretFile: "/etc/ceph/admin.secret"
      readOnly: true

二、持久数据卷——PV和PVC

2.1 概念

持久卷（PersistentVolume，PV）：K8S在指定的存储设备空间中逻辑划分创建出来的可持久化的存储资源对象。

持久卷声明（PersistentVolumeClaim，PVC）：对PV存储资源对象的请求和绑定，也是Pod能够挂载使用的一种存储卷类型。

2.2 PV的生命周期和状态

生命周期

#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（可用）	表示为可用状态，PV已经被创建出来了，但是还未被PVC绑定
Bound（已绑定）	表示PV已经被PVC绑定了，PV与PVC是一对一的绑定关系
Released（已释放）	表示PVC被删除了，但是PV还没被回收
Failed（失败）	表示PV被自动回收失败

2.3 访问模式 (Access Modes) 和回收策略 (Reclaim Policy)

访问模式

存储卷在挂载到宿主机系统上时，可以设置不同的访问模式 (Access Modes）。

支持的访问模式	描述
ReadWriteOnce (RWO)	读写权限，并且只能被单个Node挂载
ReadOnlyMany (ROX)	只读权限，允许被多个Node挂载
ReadWriteMany(RWX)	读写权限，允许被多个Node挂载

回收策略

通过PV定义中的persistentVolumeReclaimPolicy字段进行设置。

回收策略	描述
Retain（保留）	保留数据，需要手工处理
Recycle（回收）	简单清除文件的操作（例如运行rm -rf /thevolume/*命令），只有 NFS 和 HostPath 两种类型的 PV支持 Recycle 策略
Delete（删除）	与PV相连的后端存储完成Volume的删除操作，AWSElasticBlockStore、 GCEPersistentDis、 AzureDisk和Cinder类型的PV支持 Delete策略

三、静态创建PV

3.1 创建思路

1）准备好存储设备和共享目录；

2）准备yaml配置文件创建PV资源，设置 存储类型、访问模式(RWO RWX ROX RWOP)、 空间大小、回收策略(Retain Delete Recycle) 、storageClassName等；

3）准备yaml配置文件创建PVC资源，设置 访问模式(必要条件，必须是PV能支持的访问模式)、空间大小(默认就近选择大于等于指定大小的PV) 、storageClassName等来绑定PV；

4）创建Pod资源挂载PVC存储卷，设置存储卷类型为 persistentVolumeClaim ，并在容器配置中定义存储卷挂载点目录。

3.2 创建实例：NFS使用PV和PVC

Step1 配置nfs存储

#创建共享目录
mkdir /opt/test
cd /opt/test
mkdir v{
    
    1,2,3,4,5}

#定义多个共享目录和对应的访问权限
vim /etc/exports
 
/opt/test/v1 192.168.2.0/24(rw,no_root_squash)
/opt/test/v2 192.168.2.0/24(rw,no_root_squash)
/opt/test/v3 192.168.2.0/24(rw,no_root_squash)
/opt/test/v4 192.168.2.0/24(rw,no_root_squash)
/opt/test/v5 192.168.2.0/24(rw,no_root_squash)

#重新加载共享目录，应用修改
exportfs -arv

showmount -e

Step2 定义PV

#这里定义5个PV，并且定义挂载的路径以及访问模式，还有PV划分的大小。
vim pv-demo.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /opt/test/v1
    server: master01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /opt/test/v2
    server: master01
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /opt/test/v3
    server: master01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /opt/test/v4
    server: master01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /opt/test/v5
    server: master01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 5Gi

kubectl apply -f pv-demo.yaml -n my-ns
kubectl get pv -n my-ns

Step3 定义PVC

这里定义了pvc的访问模式为多路读写，该访问模式必须在前面pv定义的访问模式之中。

定义PVC申请的大小为2Gi，此时PVC会自动去匹配多路读写且大小为2Gi的PV，匹配成功获取PVC的状态即为Bound。

vim pod-vol-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
  namespace: my-ns
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-vol-pvc
  namespace: my-ns
spec:
  containers:
  - name: myapp
    image: nginx
    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

Step4 访问测试

在存储服务器上创建index.html，并写入数据，通过访问Pod进行查看，可以获取到相应的页面。

#创建测试页面
cd /opt/test/v3/
echo "welcome to use pv3" > index.html

kubectl get pods -o wide -n my-ns

#访问测试
firefox http://10.244.2.82

四、动态创建PV

4.1 创建思路

1）准备好存储设备和共享目录；

2）如果是外置存储卷插件，需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限，再将账户与角色进行绑定)，使sa账户具有对PV PVC StorageClass等资源的操作权限；

3）准备yaml配置文件创建外置存储卷插件的Pod，设置sa账户作为Pod的用户，并设置相关的环境变量(比如存储卷插件名称);

4）创建StorageClass(简称SC)资源，provisioner自动设置为存储卷插件名称 ；

以上操作是一劳永逸的，之后只需要创建PVC资源时引用StorageClass就可以自动调用存储卷插件动态创建PV资源了

5）准备yaml配置文件创建PVC资源，设置 访问模式、空间大小 storageClassName指定SC资源名称等来动态创建PV资源并绑定PV；

6）创建Pod资源挂载PVC存储卷，设置存储卷类型为 persistentVolumeClaim ，并在容器配置中定义存储卷挂载点目录。

4.2 StorageClass的概念

官方文档：存储类 | Kubernetes

简介

存储类（Storage Class） 是 Kubernetes 中用于定义持久卷（Persistent Volume）的类型和行为的对象。

它定义了动态分配的存储和卷的属性，并指定如何创建和管理这些存储资源。

关于默认的StorageClass

当一个 PVC 没有指定 storageClassName 时，会使用默认的 StorageClass。

集群中只能有一个默认的 StorageClass。

如果不小心设置了多个默认的 StorageClass， 当 PVC 动态配置时，将使用最新设置的默认 StorageClass。

关于字段

每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在 StorageClass 需要动态制备 PersistentVolume 时会使用到。

功能

1）提供动态卷配置：存储类可以与动态卷配置程序（比如 CSI 驱动程序）集成，以便在创建 PVC（Persistent Volume Claim）时自动创建相应的 PV（Persistent Volume）。

2）指定卷的参数： 存储类可以定义卷的各种参数和配置选项，如访问模式、卷大小、复制策略等。

3）支持动态卷生命周期管理： 存储类可以定义如何动态创建、扩容和销毁卷，以及何时回收 PV 等。

4.3 Provisioner的概念

Provisioner（存储分配器）： 卷插件，用于指定 Volume 插件的类型，包括内置插件（如 kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。

详见：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/

Kubernetes 本身支持的动态 PV 创建不包括 NFS，所以需要使用外部存储卷插件分配PV。

4.4 实例：NFS 的动态 PV 创建

搭建 StorageClass + nfs-client-provisioner ，实现 NFS 的动态 PV 创建

Step1 在master01节点上安装nfs，并配置nfs服务

#创建共享目录
mkdir /opt/test2
chmod 777 /opt/test2/

#添加权限
vim /etc/exports
/opt/test2 192.168.2.0/24(rw,no_root_squash,sync)

#重启NFS服务
systemctl restart nfs

exportfs -var
showmount -e

Step2 创建 Service Account

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

##配置清单文件详解##
用于创建一个 Service Account 账户和相关的 Role、RoleBinding，用于管理 NFS Provisioner 在 Kubernetes 集群中的权限。

首先，创建了一个 Service Account 账户，命名为 "nfs-client-provisioner"

然后，创建了一个 Cluster Role，命名为 "nfs-client-provisioner-clusterrole"。
该角色定义了一组权限规则，包括对持久卷（persistentvolume）的获取、列表、监视、创建和删除操作，对持久卷声明（persistentvolumeclaim）的获取、列表、监视和更新操作，对存储类（storageclass）的获取、列表和监视操作，对事件（events）和端点（endpoints）的获取、列表、监视、创建、更新等操作。

最后，创建了一个 Cluster Role Binding，将上述角色与之前创建的 Service Account 进行绑定，并将其绑定到默认命名空间（namespace）中。

kubectl apply -f nfs-client-rbac.yaml
#Service Account "nfs-client-provisioner" 具备了管理 NFS Provisioner 所需的权限。

Step3 使用 Deployment 创建 NFS Provisioner

NFS Provisioner(即 nfs-client)，有两个功能
1）在 NFS 共享目录下创建挂载点(volume)，另一个则是将 PV 与 NFS 的挂载点建立关联。

编写资源配置清单文件

#编写配置清单文件
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: master01           #配置绑定的nfs服务器
            - name: NFS_PATH
              value: /opt/test2/          #配置绑定的nfs服务器目录
      volumes:              #申明nfs数据卷
        - name: nfs-client-root
          nfs:
            server: master01
            path: /opt/test2/

创建

kubectl apply -f nfs-client-provisioner.yaml 

kubectl get po 

补充：报错解决方法

#由于 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.2.100
.....

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

Step4 创建 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时不会对数据目录进行打包存档，即删除数据；为ture时就会自动对数据目录进行打包存档，存档文件以archived开头

#声明式创建
kubectl apply -f nfs-client-storageclass.yaml

kubectl get storageclass

Step5 创建 PVC ，进行Pod 测试

创建PVC

vim test-pvc-pod.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-nfs-pvc
  #annotations: volume.beta.kubernetes.io/storage-class: "nfs-client-storageclass"     #另一种SC配置方式
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

kubectl get pvc 

查看 NFS 服务器上是否生成对应的目录

自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上。

ls /opt/test2

Pod测试

测试思路： 进入 Pod 在挂载目录 /mnt 下写一个文件，然后查看 NFS 服务器上是否存在该文件。

#进入Pod，创建测试文件
kubectl exec -it test-storageclass-pod sh

/ # cd /mnt/
/mnt # echo 'this is test file' > test.txt

#进入到目录
cd /opt/test2/default-test-nfs-pvc-pvc-7a63142b-a4b4-4f07-966c-828ca60bbdcb

五、小结

5.1 PV、PVC的概念和状态

概念

PV： K8S在指定的存储设备空间中逻辑划分创建出来的可持久化的存储资源对象。

PVC： 对PV存储资源对象的请求和绑定，也是Pod能够挂载使用的一种存储卷类型。

创建方式简介

手动根据PV资源的yaml配置文件创建静态PV。

根据PVC的配置通过StorageClass(简称SC)资源调用存储卷插件创建动态PV。

PV的4种状态

PV的状态	描述
Available（可用）	表示为可用状态，PV已经被创建出来了，但是还未被PVC绑定
Bound（已绑定）	表示PV已经被PVC绑定了，PV与PVC是一对一的绑定关系
Released（已释放）	表示PVC被删除了，但是PV还没被回收
Failed（失败）	表示PV被自动回收失败

5.2 静态和动态创建PV的思路

创建使用静态PV

1）准备好存储设备和共享目录；

2）准备yaml配置文件创建PV资源，设置 存储类型、访问模式(RWO RWX ROX RWOP)、 空间大小、回收策略(Retain Delete Recycle) 、storageClassName等；

3）准备yaml配置文件创建PVC资源，设置 访问模式(必要条件，必须是PV能支持的访问模式)、空间大小(默认就近选择大于等于指定大小的PV) 、storageClassName等来绑定PV；

4）创建Pod资源挂载PVC存储卷，设置存储卷类型为 persistentVolumeClaim ，并在容器配置中定义存储卷挂载点目录。

创建使用动态PV

1）准备好存储设备和共享目录；

2）如果是外置存储卷插件，需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限，再将账户与角色进行绑定)，使sa账户具有对PV PVC StorageClass等资源的操作权限；

3）准备yaml配置文件创建外置存储卷插件的Pod，设置sa账户作为Pod的用户，并设置相关的环境变量(比如存储卷插件名称);

4）创建StorageClass(简称SC)资源，provisioner自动设置为存储卷插件名称 ；

以上操作是一劳永逸的，之后只需要创建PVC资源时引用StorageClass就可以自动调用存储卷插件动态创建PV资源了

5）准备yaml配置文件创建PVC资源，设置 访问模式、空间大小 storageClassName指定SC资源名称等来动态创建PV资源并绑定PV；

6）创建Pod资源挂载PVC存储卷，设置存储卷类型为 persistentVolumeClaim ，并在容器配置中定义存储卷挂载点目录。

通过陈述式管理资源配置的方式 修改或添加资源对象的配置
kubectl patch <资源类型> <资源名称> -p '{"第一层字段": {"第二层字段": {....}}}'

kubectl patch deployment deploy-test -p '{"spec": {"replicas": 0}}'
kubectl patch deployment deploy-test -p '{"spec": {"template": {"spec": {"containers": [{"name": "myapp", "image": "soscscs/myapp:v1"}]}}}}'

创建使用动态PV

1）准备好存储设备和共享目录；

2）如果是外置存储卷插件，需要先创建serviceaccount账户(Pod使用的账户)和做RBAC授权(创建角色授予相关资源对象的操作权限，再将账户与角色进行绑定)，使sa账户具有对PV PVC StorageClass等资源的操作权限；

3）准备yaml配置文件创建外置存储卷插件的Pod，设置sa账户作为Pod的用户，并设置相关的环境变量(比如存储卷插件名称);

4）创建StorageClass(简称SC)资源，provisioner自动设置为存储卷插件名称 ；

以上操作是一劳永逸的，之后只需要创建PVC资源时引用StorageClass就可以自动调用存储卷插件动态创建PV资源了

5）准备yaml配置文件创建PVC资源，设置 访问模式、空间大小 storageClassName指定SC资源名称等来动态创建PV资源并绑定PV；

6）创建Pod资源挂载PVC存储卷，设置存储卷类型为 persistentVolumeClaim ，并在容器配置中定义存储卷挂载点目录。

通过陈述式管理资源配置的方式 修改或添加资源对象的配置
kubectl patch <资源类型> <资源名称> -p '{"第一层字段": {"第二层字段": {....}}}'

kubectl patch deployment deploy-test -p '{"spec": {"replicas": 0}}'
kubectl patch deployment deploy-test -p '{"spec": {"template": {"spec": {"containers": [{"name": "myapp", "image": "soscscs/myapp:v1"}]}}}}'