卷

容器中的磁盘文件是短暂的，这对于在容器中运行的非平凡应用程序来说会带来一些问题。一个问题是当容器崩溃或停止时。容器状态不会保存，因此在容器的生命周期中创建或修改的所有文件都会丢失。崩溃期间，kubelet 会以干净的状态重启容器。另一个问题发生在多个容器在 Pod 中运行并且需要共享文件时。在所有容器之间设置和访问共享文件系统可能具有挑战性。Kubernetes 卷 抽象解决了这两个问题。建议熟悉 Pod。

背景

Kubernetes 支持多种类型的卷。一个 Pod 可以同时使用任意数量的卷类型。临时卷 的生命周期与 Pod 相同，但 持久卷 的存在时间超过 Pod 的生命周期。当 Pod 不再存在时，Kubernetes 会销毁临时卷；但是，Kubernetes 不会销毁持久卷。对于给定 Pod 中的任何类型的卷，数据都会在容器重启后保留。

从本质上讲，卷是一个目录，其中可能包含一些数据，Pod 中的容器可以访问该目录。该目录是如何生成的、支持它的介质以及它的内容取决于所使用的特定卷类型。

要使用卷，请在 .spec.volumes 中指定要为 Pod 提供的卷，并在 .spec.containers[*].volumeMounts 中声明将这些卷挂载到容器中的位置。容器中的进程会看到一个文件系统视图，该视图由 容器镜像 的初始内容以及挂载在容器内部的卷（如果已定义）组成。该进程会看到一个最初与容器镜像内容匹配的根文件系统。如果允许，对该文件系统层次结构中的任何写入操作都会影响该进程在执行后续文件系统访问时看到的内容。卷会挂载在镜像内的 指定路径 上。对于 Pod 中定义的每个容器，您必须独立指定每个容器使用的每个卷的挂载位置。

卷不能挂载在其他卷内（但请参阅 使用 subPath 了解相关机制）。此外，卷不能包含指向不同卷中任何内容的硬链接。

卷类型

Kubernetes 支持多种类型的卷。

awsElasticBlockStore（已弃用）

在 Kubernetes 1.30 中，针对树内 awsElasticBlockStore 类型的所有操作都将重定向到 ebs.csi.aws.com CSI 驱动程序。

AWSElasticBlockStore 树内存储驱动程序在 Kubernetes v1.19 版本中已弃用，并在 v1.27 版本中完全移除。

Kubernetes 项目建议您改用 AWS EBS 第三方存储驱动程序。

azureDisk（已弃用）

在 Kubernetes 1.30 中，针对树内 azureDisk 类型的所有操作都将重定向到 disk.csi.azure.com CSI 驱动程序。

AzureDisk 树内存储驱动程序在 Kubernetes v1.19 版本中已弃用，并在 v1.27 版本中完全移除。

Kubernetes 项目建议您改用 Azure 磁盘 第三方存储驱动程序。

azureFile（已弃用）

azureFile 卷类型将 Microsoft Azure 文件卷（SMB 2.1 和 3.0）挂载到 Pod 中。

有关更多详细信息，请参阅 azureFile 卷插件。

azureFile CSI 迁移

azureFile 的 CSIMigration 功能启用后，会将所有插件操作从现有的树内插件重定向到 file.csi.azure.com 容器存储接口 (CSI) 驱动程序。要使用此功能，必须在集群上安装 Azure 文件 CSI 驱动程序，并且必须启用 CSIMigrationAzureFile 功能门控。

Azure 文件 CSI 驱动程序不支持对不同的 fsgroups 使用相同的卷。如果启用了 CSIMigrationAzureFile，则完全不支持对不同的 fsgroups 使用相同的卷。

azureFile CSI 迁移完成

要禁用控制器管理器和 kubelet 加载 azureFile 存储插件，请将 InTreePluginAzureFileUnregister 标志设置为 true。

cephfs（已弃用）

cephfs 卷允许将现有的 CephFS 卷挂载到 Pod 中。与在移除 Pod 时会被擦除的 emptyDir 不同，cephfs 卷的内容会被保留，并且该卷只是被卸载。这意味着 cephfs 卷可以预先填充数据，并且该数据可以在 Pod 之间共享。cephfs 卷可以由多个写入器同时挂载。

