kubernetes共享存储原理

Kubernetes在处理有状态应用和数据持久化的需求时，采取了一套灵活高效的策略，主要通过PersistentVolume(PV)、PersistentVolumeClaim(PVC)和StorageClass这下面几个关键概念来实现。

1. PersistentVolume (PV)：存储资源的容器

想象一下，PV就像是一个装满了存储空间的大箱子，它代表了集群中可用的存储资源，这些资源可能是来自不同类型的存储系统，比如云上的硬盘、企业内部的NAS设备等。

管理员负责准备这些“箱子”，并告诉Kubernetes每个箱子的大小、速度（快还是慢）、是否支持多用户同时访问（读写模式）等特性。这些信息就像是箱子上的标签，帮助Kubernetes了解每个存储资源的能力。

2. PersistentVolumeClaim (PVC)：用户的需求清单

PVC则是应用开发者用来向Kubernetes提出存储需求的请求单。开发者不需要知道具体的存储设备在哪里，也不必关心怎么连接到存储，他们只需要填写一张清单，说明需要多少存储空间、希望的数据访问模式（比如只读还是读写）等。

Kubernetes会根据这张清单，从已有的PV中找到最合适的那个“箱子”，然后分配给应用使用。这就像是你告诉超市你需要一袋5公斤的大米，超市就会从仓库里找到符合要求的商品给你一样。

3. StorageClass：存储服务的菜单

StorageClass就像是存储服务的菜单，上面列出了不同种类的存储选项，每种都标有特性（比如“高速SSD存储”、“经济型HDD存储”）和价格（在云服务商中可能体现为不同价格层次）。

管理员可以根据实际需求，预先设定好这些存储类别的配置。用户在创建PVC时，可以选择一个StorageClass，就像是在餐厅点菜一样，选择了自己想要的存储服务类型。Kubernetes会根据所选的类别，自动匹配或创建相应的PV。

A. Container Storage Interface (CSI)

最后，CSI就像是一个翻译官，它让Kubernetes能够和各种外部存储系统顺畅沟通。不同的存储供应商（比如AWS、Google Cloud、NFS等）有着各自的接口和协议，CSI提供了一套标准化的接口，使得Kubernetes能够不关心底层存储的具体实现，就能对接并管理这些存储服务。

这就像无论你是讲英语、法语还是中文，有了CSI这位翻译，Kubernetes都能听懂你的存储需求，并且帮你搞定。

小总结

Kubernetes通过PV、PVC、StorageClass以及CSI等机制，构建了一个高度灵活且易用的存储管理系统，

使得应用开发者能够轻松申请和使用存储资源，而管理员则可以集中管理存储资源，确保资源的有效分配和利用，

满足了现代云原生应用对数据持久化和存储灵活性的高标准要求。

前面三点我们会在实践课讲到更详细的解释，这里简单的再次眼熟一下下

PersistentVolume (PV)

• 资源抽象与配置: PV 是对底层物理或网络存储资源的抽象，如云存储、本地磁盘等，由管理员预先创建并配置。它定义了存储的大小、访问模式（如 ReadWriteOnce, ReadOnlyMany, ReadWriteMany）和存储类（StorageClass）等属性。
• 生命周期独立: PV 的生命周期不依赖于任何使用它的 Pod，可独立存在，支持重绑定和资源复用。
• 静态分配: 管理员手动创建 PV，并通过标签或其它匹配规则手动将其与 PVC 绑定，适用于已有存储资源的整合。

PersistentVolume （PV） 是群集中由管理员置备或使用存储类动态置备的存储块。它是集群中的资源，就像节点是集群资源一样。PV 是像 Volume 一样的卷插件，但其生命周期独立于使用 PV 的任何单个 Pod。此 API 对象捕获存储实现的详细信息，无论是 NFS、iSCSI 还是特定于云提供商的存储系统。

官网pvc实践

PersistentVolumeClaim (PVC)

• 需求声明: 用户通过 PVC 来声明对存储资源的需求，包括所需容量、访问模式和期望的存储类，而无需关心底层存储的具体细节。
• 动态供给: 结合 StorageClass，PVC 可触发自动创建 PV 的过程，依据声明的需求动态分配存储资源，极大提升了存储资源的分配灵活性和效率。
• 资源隔离与解耦: PVC 为应用提供了与存储资源的解耦层，使得应用的存储需求与实际存储资源的管理分离，有利于应用的可移植性和扩展性。

