临时卷
本文档介绍了 Kubernetes 中的临时卷。建议熟悉 卷，特别是 PersistentVolumeClaim 和 PersistentVolume。
一些应用程序需要额外的存储，但不关心这些数据是否在重启后持久存储。例如，缓存服务通常受内存大小限制，可以将不常用的数据移动到比内存慢的存储中，而对整体性能影响不大。
其他应用程序希望某些只读输入数据以文件的形式存在，例如配置数据或密钥。
临时卷专为这些用例而设计。由于卷遵循 Pod 的生命周期，并与 Pod 一起创建和删除，因此可以停止和重启 Pod，而不受限于某些持久卷的可用性。
临时卷在 Pod 规范中内联指定，这简化了应用程序的部署和管理。
临时卷的类型
Kubernetes 支持多种不同类型的临时卷，用于不同的目的
- emptyDir：在 Pod 启动时为空，存储来自 kubelet 基本目录（通常是根磁盘）或 RAM
- configMap、downwardAPI、secret：将不同类型的 Kubernetes 数据注入到 Pod 中
- image：允许将容器镜像文件或工件直接挂载到 Pod。
- CSI 临时卷：与之前的卷类型类似，但由特殊的 CSI 驱动程序提供，这些驱动程序专门支持此功能
- 通用临时卷，可以由所有也支持持久卷的存储驱动程序提供
emptyDir、configMap、downwardAPI、secret 作为本地临时存储提供。它们由每个节点上的 kubelet 管理。
CSI 临时卷必须由第三方 CSI 存储驱动程序提供。
通用临时卷可以由第三方 CSI 存储驱动程序提供，也可以由任何支持动态配置的其他存储驱动程序提供。一些 CSI 驱动程序是专门为 CSI 临时卷编写的，不支持动态配置：这些驱动程序不能用于通用临时卷。
使用第三方驱动程序的优点是，它们可以提供 Kubernetes 本身不支持的功能，例如具有与 kubelet 管理的磁盘不同的性能特征的存储，或注入不同的数据。
CSI 临时卷
Kubernetes v1.25 [stable]注意
CSI 临时卷仅由部分 CSI 驱动程序支持。Kubernetes CSI 驱动程序列表显示了哪些驱动程序支持临时卷。从概念上讲，CSI 临时卷类似于 configMap、downwardAPI 和 secret 卷类型：存储在每个节点本地管理，并在 Pod 被调度到节点后与其他本地资源一起创建。在此阶段，Kubernetes 不再有重新调度 Pod 的概念。卷的创建必须不太可能失败，否则 Pod 启动会被卡住。特别是，这些卷不支持存储容量感知 Pod 调度。它们目前也不在 Pod 的存储资源使用限制范围内，因为这是 kubelet 只能对其自己管理的存储强制执行的功能。
这是一个使用 CSI 临时存储的 Pod 的示例清单
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox:1.28
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
command: [ "sleep", "1000000" ]
volumes:
- name: my-csi-inline-vol
csi:
driver: inline.storage.kubernetes.io
volumeAttributes:
foo: bar
volumeAttributes 确定驱动程序准备的卷。这些属性特定于每个驱动程序，并且不是标准化的。有关进一步说明，请参阅每个 CSI 驱动程序的文档。
CSI 驱动程序限制
CSI 临时卷允许用户直接将 volumeAttributes 作为 Pod 规范的一部分提供给 CSI 驱动程序。允许通常仅限于管理员使用的 volumeAttributes 的 CSI 驱动程序不适合在内联临时卷中使用。例如，通常在 StorageClass 中定义的参数不应通过使用内联临时卷暴露给用户。
需要在 Pod 规范中限制允许用作内联卷的 CSI 驱动程序的集群管理员可以通过以下方式实现：
- 从 CSIDriver 规范中的
volumeLifecycleModes中删除Ephemeral，这将阻止驱动程序用作内联临时卷。 - 使用准入 webhook来限制此驱动程序的使用方式。
通用临时卷
Kubernetes v1.23 [stable]通用临时卷类似于 emptyDir 卷，它们为每个 Pod 提供一个用于临时数据的目录，该目录在配置后通常为空。但它们也可能具有其他功能
示例
kind: Pod
apiVersion: v1
metadata:
name: my-app
spec:
containers:
- name: my-frontend
image: busybox:1.28
volumeMounts:
- mountPath: "/scratch"
name: scratch-volume
command: [ "sleep", "1000000" ]
volumes:
- name: scratch-volume
ephemeral:
volumeClaimTemplate:
metadata:
labels:
type: my-frontend-volume
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "scratch-storage-class"
resources:
requests:
storage: 1Gi
生命周期和 PersistentVolumeClaim
关键的设计思想是，允许在 Pod 的卷源中包含卷声明的参数。支持 PersistentVolumeClaim 的标签、注解和整套字段。当创建这样的 Pod 时，临时卷控制器会在与 Pod 相同的命名空间中创建一个实际的 PersistentVolumeClaim 对象，并确保在 Pod 被删除时删除该 PersistentVolumeClaim。
这将触发卷绑定和/或配置，如果 StorageClass 使用立即卷绑定，则立即触发；或者当 Pod 被临时调度到节点上时触发 (WaitForFirstConsumer 卷绑定模式)。后者推荐用于通用临时卷，因为这样调度器可以自由地为 Pod 选择合适的节点。通过立即绑定，调度器一旦卷可用，就必须选择一个可以访问该卷的节点。
在资源所有权方面，具有通用临时存储的 Pod 是提供该临时存储的 PersistentVolumeClaim 的所有者。当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC，这通常会触发卷的删除，因为存储类的默认回收策略是删除卷。你可以使用回收策略为 retain 的 StorageClass 创建准临时本地存储：该存储的生命周期比 Pod 长，在这种情况下，你需要确保单独进行卷清理。
在这些 PVC 存在期间，它们可以像任何其他 PVC 一样使用。特别是，它们可以作为卷克隆或快照的数据源被引用。PVC 对象还保存卷的当前状态。
PersistentVolumeClaim 命名
自动创建的 PVC 的命名是确定的：名称是 Pod 名称和卷名称的组合，中间用连字符 (-) 连接。在上面的示例中，PVC 名称将是 my-app-scratch-volume。这种确定性的命名使得与 PVC 的交互更加容易，因为一旦知道 Pod 名称和卷名称，就不必再搜索它。
确定性的命名还引入了不同 Pod 之间（具有卷 “scratch” 的 Pod “pod-a” 和另一个名称为 “pod” 且卷为 “a-scratch” 的 Pod 都以相同的 PVC 名称 “pod-a-scratch” 结束）以及 Pod 和手动创建的 PVC 之间潜在的冲突。
检测到此类冲突：PVC 仅在其为 Pod 创建时才用于临时卷。此检查基于所有权关系。现有的 PVC 不会被覆盖或修改。但这并不能解决冲突，因为没有正确的 PVC，Pod 就无法启动。
注意
在同一个命名空间中命名 Pod 和卷时要小心，这样就不会发生这些冲突。安全
使用通用临时卷允许用户间接创建 PVC（如果他们可以创建 Pod），即使他们没有直接创建 PVC 的权限。集群管理员必须意识到这一点。如果这不符合他们的安全模型，他们应该使用一个准入 webhook来拒绝具有通用临时卷的 Pod 等对象。
对于 PVC 的正常命名空间配额仍然适用，因此即使允许用户使用这种新机制，他们也无法使用它来规避其他策略。
下一步是什么
由 kubelet 管理的临时卷
请参阅本地临时存储。
CSI 临时卷
- 有关设计的更多信息，请参阅临时内联 CSI 卷 KEP。
- 有关此功能进一步开发的更多信息，请参阅增强功能跟踪问题 #596。
通用临时卷
- 有关设计的更多信息，请参阅通用临时内联卷 KEP。