有关更多详细信息，请参阅 CephFS 示例。

cinder（已弃用）

在 Kubernetes 1.30 中，针对树内 cinder 类型的所有操作都将重定向到 cinder.csi.openstack.org CSI 驱动程序。

OpenStack Cinder 树内存储驱动程序在 Kubernetes v1.11 版本中已弃用，并在 v1.26 版本中完全移除。

Kubernetes 项目建议您改用 OpenStack Cinder 第三方存储驱动程序。

configMap

ConfigMap 提供了一种将配置数据注入 Pod 的方法。存储在 ConfigMap 中的数据可以在类型为 configMap 的卷中引用，然后由 Pod 中运行的容器化应用程序使用。

引用 ConfigMap 时，请在卷中提供 ConfigMap 的名称。您可以自定义用于 ConfigMap 中特定条目的路径。以下配置显示了如何将 log-config ConfigMap 挂载到名为 configmap-pod 的 Pod 上

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox:1.28
      command: ['sh', '-c', 'echo "The app is running!" && tail -f /dev/null']
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

log-config ConfigMap 作为卷挂载，存储在其 log_level 条目中的所有内容都挂载到路径 /etc/config/log_level 下的 Pod 中。请注意，此路径是从卷的 mountPath 和以 log_level 为键的 path 派生而来的。

downwardAPI

downwardAPI 卷使 下行 API 数据可供应用程序使用。在卷中，您可以找到以纯文本格式作为只读文件公开的数据。

请参阅将 Pod 信息暴露给容器以了解更多信息。

emptyDir

对于定义了 emptyDir 卷的 Pod，该卷会在 Pod 被分配到节点时创建。顾名思义，emptyDir 卷最初是空的。Pod 中的所有容器都可以在 emptyDir 卷中读取和写入相同的文件，尽管该卷可以安装在每个容器中相同或不同的路径下。当 Pod 因任何原因从节点中移除时，emptyDir 中的数据将被永久删除。

emptyDir 的一些用途是

• 临时空间，例如基于磁盘的归并排序
• 为从崩溃中恢复而检查点长时间计算
• 保存内容管理器容器在 Web 服务器容器提供数据时获取的文件

emptyDir.medium 字段控制 emptyDir 卷的存储位置。默认情况下，emptyDir 卷存储在支持节点的任何介质上，例如磁盘、SSD 或网络存储，具体取决于您的环境。如果您将 emptyDir.medium 字段设置为 "Memory"，Kubernetes 会为您挂载一个 tmpfs（RAM 支持的文件系统）。虽然 tmpfs 速度非常快，但请注意，与磁盘不同，您写入的文件将计入写入它们的容器的内存限制。

可以为默认介质指定大小限制，这会限制 emptyDir 卷的容量。存储空间从节点临时存储中分配。如果该存储空间被其他来源（例如，日志文件或镜像层）填满，则 emptyDir 可能会在此限制之前耗尽容量。

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

fc（光纤通道）

fc 卷类型允许将现有的光纤通道块存储卷挂载到 Pod 中。您可以在卷配置中使用参数 targetWWNs 指定单个或多个目标全球名称 (WWN)。如果指定了多个 WWN，则 targetWWNs 预计这些 WWN 来自多路径连接。

有关更多详细信息，请参阅光纤通道示例。

gcePersistentDisk（已弃用）

在 Kubernetes 1.30 中，针对内置 gcePersistentDisk 类型的所有操作都将重定向到 pd.csi.storage.gke.io CSI 驱动程序。

gcePersistentDisk 内置存储驱动程序在 Kubernetes v1.17 版本中已弃用，并在 v1.28 版本中完全移除。

Kubernetes 项目建议您改用Google Compute Engine Persistent Disk CSI第三方存储驱动程序。

gitRepo（已弃用）

gitRepo 卷是卷插件的一个示例。此插件会挂载一个空目录，并将 git 存储库克隆到此目录中供您的 Pod 使用。

