举报投诉联系我们 手机版 热门标签 名动网
您的位置:名动网 > Kubernetes 临时卷

Kubernetes 临时卷

2023-06-24 22:20 Kubernetes(k8s)手册

 Kubernetes 临时卷

临时卷

本文档描述 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: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 驱动程序限制

FEATURE STATE: Kubernetes v1.21 [deprecated]

作为一个集群管理员,你可以使用 PodSecurityPolicy 来控制在 Pod 中可以使用哪些 CSI 驱动程序, 具体则是通过 ​allowedCSIDrivers 字段​ 指定。

PodSecurityPolicy 已弃用,并将在 Kubernetes v1.25 版本中移除。

CSI 临时卷仅有 CSI 驱动程序的一个子集支持。 Kubernetes CSI 驱动列表显示了哪些驱动程序支持临时卷。

通用临时卷 

FEATURE STATE: 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 的命名

自动创建的 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。 集群管理员必须意识到这一点。 如果这不符合他们的安全模型,他们有如下选择:

  • 通过特性门控显式禁用该特性。
  • 使用一个准入 Webhook 拒绝包含通用临时卷的 Pods。
  • 当 ​volumes ​列表不包含 ​ephemeral ​卷类型时,使用 Pod 安全策略。 (这一方式在 Kubernetes 1.21 版本已经弃用)

为 PVC 卷所设置的逐名字空间的配额 仍然有效,因此即使允许用户使用这种新机制,他们也不能使用它来规避其他策略。


阅读全文
以上是名动网为你收集整理的 Kubernetes 临时卷全部内容。
声明:本站所有文章资源内容,如无特殊说明或标注,均为采集网络资源。如若本站内容侵犯了原著者的合法权益,可联系本站删除。
相关文章
© 2024 名动网 mdwl.vip 版权所有 联系我们