PersistentVolumeClaim （PVC） 是用户对存储的请求。它类似于 Pod。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，它们可以装载 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 或 ReadWriteOncePod，请参阅 AccessModes）。

Kubernetes 设计了 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 机制来满足有状态应用和数据持久化的需求，这两种资源对象不仅实现了存储资源的抽象与管理，而且还支持静态分配与动态供给两种模式，以适应不同场景下的存储需求。以下是对 PV、PVC 特性、特点、作用以及静态与动态分配方式的综合概述：

静态分配 vs 动态供给

• 静态分配适合于有特定存储配置要求或已有的存储资源。管理员需先创建 PV，再手动绑定 PVC。这种方式提供了对存储资源的直接控制，但管理成本较高，灵活性较低。
  

• 动态供给通过 StorageClass 实现，允许 PVC 自动触发 PV 的创建，减轻了管理负担，提高了资源利用效率。适用于存储需求频繁变动或规模难以预估的场景。
  

StorageClass 详解

StorageClass 是 Kubernetes 存储资源管理的核心组件之一，它体现了存储资源的策略和分类，是一种高级抽象，旨在简化存储资源的分配和管理流程。StorageClass 通过提供一种标准化的方法来描述存储的“类别”或“模板”，使得用户可以按需请求存储资源，而无需深入了解底层存储系统的具体实现细节。以下是关于 StorageClass 的深入解析：

核心概念与功能

• 抽象与标准化：StorageClass 实际上定义了一系列的参数和策略，用于指导 Kubernetes 如何创建和管理 PersistentVolume（PV）。这些参数包括但不限于存储类型（如 SSD、HDD）、IOPS 性能、存储区域（Zone）、回收策略（Retain, Recycle, Delete）以及是否允许卷扩展等，从而使得存储资源的配置标准化、模板化。

• 动态供给：当用户创建 PersistentVolumeClaim（PVC）时，通过引用一个特定的 StorageClass 名称，可以触发 Kubernetes 自动创建一个符合需求的 PV。这一过程无需管理员干预，极大地提高了存储资源分配的效率和灵活性，特别适合于快速变化的云原生应用环境。

• 资源策略：StorageClass 定义了存储资源的回收策略（如删除、保留或回收重用），这对于资源的生命周期管理至关重要。例如，当 PVC 被删除时，与之绑定的 PV 可以根据 StorageClass 设置的策略决定是否同时被删除，或是保留下来供未来使用。

• 多租户与资源隔离：在多租户环境中，不同的项目或团队可能有不同的存储需求和预算限制。通过定义多种 StorageClass，管理员可以为不同的团队或应用提供不同级别的存储服务，比如高性能存储、低成本存储等，实现资源的精细化管理和成本控制。

• 可扩展性与兼容性：Kubernetes 的 StorageClass 设计考虑了存储后端的多样性，支持多种存储插件（如 AWS EBS、GCP PD、Ceph RBD 等），通过插件化的机制，使得新存储系统的集成变得相对简单，增强了平台的可扩展性和兼容性。

应用场景与实践

• 云原生应用开发：在云原生应用的持续集成和部署过程中，开发者只需关注应用逻辑和存储需求（如大小、访问模式），而通过声明式地指定 StorageClass，即可自动获得满足需求的存储资源，简化了开发和运维流程。

• 自动化运维与扩展：配合自动化工具和CI/CD流程，StorageClass 可以帮助实现存储资源的自动扩展、备份和恢复等高级功能，支撑应用的弹性伸缩和故障恢复能力。

• 成本优化与资源规划：企业可以根据业务需求和成本考量，利用不同级别的 StorageClass 来优化存储成本，如将热数据存放于高性能存储，冷数据迁移到成本更低的存储方案，实现资源的合理配置和成本节约。

总之，StorageClass 是 Kubernetes 存储体系中不可或缺的一部分，它通过提供存储资源的模板化定义，实现了存储资源的自动化管理，降低了操作复杂度，提升了应用的灵活性和基础设施的可维护性，是云原生应用存储解决方案中的关键组件。