以下是 gitRepo 卷的示例

apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    gitRepo:
      repository: "git@somewhere:me/my-git-repository.git"
      revision: "22f1d8406d464b0c0874075539c1f2e96c253775"

glusterfs（已移除）

Kubernetes 1.30 不包含 glusterfs 卷类型。

GlusterFS 内置存储驱动程序在 Kubernetes v1.25 版本中已弃用，并在 v1.26 版本中完全移除。

hostPath

hostPath 卷将主机节点文件系统中的文件或目录挂载到您的 Pod 中。这不是大多数 Pod 所需的，但它为某些应用程序提供了一个强大的应急机制。

hostPath 的一些用途是

• 运行需要访问节点级系统组件的容器（例如，将系统日志传输到中心位置的容器，使用 /var/log 的只读挂载访问这些日志）
• 使存储在主机系统上的配置文件对静态 Pod只读可用；与普通 Pod 不同，静态 Pod 无法访问 ConfigMap

hostPath 卷类型

除了必需的 path 属性之外，您还可以选择为 hostPath 卷指定 type。

type 的可用值为

在底层主机上创建的某些文件或目录可能只能由 root 用户访问。然后，您需要在特权容器中以 root 用户身份运行您的进程，或者修改主机上的文件权限才能从 hostPath 卷读取（或写入）。

hostPath 配置示例

• Linux 节点
• Windows 节点

---
# This manifest mounts /data/foo on the host as /foo inside the
# single container that runs within the hostpath-example-linux Pod.
#
# The mount into the container is read-only.
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example-linux
spec:
  os: { name: linux }
  nodeSelector:
    kubernetes.io/os: linux
  containers:
  - name: example-container
    image: registry.k8s.io/test-webserver
    volumeMounts:
    - mountPath: /foo
      name: example-volume
      readOnly: true
  volumes:
  - name: example-volume
    # mount /data/foo, but only if that directory already exists
    hostPath:
      path: /data/foo # directory location on host
      type: Directory # this field is optional

---
# This manifest mounts C:\Data\foo on the host as C:\foo, inside the
# single container that runs within the hostpath-example-windows Pod.
#
# The mount into the container is read-only.
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example-windows
spec:
  os: { name: windows }
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: example-container
    image: microsoft/windowsservercore:1709
    volumeMounts:
    - name: example-volume
      mountPath: "C:\\foo"
      readOnly: true
  volumes:
    # mount C:\Data\foo from the host, but only if that directory already exists
  - name: example-volume
    hostPath:
      path: "C:\\Data\\foo" # directory location on host
      type: Directory       # this field is optional

hostPath FileOrCreate 配置示例

以下清单定义了一个 Pod，该 Pod 在 Pod 的单个容器中挂载了 /var/local/aaa。如果节点上还没有路径 /var/local/aaa，则 kubelet 会将其创建为目录，然后将其挂载到 Pod 中。

如果 /var/local/aaa 已经存在但不是目录，则 Pod 将失败。此外，kubelet 会尝试在该目录中创建一个名为 /var/local/aaa/1.txt 的文件（从主机的角度来看）；如果该路径下已经存在内容并且不是常规文件，则 Pod 将失败。

以下是示例清单

apiVersion: v1
kind: Pod
metadata:
  name: test-webserver
spec:
  os: { name: linux }
  nodeSelector:
    kubernetes.io/os: linux
  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:
      # Ensure the file directory is created.
      path: /var/local/aaa
      type: DirectoryOrCreate
  - name: myfile
    hostPath:
      path: /var/local/aaa/1.txt
      type: FileOrCreate

iscsi

iscsi 卷允许将现有的 iSCSI（SCSI over IP）卷挂载到您的 Pod 中。与在 Pod 被移除时会被擦除的 emptyDir 不同，iscsi 卷的内容会被保留，并且该卷只是被卸载。这意味着可以使用数据预先填充 iscsi 卷，并且可以在 Pod 之间共享该数据。

iSCSI 的一个特性是它可以被多个使用者同时以只读方式挂载。这意味着您可以使用您的数据集预先填充卷，然后根据需要从任意数量的 Pod 并行提供该卷。遗憾的是，iSCSI 卷只能由单个使用者以读写模式挂载。不允许同时写入。

