为什么需要volume
容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。 首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建
k8s支持很多类型的卷
awsElasticBlockStore、azureDisk、azureFile、cephfs、cinder、configMap、csi、downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flockegcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secret、storageos、vsphereVolume
K8s 支持的卷基本上可以分为三类：配置信息、临时存储、持久存储。
无论何种类型的应用，都会用到配置文件或启动参数。而 K8s 将配置信息进行了抽象，定义成了几种资源，主要有以下三种：
ConfigMap
Secret
DownwardAPI
ConfigMap
onfigMap 卷通常以一个或多个 key: value 形式存在，主要用来保存应用的配置数据。其中 value 可以是字面量或配置文件。
不过，因为ConfigMap 在设计上不是用来保存大量数据的，所以在 ConfigMap 中保存的数据不可超过 1 MiB（兆字节）。
ConfigMap 有两种创建方式：
通过命令行创建
通过 yaml 文件创建
命令行创建的:
[root@kubeadm-master1 ~]# kubectl create configmap c1 --from-literal=foo=bar --from-literal=bar=bra.txt
configmap/c1 created
[root@kubeadm-master1 ~]# ll
总用量 24
-rw-------. 1 root root 1259 12月 26 2022 anaconda-ks.cfg
-rw-r--r-- 1 root root 71 12月 22 13:46 command.sh
-rw-r--r--. 1 root root 13 4月 26 2023 ifcfg-eth0
-rw-r--r-- 1 root root 1127 12月 21 15:08 kubecfg.crt
-rw-r--r-- 1 root root 1679 12月 21 15:08 kubecfg.key
-rw-r--r-- 1 root root 2496 12月 21 15:08 kubecfg.p12
[root@kubeadm-master1 ~]# kubectl get configmap
NAME DATA AGE
c1 2 18s
kube-root-ca.crt 1 25d
[root@kubeadm-master1 ~]# kubectl describe configmap c1
Name: c1
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
bar:
----
bra.txt
foo:
----
bar
Events: <none>
[root@kubeadm-master1 ~]#
通过configmap-demo.yaml yaml 文件创建的
kind: ConfigMap
apiVersion: v1
metadata:
name:c2
namespace: default
data:
foo:bar
bar:baz
Volume
Kubernetes（也称为K8s）是一个用于自动化部署、扩展和管理容器化应用程序的开源平台。在Kubernetes中，Volume（卷）是一种抽象概念，用于提供容器持久化存储的解决方案。它允许容器在生命周期中存储和访问持久化数据。
下面是对Kubernetes Volume功能的理解：
持久化存储：Volume提供了一种持久化存储数据的方式，使得容器在重新启动、重新调度或维护迁移等场景下仍然能够访问之前的数据。它解决了容器中的数据持久性问题。
抽象化和标准化：Volume在Kubernetes中是一个抽象层，它隐藏了底层存储细节，使得应用程序可以以一个统一的方式来访问和管理不同类型的存储解决方案，如本地存储、网络存储和云存储等。
插件化支持：Kubernetes提供了丰富的Volume插件，可以满足不同场景和需求的存储要求。这些插件包括EmptyDir、HostPath、PersistentVolumeClaim（PVC）、NFS、AWS EBS、Azure Disk等，每个插件都有不同的特点和适用范围。
容器级别的访问控制：Volumes可以以容器级别进行访问控制，不同容器可以使用不同的Volume实例，并根据需要进行读取和写入操作。这使得容器之间的数据隔离、共享和管理变得更加灵活和可控。
动态供给和自动管理：Kubernetes支持动态供给和自动管理Volume。通过PersistentVolume（PV）和PersistentVolumeClaim（PVC）的机制，管理员可以预先配置存储资源并将其提供给应用程序。而应用程序只需要声明自己的存储需求（PVC），Kubernetes会自动选择和绑定适合的PV，并将其动态分配给应用程序。
通过使用Kubernetes Volume功能，应用程序开发者可以更方便地处理数据的持久性和生命周期管理。它提供了一种统一和标准化的方式来管理容器中的持久化存储，使得容器更具可移植性、可扩展性和可靠性。
nfs挂载volume
apiVersion: v1
kind: Pod
metadata:
name: nfs-pd
spec:
containers:
- name: test-container
image: reg.westos.org/k8s/nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: test-volume
volumes:
- name: test-volume
nfs:
server: 172.25.254.4
path: /nfsdata
持久卷的痛点
虽然通过使用持久卷，可以解决临时卷数据易丢失的问题。但目前持久卷的使用方式还存在以下痛点：
Pod 开发人员可能对存储不够了解，却要对接多种存储
安全问题，有些存储可能需要账号密码，这些信息不应该暴露给 Pod
因此为了解决这些不足，K8s 又针对持久化存储抽象出了三种资源 PV、PVC、StorageClass。三种资源定义如下：
PV 描述的是持久化存储数据卷
PVC 描述的是 Pod 想要使用的持久化存储属性，既存储卷申明
StorageClass 作用是根据 PVC 的描述，申请创建对应的 PV
PV 和 PVC 的概念可以对应编程语言中的面向对象思想，PVC 是接口，PV 是具体实现。
有了这三种资源类型后，Pod 就可以通过静态供应和动态供应这两种方式来使用持久卷。
参考文档：
作者：又拍云
链接：https://juejin.cn/post/7186925237592653884
来源：稀土掘金