临时卷
本文档描述 Kubernetes 中的 临时卷(Ephemeral Volume)。 建议先了解卷,特别是 PersistentVolumeClaim 和 PersistentVolume。
有些应用程序需要额外的存储,但并不关心数据在重启后仍然可用,既是否被持久地保存。 例如,缓存服务经常受限于内存大小,将不常用的数据转移到比内存慢、但对总体性能的影响很小的存储中。
另有些应用程序需要以文件形式注入的只读数据,比如配置数据或密钥。
临时卷 就是为此类用例设计的。因为卷会遵从 Pod 的生命周期,与 Pod 一起创建和删除, 所以停止和重新启动 Pod 时,不会受持久卷在何处可用的限制。
临时卷在 Pod 规范中以 内联 方式定义,这简化了应用程序的部署和管理。
临时卷的类型
Kubernetes 为了不同的目的,支持几种不同类型的临时卷:
- emptyDir: Pod 启动时为空,存储空间来自本地的 kubelet 根目录(通常是根磁盘)或内存
- configMap、 downwardAPI、 secret: 将不同类型的 Kubernetes 数据注入到 Pod 中
- CSI 临时卷: 类似于前面的卷类型,但由专门支持此特性 的指定 CSI 驱动程序提供
- 通用临时卷: 它可以由所有支持持久卷的存储驱动程序提供
emptyDir
、configMap
、downwardAPI
、secret
是作为 本地临时存储 提供的。它们由各个节点上的 kubelet 管理。
CSI 临时卷 必须 由第三方 CSI 存储驱动程序提供。
通用临时卷 可以 由第三方 CSI 存储驱动程序提供,也可以由支持动态配置的任何其他存储驱动程序提供。 一些专门为 CSI 临时卷编写的 CSI 驱动程序,不支持动态供应:因此这些驱动程序不能用于通用临时卷。
使用第三方驱动程序的优势在于,它们可以提供 Kubernetes 本身不支持的功能, 例如,与 kubelet 管理的磁盘具有不同运行特征的存储,或者用来注入不同的数据
CSI 临时卷
FEATURE STATE: Kubernetes v1.16 [beta]
该特性需要启用参数 CSIInlineVolume
特性门控(feature gate)。 该参数从 Kubernetes 1.16 开始默认启用。
说明: 只有一部分 CSI 驱动程序支持 CSI 临时卷。Kubernetes CSI 驱动程序列表 显示了支持临时卷的驱动程序。
从概念上讲,CSI 临时卷类似于 configMap
、downwardAPI
和 secret
类型的卷: 其存储在每个节点本地管理,并在将 Pod 调度到节点后与其他本地资源一起创建。 在这个阶段,Kubernetes 没有重新调度 Pods 的概念。卷创建不太可能失败,否则 Pod 启动将会受阻。 特别是,这些卷 不 支持感知存储容量的 Pod 调度。 它们目前也没包括在 Pod 的存储资源使用限制中,因为 kubelet 只能对它自己管理的存储强制执行。
下面是使用 CSI 临时存储的 Pod 的示例清单:
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
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 驱动程序的文档。
作为一个集群管理员,你可以使用 PodSecurityPolicy 来控制在 Pod 中可以使用哪些 CSI 驱动程序, 具体则是通过 allowedCSIDrivers
字段 指定。
通用临时卷
FEATURE STATE: Kubernetes v1.19 [alpha]
这个特性需要启用 GenericEphemeralVolume
特性门控。 因为这是一个alpha特性,默认禁用。
通用临时卷类似于 emptyDir
卷,但更加灵活:
- 存储可以是本地的,也可以是网络连接的。
- 卷可以有固定的大小,pod不能超量使用。
- 卷可能有一些初始数据,这取决于驱动程序和参数。
- 当驱动程序支持,卷上的典型操作将被支持,包括(快照、克隆、调整大小和存储容量跟踪)。
示例:
kind: Pod
apiVersion: v1
metadata:
name: my-app
spec:
containers:
- name: my-frontend
image: busybox
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 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。 当 Pod 被删除时,Kubernetes 垃圾收集器会删除 PVC, 然后 PVC 通常会触发卷的删除,因为存储类的默认回收策略是删除卷。 你可以使用带有 retain
回收策略的 StorageClass 创建准临时 (quasi-ephemeral) 本地存储: 该存储比 Pod 寿命长,在这种情况下,你需要确保单独进行卷清理。
当这些 PVC 存在时,它们可以像其他 PVC 一样使用。 特别是,它们可以被引用作为批量克隆或快照的数据源。 PVC对象还保持着卷的当前状态。
PersistentVolumeClaim 的命名
自动创建的 PVCs 的命名是确定的:此名称是 Pod 名称和卷名称的组合,中间由连字符(-
)连接。 在上面的示例中,PVC 将命名为 my-app-scratch-volume
。 这种确定性命名方式使得与 PVC 交互变得更容易,因为一旦知道 Pod 名称和卷名,就不必搜索它。
这种确定性命名方式也引入了潜在的冲突, 比如在不同的 Pod 之间(名为 “Pod-a” 的 Pod 挂载名为 “scratch” 的卷, 名为 “pod” 的 Pod 挂载名为 “a-scratch” 的卷,这两者均会生成名为 “pod-a-scratch” 的PVC), 或者在 Pod 和手工创建的 PVC 之间。
以下冲突会被检测到:如果 PVC 是为 Pod 创建的,那么它只用于临时卷。 此检测基于所有权关系。现有的 PVC 不会被覆盖或修改。 但这并不能解决冲突,因为如果没有正确的 PVC,Pod 就无法启动。
注意: 当命名 Pods 和卷出现在同一个命名空间中时,要小心,以防止发生此类冲突。
安全
启用 GenericEphemeralVolume 特性会导致那些没有 PVCs 创建权限的用户, 在创建 Pods 时,被允许间接的创建 PVCs。 集群管理员必须意识到这一点。 如果这不符合他们的安全模型,他们有两种选择:
- 通过特性门控显式禁用该特性,可以避免将来的 Kubernetes 版本默认启用时带来混乱。
- 当
卷
列表不包含ephemeral
卷类型时,使用 Pod 安全策略。
在一个命名空间中,用于 PVCs 的常规命名空间配额仍然适用, 因此即使允许用户使用这种新机制,他们也不能使用它来规避其他策略。
接下来
kubelet 管理的临时卷
参阅本地临时存储。
CSI 临时卷
- 有关设计的更多信息,参阅 Ephemeral Inline CSI volumes KEP。
- 本特性下一步开发的更多信息,参阅 enhancement tracking issue #596。
通用临时卷
- 有关设计的更多信息,参阅 Generic ephemeral inline volumes KEP。
- 本特性下一步开发的更多信息,参阅 enhancement tracking issue #1698.