有关更多详细信息，请参阅iSCSI 示例。

local

local 卷表示挂载的本地存储设备，例如磁盘、分区或目录。

本地卷只能用作静态创建的 PersistentVolume。不支持动态配置。

与 hostPath 卷相比，local 卷的使用方式持久且可移植，无需手动将 Pod 调度到节点。系统可以通过查看 PersistentVolume 上的节点关联性来了解卷的节点约束。

但是，local 卷受到底层节点可用性的限制，并不适合所有应用程序。如果节点变得不健康，则 Pod 将无法访问 local 卷。使用此卷的 Pod 将无法运行。使用 local 卷的应用程序必须能够容忍这种降低的可用性，以及潜在的数据丢失（取决于底层磁盘的持久性特征）。

以下示例显示了一个使用 local 卷和 nodeAffinity 的 PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

使用 local 卷时，必须设置 PersistentVolume nodeAffinity。Kubernetes 调度程序使用 PersistentVolume nodeAffinity 将这些 Pod 调度到正确的节点。

PersistentVolume volumeMode 可以设置为“Block”（而不是默认值“Filesystem”），以将本地卷作为原始块设备公开。

使用本地卷时，建议创建一个 volumeBindingMode 设置为 WaitForFirstConsumer 的 StorageClass。有关更多详细信息，请参阅本地 StorageClass 示例。延迟卷绑定可确保 PersistentVolumeClaim 绑定决策也会根据 Pod 可能具有的任何其他节点约束进行评估，例如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。

可以单独运行外部静态供应器，以改进本地卷生命周期的管理。请注意，此供应器尚不支持动态供应。有关如何运行外部本地供应器的示例，请参阅本地卷供应器用户指南。

nfs

nfs 卷允许将现有的 NFS（网络文件系统）共享挂载到 Pod 中。与在删除 Pod 时会被擦除的 emptyDir 不同，nfs 卷的内容会被保留，并且该卷仅被卸载。这意味着可以使用数据预先填充 NFS 卷，并且可以在 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

有关使用 PersistentVolume 挂载 NFS 卷的示例，请参阅NFS 示例。

persistentVolumeClaim

persistentVolumeClaim 卷用于将 PersistentVolume 挂载到 Pod 中。PersistentVolumeClaim 是一种让用户“声明”持久存储（例如 iSCSI 卷）的方法，而无需了解特定云环境的详细信息。

有关更多详细信息，请参阅有关 PersistentVolume 的信息。

portworxVolume（已弃用）

portworxVolume 是一个弹性块存储层，可与 Kubernetes 超融合运行。Portworx 对服务器中的存储进行指纹识别，根据功能进行分层，并在多台服务器之间聚合容量。Portworx 在虚拟机中的来宾系统或裸机 Linux 节点上运行。

portworxVolume 可以通过 Kubernetes 动态创建，也可以预先配置并在 Pod 中引用。下面是一个引用预先配置的 Portworx 卷的 Pod 示例

apiVersion: v1
kind: Pod
metadata:
  name: test-portworx-volume-pod
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /mnt
      name: pxvol
  volumes:
  - name: pxvol
    # This Portworx volume must already exist.
    portworxVolume:
      volumeID: "pxvol"
      fsType: "<fs-type>"

有关更多详细信息，请参阅Portworx 卷示例。

Portworx CSI 迁移

Portworx 的 CSIMigration 功能已添加，但自 Kubernetes 1.23 起默认禁用，因为它处于 alpha 状态。自 v1.25 起，它现在处于测试阶段，但默认情况下仍然关闭。它将所有插件操作从现有的树内插件重定向到 pxd.portworx.com 容器存储接口 (CSI) 驱动程序。必须在集群上安装Portworx CSI 驱动程序。要启用此功能，请在 kube-controller-manager 和 kubelet 中设置 CSIMigrationPortworx=true。

projected

projected 卷将多个现有卷源映射到同一个目录中。有关更多详细信息，请参阅projected 卷。

rbd

