临时卷
本文档描述了 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 [稳定]
注意
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 的目录,该目录在配置后通常是空的。但它们也可能具有其他功能:
- 存储可以是本地的或网络附加的。
- 卷可以具有 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(s) 的所有者。当 Pod 被删除时,Kubernetes 垃圾回收器会删除 PVC,这通常会触发卷的删除,因为存储类的默认回收策略是删除卷。你可以使用回收策略为 retain
的 StorageClass 创建准临时本地存储:存储会比 Pod 寿命长,在这种情况下,你需要确保卷清理单独进行。
当这些 PVC 存在时,它们可以像任何其他 PVC 一样使用。特别是,它们可以作为卷克隆或快照的数据源引用。PVC 对象还包含卷的当前状态。
PersistentVolumeClaim 命名
自动创建的 PVC 的命名是确定的:名称是 Pod 名称和卷名称的组合,中间用连字符(-
)连接。在上面的示例中,PVC 名称将是 my-app-scratch-volume
。这种确定的命名使得与 PVC 交互变得更容易,因为一旦 Pod 名称和卷名称已知,就不必再搜索它。
确定的命名也引入了不同 Pod 之间(名为 "pod-a" 的 Pod 带有卷 "scratch",另一个名为 "pod" 的 Pod 带有卷 "a-scratch",它们都以相同的 PVC 名称 "pod-a-scratch" 结束)以及 Pod 与手动创建的 PVC 之间的潜在冲突。
这些冲突会被检测到:PVC 仅在为 Pod 创建时才用于临时卷。此检查基于所有权关系。现有 PVC 不会被覆盖或修改。但这并不能解决冲突,因为没有正确的 PVC,Pod 就无法启动。
注意
在同一命名空间中命名 Pod 和卷时要小心,以免发生这些冲突。安全
使用通用临时卷允许用户间接创建 PVC,如果他们可以创建 Pod,即使他们没有直接创建 PVC 的权限。集群管理员必须意识到这一点。如果这不符合他们的安全模型,他们应该使用准入 Webhook 来拒绝具有通用临时卷的 Pod 等对象。
对 PVC 的常规命名空间配额仍然适用,因此即使允许用户使用这种新机制,他们也不能用它来规避其他策略。
下一步
由 kubelet 管理的临时卷
请参阅本地临时存储。
CSI 临时卷
- 有关设计的更多信息,请参阅临时内联 CSI 卷 KEP。
- 有关此功能进一步开发的更多信息,请参阅增强跟踪问题 #596。
通用临时卷
- 有关设计的更多信息,请参阅通用临时内联卷 KEP。