k8s 存储类(StorageClass)如何动态创建PV深度解析
Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。Kubernetes(简称K8s)的前世今生可以追溯到谷歌(Google)内部的一个项目,它起源于2003年,当时谷歌正面临着不断增长的应用程序和服务的管理挑战。这个项目最初被称为"Borg",是一个早期的容器编排系统。Borg 的成功经验成为 Kubernetes 开发的契机。有关k8s起源的介绍,请参考《初识K8s
🐇明明跟你说过:个人主页
🏅个人专栏:《Kubernetes航线图:从船长到K8s掌舵者》 🏅
🔖行路有良友,便是天堂🔖
目录
2、StorageClass与PersistentVolumeClaim(PVC)的关系
一、前言
1、k8s概述
Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。
Kubernetes(简称K8s)的前世今生可以追溯到谷歌(Google)内部的一个项目,它起源于2003年,当时谷歌正面临着不断增长的应用程序和服务的管理挑战。这个项目最初被称为"Borg",是一个早期的容器编排系统。Borg 的成功经验成为 Kubernetes 开发的契机。
有关k8s起源的介绍,请参考《初识K8s之前世今生、架构、组件、前景》这篇文章
Kubernetes的优点包括可移植性、可伸缩性和扩展性。它使用轻型的YAML清单文件实现声明性部署方法,对于应用程序更新,无需重新构建基础结构。管理员可以计划和部署容器,根据需要扩展容器并管理其生命周期。借助Kubernetes的开放源代码API,用户可以通过首选编程语言、操作系统、库和消息传递总线来构建应用程序,还可以将现有持续集成和持续交付(CI/CD)工具集成。
2、k8s存储类:storageclass
StorageClass是Kubernetes中的一种机制,它允许管理员定义一组存储卷的模板,以便动态地根据PVC的请求创建PV。使用StorageClass,管理员可以根据应用程序的需求,定义不同类型、性能和参数的存储卷模板,而不需要手动创建大量的PV。
StorageClass可以定义存储卷的类型、存储提供商、存储参数等信息,并将这些信息与一个特定的存储提供商或存储后端关联起来。当创建PVC并指定所需的存储类时,Kubernetes将根据存储类的定义自动创建满足要求的PV,并将其绑定到PVC上,从而实现存储资源的动态分配和管理。
通过使用StorageClass,管理员可以更加灵活地管理存储资源,提高资源利用率,减少手动操作的复杂性,降低维护成本,从而更好地满足不同应用的存储需求。
二、StorageClass基础
1、StorageClass的组成
-
名称(Name): 每个 StorageClass 都有一个唯一的名称,用于标识该存储类。
-
Provisioner: Provisioner 是负责动态创建 PV 的组件或插件。当 PVC 请求特定存储类时,Provisioner 将根据存储类的定义自动创建相应的 PV。
-
参数(Parameters): Parameters 是一组键值对,用于指定存储资源的配置参数,例如存储类型、容量、性能特性等。
-
Reclaim Policy(回收策略): 回收策略指定当 PV 与 PVC 解绑时如何处理 PV 中的数据。常见的回收策略包括 Delete(删除 PV)、Retain(保留 PV)、Recycle(回收 PV 中的数据)等。
-
Provisioning(供给): 它指定是否允许 StorageClass 动态创建 PV。如果 Provisioning 被设置为 true,则允许 StorageClass 动态创建 PV;如果设置为 false,则不允许动态创建 PV,只能手动创建。
2、StorageClass与PersistentVolumeClaim(PVC)的关系
StorageClass与PersistentVolumeClaim(PVC)在Kubernetes存储管理中起着不同的作用,并且它们之间有着紧密的关系。
PersistentVolumeClaim(PVC)是用户对存储资源的请求。它描述了用户希望获得的存储资源的特性,如大小、访问模式等。PVC允许用户在不关心底层存储实现细节的情况下,声明所需的存储资源。
而StorageClass则是对存储“类”的描述。它包含了用于动态分配PersistentVolume(PV)的信息,包括存储分配器(Provisioner)和相关的参数配置。通过StorageClass,管理员可以定义不同的存储类别,以满足不同的存储需求和服务质量等级。
当PVC被创建时,Kubernetes会根据PVC中指定的存储类(通过storageClassName字段)查找匹配的StorageClass。如果找到了匹配的StorageClass,并且该StorageClass配置了动态分配PV的策略,Kubernetes会自动调用存储分配器来动态创建PV,并将其与PVC进行绑定。这样,用户就可以通过PVC获得所需的存储资源,而无需手动创建PV。
3、StorageClass的动态卷分配机制
StorageClass在Kubernetes中提供了一种动态卷分配机制,使得能够根据PVC(PersistentVolumeClaim)的请求动态地创建PV(PersistentVolume)。以下是StorageClass动态卷分配机制的主要步骤:
- PVC请求:用户创建PVC时,会指定所需的存储大小和访问模式等参数,并引用一个StorageClass。PVC表示用户对存储资源的请求。
- 匹配StorageClass:Kubernetes根据PVC中指定的storageClassName查找匹配的StorageClass。StorageClass定义了存储资源的特性,如存储类型、容量、访问模式等。
- 调用Provisioner:如果找到了匹配的StorageClass,并且该StorageClass配置了动态分配PV的策略,Kubernetes会调用StorageClass中定义的Provisioner。Provisioner是一个负责创建PV的组件,它可以是Kubernetes内置的,也可以是第三方提供的。
- 动态创建PV:Provisioner根据StorageClass中的参数和PVC的请求,动态创建PV。这通常涉及与后端存储系统的交互,以准备和分配所需的存储资源。
- 绑定PVC和PV:一旦PV被成功创建,Kubernetes会将其与PVC进行绑定。绑定后,PVC就可以使用分配给它的PV提供的存储资源了。
通过这种方式,StorageClass能够根据PVC的请求动态地创建和管理PV,无需用户手动进行存储资源的创建和配置。
三、StorageClass的提供者
1、内置存储提供者
内置存储提供者(Built-in Storage Providers): 这些提供者是 Kubernetes 自身所提供的,并且已经在 Kubernetes 集群中预先安装和配置好。内置存储提供者通常用于模拟本地存储或测试环境,并不适合生产环境的持久化存储需求。
内置存储提供者通常包括以下几种:
- emptyDir:用于创建临时性存储卷,生命周期与 Pod 相关联,适合临时性数据存储或共享数据等场景。
- hostPath:用于将主机的文件系统路径挂载到 Pod 中,可以用于存储主机上的持久化数据。
- local:用于直接挂载本地存储卷到 Pod 中,不需要经过网络传输,适合于要求低延迟、高性能的应用场景。
2、第三方存储提供者
StorageClass 的提供者中的第三方存储提供者是指由第三方厂商或社区开发的插件或驱动程序,用于与 Kubernetes 集群中的 StorageClass 集成,以支持不同类型的持久化存储需求。这些存储提供者通常是 CSI (Container Storage Interface) 插件的一部分,通过实现 CSI 规范与 Kubernetes 集成。
第三方存储提供者具有以下特点:
- 丰富的存储后端支持: 第三方存储提供者通常支持多种存储后端,包括云存储、网络存储、块存储等,可以满足不同场景下的持久化存储需求。
- 灵活的配置选项: 这些提供者通常提供丰富的配置选项,可以根据实际需求进行灵活配置,包括存储容量、性能要求、数据保护策略等。
- 可扩展性强: 第三方存储提供者通常是基于 CSI 规范开发的,具有良好的可扩展性,可以方便地与 Kubernetes 集群中的其他组件集成,如调度器、卷管理器等。
- 功能丰富: 这些提供者通常提供丰富的功能,如快照管理、数据复制、数据加密等,可以满足复杂应用场景下的存储需求。
常见的第三方存储提供者包括但不限于:
- AWS EBS CSI Driver:用于与 Amazon Elastic Block Store (EBS) 集成。
- Azure Disk CSI Driver:用于与 Azure Disk 集成。
- Google Cloud Persistent Disk CSI Driver:用于与 Google Cloud Persistent Disk 集成。
- OpenEBS:一个开源的云原生存储平台,提供多种存储引擎,如本地 PV、Replica、Jiva 等。
- Rook:一个开源的存储编排器,支持在 Kubernetes 集群中部署和管理 Ceph、EdgeFS、NFS 等存储系统。
四、StorageClass特性
1、持久卷访问模式
StorageClass 定义了持久卷(PersistentVolume)的属性和访问模式。持久卷的访问模式指定了 Pod 如何访问该持久卷。常见的持久卷访问模式包括以下几种:
- ReadWriteOnce (RWO):该访问模式表示卷可以被单个节点以读写方式挂载。这意味着卷只能同时被一个 Pod 挂载,并且可以在此节点上进行读取和写入操作。
- ReadOnlyMany (ROX):该访问模式表示卷可以被多个节点以只读方式挂载。这意味着卷可以被多个 Pod 同时挂载,但只能在挂载节点上进行读取操作,不能进行写入操作。
- ReadWriteMany (RWX):该访问模式表示卷可以被多个节点以读写方式挂载。这意味着卷可以被多个 Pod 同时挂载,并且可以在任何挂载节点上进行读取和写入操作。
不同的持久卷提供者和存储引擎可能支持不同的访问模式,因此在创建 StorageClass 时需要根据实际需求选择合适的访问模式。例如,某些存储提供者可能仅支持 RWO 访问模式,而另一些则支持 RWX 访问模式。
2、卷绑定模式
StorageClass 的卷绑定模式(Volume Binding Mode)定义了持久卷(PersistentVolume)如何与 PersistentVolumeClaim(PVC)进行绑定。Kubernetes 支持两种主要的绑定模式:
- Immediate(立即绑定):在此模式下,PVC 会立即绑定到可用的 PV。当 PVC 创建时,Kubernetes 会尝试查找符合其要求的可用 PV,并将其绑定到 PVC。如果没有匹配的可用 PV,则 PVC 将保持未绑定状态,直到匹配的 PV 可用为止。此模式下的绑定是立即发生的,但可能会导致 PVC 长时间处于未绑定状态。
- WaitForFirstConsumer(等待第一个消费者):在此模式下,PVC 会等待第一个 Pod(消费者)使用它。当 PVC 创建时,它不会立即绑定到任何 PV,而是等待第一个使用该 PVC 的 Pod 出现。一旦 Pod 使用了 PVC,Kubernetes 就会根据 Pod 的需求选择并绑定适合的 PV。这种方式确保了 PV 仅在需要时才被分配,但可能会导致 Pod 创建时间较长。
选择绑定模式取决于具体的需求和应用场景。如果需要立即将 PVC 绑定到可用的 PV,并且不介意 PVC 可能长时间处于未绑定状态,那么可以选择 Immediate 模式。如果希望 PV 仅在被 Pod 使用时才被分配,并且不介意等待 PV 分配的时间,那么可以选择 WaitForFirstConsumer 模式。
3、回收策略
StorageClass 的回收策略定义了在 PVC 删除时如何处理相应的 PV。Kubernetes 支持以下几种回收策略:
- Retain(保留):在这种策略下,当 PVC 删除时,关联的 PV 不会被自动删除。相应的 PV 将被标记为 Released 状态,需要手动处理。这允许管理员手动处理 PV 的后续操作,如数据备份或归档。
- Delete(删除):在这种策略下,当 PVC 删除时,关联的 PV 会被自动删除。Kubernetes 将释放 PV 使用的存储资源,并删除 PV 对象及其底层存储资源。这样做可以自动释放存储资源并减少存储资源的浪费。
- Recycle(回收):此回收策略已经在 Kubernetes 1.19 版本中被废弃,不再推荐使用。在此策略下,当 PVC 删除时,关联的 PV 上的数据会被清除,并重用 PV。这种策略不够灵活,并且可能导致数据泄漏,因此不再建议使用。
- DeleteWithStorage(带存储删除):此回收策略用于动态卷。在此策略下,当 PVC 删除时,关联的 PV 会被删除,同时 PV 使用的存储资源也会被释放。这种策略与 Delete 类似,但专为动态卷设计。
管理员可以根据实际需求和应用场景选择适当的回收策略。
💕💕💕每一次的分享都是一次成长的旅程,感谢您的陪伴和关注。希望这些关于Kubernetes的文章能陪伴您走过技术的一段旅程,共同见证成长和进步!😺😺😺
🧨🧨🧨让我们一起在技术的海洋中探索前行,共同书写美好的未来!!!
更多推荐
所有评论(0)