rbd 卷允许将 Rados 块设备 (RBD) 卷挂载到您的 Pod 中。与在删除 Pod 时会被擦除的 emptyDir 不同，rbd 卷的内容会被保留，并且该卷会被卸载。这意味着可以使用数据预先填充 RBD 卷，并且可以在 Pod 之间共享数据。

RBD 的一个特性是它可以由多个使用者同时以只读方式挂载。这意味着您可以使用数据集预先填充卷，然后根据需要从任意数量的 Pod 并行提供该卷。遗憾的是，RBD 卷只能由一个使用者以读写模式挂载。不允许同时写入。

有关更多详细信息，请参阅RBD 示例。

RBD CSI 迁移

RBD 的 CSIMigration 功能在启用后，会将所有插件操作从现有的树内插件重定向到 rbd.csi.ceph.com CSI 驱动程序。要使用此功能，必须在集群上安装Ceph CSI 驱动程序，并且必须启用 CSIMigrationRBD 功能门控。（请注意，csiMigrationRBD 标志已在 v1.24 版本中删除，并替换为 CSIMigrationRBD）

secret

secret 卷用于将敏感信息（例如密码）传递给 Pod。您可以将密钥存储在 Kubernetes API 中，并将它们作为文件挂载以供 Pod 使用，而无需直接耦合到 Kubernetes。secret 卷由 tmpfs（一个基于 RAM 的文件系统）支持，因此它们永远不会写入非易失性存储。

有关更多详细信息，请参阅配置 Secret。

vsphereVolume（已弃用）

vsphereVolume 用于将 vSphere VMDK 卷挂载到您的 Pod 中。卸载卷时，卷的内容会被保留。它支持 VMFS 和 VSAN 数据存储。

有关更多信息，请参阅vSphere 卷示例。

vSphere CSI 迁移

在 Kubernetes 1.30 中，树内 vsphereVolume 类型的所有操作都将重定向到 csi.vsphere.vmware.com CSI 驱动程序。

必须在集群上安装vSphere CSI 驱动程序。您可以在 VMware 的文档页面将树内 vSphere 卷迁移到 vSphere 容器存储插件中找到有关如何迁移树内 vsphereVolume 的更多建议。如果未安装 vSphere CSI 驱动程序，则无法对使用树内 vsphereVolume 类型创建的 PV 执行卷操作。

您必须运行 vSphere 7.0u2 或更高版本才能迁移到 vSphere CSI 驱动程序。

如果您运行的 Kubernetes 版本不是 v1.30，请参阅该版本 Kubernetes 的文档。

vSphere CSI 迁移完成

要关闭控制器管理器和 kubelet 加载 vsphereVolume 插件，您需要将 InTreePluginvSphereUnregister 功能标志设置为 true。您必须在所有工作节点上安装 csi.vsphere.vmware.com CSI 驱动程序。

使用 subPath

有时，在单个 Pod 中共享一个卷以用于多种用途非常有用。volumeMounts[*].subPath 属性指定了引用卷内部的子路径，而不是其根路径。

以下示例显示了如何使用单个共享卷配置具有 LAMP 堆栈（Linux Apache MySQL PHP）的 Pod。不建议将此示例 subPath 配置用于生产环境。

PHP 应用程序的代码和资产映射到卷的 html 文件夹，而 MySQL 数据库存储在卷的 mysql 文件夹中。例如

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: "rootpasswd"
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php:7.0-apache
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

将 subPath 与扩展的环境变量一起使用

使用 subPathExpr 字段从向下 API 环境变量构造 subPath 目录名称。subPath 和 subPathExpr 属性互斥。

在此示例中，Pod 使用 subPathExpr 在 hostPath 卷 /var/log/pods 内创建一个目录 pod1。 hostPath 卷从 downwardAPI 获取 Pod 名称。主机目录 /var/log/pods/pod1 挂载到容器中的 /logs。

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: container1
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    image: busybox:1.28
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
      mountPath: /logs
      # The variable expansion uses round brackets (not curly brackets).
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
  - name: workdir1
    hostPath:
      path: /var/log/pods

资源

