临时卷

本文档描述 Kubernetes 中的 临时卷（Ephemeral Volume）。 建议先了解卷，特别是 PersistentVolumeClaim 和 PersistentVolume。

有些应用程序需要额外的存储，但并不关心数据在重启后是否仍然可用。 例如，缓存服务经常受限于内存大小，而且可以将不常用的数据转移到比内存慢的存储中，对总体性能的影响并不大。

另有些应用程序需要以文件形式注入的只读数据，比如配置数据或密钥。

临时卷 就是为此类用例设计的。因为卷会遵从 Pod 的生命周期，与 Pod 一起创建和删除， 所以停止和重新启动 Pod 时，不会受持久卷在何处可用的限制。

临时卷在 Pod 规约中以 内联 方式定义，这简化了应用程序的部署和管理。

临时卷的类型

Kubernetes 为了不同的用途，支持几种不同类型的临时卷：

emptyDir、configMap、downwardAPI、secret 是作为 本地临时存储 提供的。它们由各个节点上的 kubelet 管理。

CSI 临时卷 必须 由第三方 CSI 存储驱动程序提供。

通用临时卷 可以 由第三方 CSI 存储驱动程序提供，也可以由支持动态制备的任何其他存储驱动程序提供。 一些专门为 CSI 临时卷编写的 CSI 驱动程序，不支持动态制备：因此这些驱动程序不能用于通用临时卷。

使用第三方驱动程序的优势在于，它们可以提供 Kubernetes 本身不支持的功能， 例如，与 kubelet 管理的磁盘具有不同性能特征的存储，或者用来注入不同的数据。

CSI 临时卷

特性状态： Kubernetes v1.25 [stable]

从概念上讲，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 临时卷允许用户直接向 CSI 驱动程序提供 volumeAttributes，它会作为 Pod 规约的一部分。 有些 volumeAttributes 通常仅限于管理员使用，允许这一类 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 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。 当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC， 然后 PVC 通常会触发卷的删除，因为存储类的默认回收策略是删除卷。 你可以使用带有 retain 回收策略的 StorageClass 创建准临时 (Quasi-Ephemeral) 本地存储： 该存储比 Pod 寿命长，所以在这种情况下，你需要确保单独进行卷清理。

当这些 PVC 存在时，它们可以像其他 PVC 一样使用。 特别是，它们可以被引用作为批量克隆或快照的数据源。 PVC 对象还保持着卷的当前状态。

PersistentVolumeClaim 的命名

自动创建的 PVC 采取确定性的命名机制：名称是 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 就无法启动。

安全

只要用户有权限创建 Pod，就可以使用通用的临时卷间接地创建持久卷申领（PVCs）， 即使他们没有权限直接创建 PVCs。集群管理员必须注意这一点。如果这与他们的安全模型相悖， 他们应该使用准入 Webhook。

正常的 PVC 的名字空间配额 仍然有效，因此即使允许用户使用这种新机制，他们也不能使用它来规避其他策略。

接下来

kubelet 管理的临时卷

参阅本地临时存储。

CSI 临时卷

通用临时卷

最后修改 October 17, 2023 at 6:48 PM PST: sync ephemeral-volumes volumes windows-storage (a46f569625)