本文档描述 Kubernetes 中的 临时卷(Ephemeral Volume)。 建议先了解卷,特别是 PersistentVolumeClaim 和 PersistentVolume。
有些应用程序需要额外的存储,但并不关心数据在重启后仍然可用。 例如,缓存服务经常受限于内存大小,将不常用的数据转移到比内存慢、但对总体性能的影响很小的存储中。
另有些应用程序需要以文件形式注入的只读数据,比如配置数据或密钥。
临时卷 就是为此类用例设计的。因为卷会遵从 Pod 的生命周期,与 Pod 一起创建和删除, 所以停止和重新启动 Pod 时,不会受持久卷在何处可用的限制。
临时卷在 Pod 规范中以 内联 方式定义,这简化了应用程序的部署和管理。
Kubernetes 为了不同的目的,支持几种不同类型的临时卷:
emptyDir
、configMap
、downwardAPI
、secret
是作为 本地临时存储 提供的。它们由各个节点上的 kubelet 管理。
CSI 临时卷 必须 由第三方 CSI 存储驱动程序提供。
通用临时卷 可以 由第三方 CSI 存储驱动程序提供,也可以由支持动态配置的任何其他存储驱动程序提供。 一些专门为 CSI 临时卷编写的 CSI 驱动程序,不支持动态供应:因此这些驱动程序不能用于通用临时卷。
使用第三方驱动程序的优势在于,它们可以提供 Kubernetes 本身不支持的功能, 例如,与 kubelet 管理的磁盘具有不同运行特征的存储,或者用来注入不同的数据
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 驱动程序的文档。
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 提供临时数据存放目录, 在最初制备完毕时一般为空。不过通用临时卷也有一些额外的功能特性:
示例:
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
关键的设计思想是在 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对象还保持着卷的当前状态。
自动创建的 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。 集群管理员必须意识到这一点。 如果这不符合他们的安全模型,他们有如下选择:
volumes
列表不包含 ephemeral
卷类型时,使用 Pod 安全策略。 (这一方式在 Kubernetes 1.21 版本已经弃用) 为 PVC 卷所设置的逐名字空间的配额 仍然有效,因此即使允许用户使用这种新机制,他们也不能使用它来规避其他策略。
新闻名称:创新互联kubernetes教程:Kubernetes临时卷
网站地址:http://www.shufengxianlan.com/qtweb/news23/426023.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联