emptyDir 卷的存储介质（例如磁盘或 SSD）由保存 kubelet 根目录（通常为 /var/lib/kubelet）的文件系统的介质决定。emptyDir 或 hostPath 卷可以使用的空间量没有限制，并且容器之间或 Pod 之间没有隔离。

要了解如何使用资源规范请求空间，请参阅如何管理资源。

树外卷插件

树外卷插件包括容器存储接口 (CSI) 以及 FlexVolume（已弃用）。这些插件使存储供应商能够创建自定义存储插件，而无需将其插件源代码添加到 Kubernetes 存储库中。

以前，所有卷插件都是“树内”的。“树内”插件是使用核心 Kubernetes 二进制文件构建、链接、编译和发布的。这意味着向 Kubernetes 添加新的存储系统（卷插件）需要将代码签入核心 Kubernetes 代码存储库。

CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署（安装）在 Kubernetes 集群上。

对于希望创建树外卷插件的存储供应商，请参阅卷插件常见问题解答。

csi

容器存储接口 (CSI) 定义了一个标准接口，用于容器编排系统（如 Kubernetes）将其容器工作负载暴露给任意存储系统。

请阅读CSI 设计提案以获取更多信息。

在 Kubernetes 集群上部署与 CSI 兼容的卷驱动程序后，用户可以使用 csi 卷类型附加或挂载 CSI 驱动程序公开的卷。

csi 卷可以通过三种不同的方式在 Pod 中使用

• 通过引用PersistentVolumeClaim
• 使用通用临时卷
• 如果驱动程序支持，则使用CSI 临时卷

存储管理员可以使用以下字段来配置 CSI 持久卷

• driver：一个字符串值，指定要使用的卷驱动程序的名称。此值必须与CSI 规范中定义的 CSI 驱动程序在 GetPluginInfoResponse 中返回的值对应。Kubernetes 使用它来识别要调用的 CSI 驱动程序，而 CSI 驱动程序组件使用它来识别哪些 PV 对象属于 CSI 驱动程序。
• volumeHandle：唯一标识卷的字符串值。此值必须与CSI 规范中定义的 CSI 驱动程序在 CreateVolumeResponse 的 volume.id 字段中返回的值对应。在引用卷时，该值作为 volume_id 传递给对 CSI 卷驱动程序的所有调用。
• readOnly：一个可选的布尔值，指示卷是否要“ControllerPublished”（附加）为只读。默认为 false。此值通过 ControllerPublishVolumeRequest 中的 readonly 字段传递给 CSI 驱动程序。
• fsType：如果 PV 的 VolumeMode 为 Filesystem，则可以使用此字段指定应用于挂载卷的文件系统。如果卷尚未格式化并且支持格式化，则将使用此值格式化卷。此值通过 ControllerPublishVolumeRequest、NodeStageVolumeRequest 和 NodePublishVolumeRequest 的 VolumeCapability 字段传递给 CSI 驱动程序。
• volumeAttributes：一个字符串到字符串的映射，指定卷的静态属性。此映射必须与CSI 规范中定义的 CSI 驱动程序在 CreateVolumeResponse 的 volume.attributes 字段中返回的映射对应。该映射通过 ControllerPublishVolumeRequest、NodeStageVolumeRequest 和 NodePublishVolumeRequest 中的 volume_context 字段传递给 CSI 驱动程序。
• controllerPublishSecretRef：对包含敏感信息的 Secret 对象的引用，该对象传递给 CSI 驱动程序以完成 CSI ControllerPublishVolume 和 ControllerUnpublishVolume 调用。此字段是可选的，如果不需要 Secret，则可以为空。如果 Secret 包含多个 Secret，则会传递所有 Secret。
• nodeExpandSecretRef：对包含敏感信息的 Secret 的引用，该 Secret 传递给 CSI 驱动程序以完成 CSI NodeExpandVolume 调用。此字段是可选的，如果不需要 Secret，则可以为空。如果对象包含多个 Secret，则会传递所有 Secret。为节点发起的卷扩展配置 Secret 数据后，kubelet 会通过对 CSI 驱动程序的 NodeExpandVolume() 调用传递该数据。为了使用 nodeExpandSecretRef 字段，您的集群应运行 Kubernetes 1.25 或更高版本。
• 如果您运行的是 Kubernetes 1.25 或 1.26 版本，则必须为每个 kube-apiserver 和每个节点上的 kubelet 启用名为 CSINodeExpandSecret 的功能门控。在 Kubernetes 1.27 版本中，此功能默认启用，不需要显式启用功能门控。您还必须使用在节点发起的存储调整大小操作期间支持或需要 Secret 数据的 CSI 驱动程序。
• nodePublishSecretRef：对包含敏感信息的 Secret 对象的引用，该对象传递给 CSI 驱动程序以完成 CSI NodePublishVolume 调用。此字段是可选的，如果不需要 Secret，则可以为空。如果 Secret 对象包含多个 Secret，则会传递所有 Secret。
• nodeStageSecretRef：对包含敏感信息的 Secret 对象的引用，该对象传递给 CSI 驱动程序以完成 CSI NodeStageVolume 调用。此字段是可选的，如果不需要 Secret，则可以为空。如果 Secret 包含多个 Secret，则会传递所有 Secret。

CSI 原始块卷支持

具有外部 CSI 驱动程序的供应商可以在 Kubernetes 工作负载中实现原始块卷支持。

您可以像往常一样设置支持原始块卷的 PersistentVolume/PersistentVolumeClaim，而无需进行任何特定于 CSI 的更改。

CSI 临时卷

您可以直接在 Pod 规范中配置 CSI 卷。以这种方式指定的卷是临时的，并且在 Pod 重新启动后不会持久化。有关更多信息，请参阅临时卷。

有关如何开发 CSI 驱动程序的更多信息，请参阅kubernetes-csi 文档

Windows CSI 代理

CSI 节点插件需要执行各种特权操作，例如扫描磁盘设备和挂载文件系统。这些操作因每个主机操作系统而异。对于 Linux 工作节点，容器化 CSI 节点插件通常部署为特权容器。对于 Windows 工作节点，使用csi-proxy支持容器化 CSI 节点插件的特权操作，csi-proxy 是一个社区管理的独立二进制文件，需要预先安装在每个 Windows 节点上。

有关更多详细信息，请参阅您要部署的 CSI 插件的部署指南。

从树内插件迁移到 CSI 驱动程序

CSIMigration 功能将针对现有树内插件的操作定向到相应的 CSI 插件（预计已安装和配置）。因此，在过渡到取代树内插件的 CSI 驱动程序时，操作员无需对现有存储类、持久卷或持久卷声明（引用树内插件）进行任何配置更改。

支持的操作和功能包括：卷的配置/删除、附加/分离、挂载/卸载和调整大小。

支持 CSIMigration 并已实现相应 CSI 驱动程序的树内插件列在卷类型中。

以下树内插件支持 Windows 节点上的持久存储

• azureFile
• gcePersistentDisk
• vsphereVolume

flexVolume（已弃用）

FlexVolume 是一个树外插件接口，它使用基于 exec 的模型与存储驱动程序交互。FlexVolume 驱动程序二进制文件必须安装在每个节点以及某些情况下控制平面节点上的预定义卷插件路径中。

Pod 通过 flexVolume 树内卷插件与 FlexVolume 驱动程序交互。有关更多详细信息，请参阅 FlexVolume README 文档。

以下 FlexVolume 插件作为主机上的 PowerShell 脚本部署，支持 Windows 节点

• SMB
• iSCSI

挂载传播

挂载传播允许将容器挂载的卷共享给同一 Pod 中的其他容器，甚至共享给同一节点上的其他 Pod。

卷的挂载传播由 containers[*].volumeMounts 中的 mountPropagation 字段控制。其值为

• None - 此卷挂载将不会接收主机挂载到此卷或其任何子目录的任何后续挂载。同样，容器创建的任何挂载在主机上都不可见。这是默认模式。

  此模式等效于 mount(8) 中描述的 rprivate 挂载传播。

  但是，当 rprivate 传播不适用时，CRI 运行时可以选择 rslave 挂载传播（即 HostToContainer）。已知 cri-dockerd (Docker) 会在挂载源包含 Docker 守护进程的根目录（/var/lib/docker）时选择 rslave 挂载传播。

• HostToContainer - 此卷挂载将接收所有后续挂载，这些挂载将挂载到此卷或其任何子目录。

  换句话说，如果主机在卷挂载内挂载任何内容，则容器将在该处看到它已挂载。

  同样，如果任何使用 Bidirectional 挂载传播到同一卷的 Pod 在该处挂载任何内容，则具有 HostToContainer 挂载传播的容器将看到它。

  此模式等效于 mount(8) 中描述的 rslave 挂载传播。

• Bidirectional - 此卷挂载的行为与 HostToContainer 挂载相同。此外，容器创建的所有卷挂载都将传播回主机以及使用相同卷的所有 Pod 的所有容器。

  此模式的典型用例是具有 FlexVolume 或 CSI 驱动程序的 Pod，或需要使用 hostPath 卷在主机上挂载内容的 Pod。

  此模式等效于 mount(8) 中描述的 rshared 挂载传播。

  警告

  Bidirectional 挂载传播可能很危险。它可能会损坏主机操作系统，因此仅在特权容器中允许使用。强烈建议熟悉 Linux 内核行为。此外，Pod 中的容器创建的任何卷挂载都必须在终止时由容器销毁（卸载）。

只读挂载

通过将 .spec.containers[].volumeMounts[].readOnly 字段设置为 true，可以将挂载设置为只读。这不会使卷本身变为只读，但该特定容器将无法写入该卷。Pod 中的其他容器可以将同一卷挂载为读写。

在 Linux 上，默认情况下，只读挂载不是递归只读的。例如，考虑一个将主机 /mnt 挂载为 hostPath 卷的 Pod。如果在 /mnt/<SUBMOUNT> 上挂载了另一个读写文件系统（例如 tmpfs、NFS 或 USB 存储），则挂载到容器中的卷也将具有可写的 /mnt/<SUBMOUNT>，即使挂载本身被指定为只读。

递归只读挂载

可以通过为 kubelet 和 kube-apiserver 设置 RecursiveReadOnlyMounts 功能门控，并为 Pod 设置 .spec.containers[].volumeMounts[].recursiveReadOnly 字段来启用递归只读挂载。

允许的值为

• Disabled（默认）：无效果。

• Enabled：使挂载递归只读。需要满足以下所有要求

  • readOnly 设置为 true
  • mountPropagation 未设置，或者设置为 None
  • 主机运行 Linux 内核 v5.12 或更高版本
  • CRI 级 容器运行时支持递归只读挂载
  • OCI 级容器运行时支持递归只读挂载。如果其中任何一个不成立，它将失败。

• IfPossible：尝试应用 Enabled，如果内核或运行时类不支持该功能，则回退到 Disabled。

示例

storage/rro.yaml

apiVersion: v1
kind: Pod
metadata:
  name: rro
spec:
  volumes:
    - name: mnt
      hostPath:
        # tmpfs is mounted on /mnt/tmpfs
        path: /mnt
  containers:
    - name: busybox
      image: busybox
      args: ["sleep", "infinity"]
      volumeMounts:
        # /mnt-rro/tmpfs is not writable
        - name: mnt
          mountPath: /mnt-rro
          readOnly: true
          mountPropagation: None
          recursiveReadOnly: Enabled
        # /mnt-ro/tmpfs is writable
        - name: mnt
          mountPath: /mnt-ro
          readOnly: true
        # /mnt-rw/tmpfs is writable
        - name: mnt
          mountPath: /mnt-rw

当 kubelet 和 kube-apiserver 识别到此属性时，.status.containerStatuses[].volumeMounts[].recursiveReadOnly 字段将设置为 Enabled 或 Disabled。

实现

以下容器运行时已知支持递归只读挂载。

CRI 级

• containerd，自 v2.0 起

OCI 级

• runc，自 v1.1 起
• crun，自 v1.8.6 起

下一步

按照使用持久卷部署 WordPress 和 MySQL的示例进行操作。