什么是容器的持久存储？

容器是云原生应用程序开发的基础，它们是轻量、可移植的软件单元，将应用程序及其依赖项打包在一起，从而可以轻松地在现代 IT 基础设施上部署。

容器本质上是临时性的。它们被设计为临时的，根据需要启动和关闭。虽然这种灵活性使它们具有高度的灵活性和可扩展性，但容器停止运行时，其中生成的任何数据都会丢失。持久存储通过保持数据独立于任何单个容器来解决了这一问题。

如果没有持久存储，关键系统将无法运行。例如，银行在容器中运行的事务数据库会在例行更新期间丢失客户账户余额，或者电子商务平台在每次重启时会丢失购物车内容。

随着组织继续转向云原生和微服务架构，容器已成为应用程序部署和管理的核心，这使得容器的持久存储对于大规模运行有状态应用程序变得至关重要。 根据 Strategic Market Research 最近的一份报告，2024 年全球应用程序容器市场规模约为 21 亿美元。预计到 2030 年将达到 69 亿美元，复合年增长率 (CAGR) 为 21.1%。¹

在企业环境中，持久存储以文件存储、Block Storage 和 Object Storage 的形式出现，每种形式适用于不同的工作负载。组织通常通过硬件系统和为支持混合云及分布式云环境而设计的软件定义存储 (SDS) 平台相结合的方式来提供这些存储解决方案。

容器化 包括将软件代码与运行它所需的仅 操作系统 (OS) 库和依赖项（通常是基于 Linux 的）打包在一起。此过程创建单一的轻量级单元（例如容器），该单元可以在任何基础设施上一致运行。

随着组织从虚拟机 (VM) 转向容器，大规模管理容器化 工作负载的需求日益增长。2013 年推出的 Docker 通过为开发人员提供构建和共享容器的标准化方式，使容器得到广泛使用。但在混合多云环境中编排成百上千个容器需要一种处理复杂性的方法。因此，Kubernetes 被开发出来，用于自动化容器化应用程序的部署、扩展和管理。

Kubernetes 由 Google 于 2014 年创建，是一个由云原生计算基金会 (CNCF) 维护的 开源平台。 主要的云提供商如 AWS、Microsoft Azure、Google Cloud 和 IBM Cloud 均支持该平台。

Kubernetes 在 Pod 中运行容器，Pod 部署在 Kubernetes 集群的节点上。它通过应用程序编程接口 (API) 管理组件之间的配置和通信，支持跨不同系统的自动化编排。如今，Kubernetes 已成为容器编排的事实标准。

在数据存储方面，Kubernetes 工作原理的一个重要方面是理解无状态应用程序与有状态应用程序之间的区别。 无状态应用程序（例如处理 API 请求的 Web 服务器）独立处理每个请求，因此不会在会话之间保留数据。 相比之下，有状态应用程序（例如数据库）会保留数据，并依赖先前交互中的信息才能正常运行。

此外，Kubernetes 中的容器和 Pod 是临时的，可以随时停止、重启或重新调度。 对于无状态应用程序，这种行为不是问题。然而，在有状态应用程序中，当容器停止时，其中存储的任何数据都会丢失。这就是持久存储在容器化环境中发挥关键作用的地方：它将数据与容器生命周期分离开来。

除了传统应用程序迁移到容器之外，数据库、人工智能 (AI) 和机器学习 (ML) 等数据密集型工作负载也越来越多地基于云。这些工作负载需要持久存储，以确保数据在容器终止后仍能存活、在分布式系统中维护状态，并提供模型训练所需的高吞吐量、低延迟性能。

容器的持久存储构建在一组组件之上，这些组件协同工作，将数据与容器分离。在 Kubernetes 中，管理员配置存储基础设施，而开发人员和应用程序通过简单的请求来访问它。

这些组件包括：

• 卷与绑定挂载
• PersistentVolume (PV)
• PersistentVolumeClaim (PVC)
• 存储类
• 容器存储接口 (CSI)

将存储附加到容器主要有两种方式：绑定挂载和命名卷（例如 Docker 卷）。

• 绑定挂载将主机上的特定文件或目录直接连接到容器中。

• 卷则更灵活，因为 Kubernetes 可以在不同的存储系统上管理它们。

卷是 Pod 中容器可以访问的存储位置。与容器内临时存储（容器停止时会消失）不同，卷在 Pod 的生命周期内持续存在。这意味着，如果容器在同一 Pod 中失败并重启，卷中的数据仍然可用。

卷可以连接到不同类型的存储设备，包括本地磁盘、通过网络文件系统 (NFS) 等协议连接的 网络直连存储，或 基于云的存储服务。

PersistentVolume 在 Kubernetes 集群内提供存储，可以由管理员手动创建，也可以自动创建。

普通卷与 PersistentVolume 的关键区别在于生命周期。PersistentVolume 独立于任何 Pod 存在。这种设置意味着，即使访问它的 Pod 被删除或移动到另一台机器，存储仍然存在。

PersistentVolume 拥有独立于使用它们的 Pod 的生命周期。管理员可以配置其存储容量、读写访问权限（例如 ReadWriteOnce 用于单 Pod 访问，或 ReadWriteMany 用于共享访问）。

PersistentVolumeClaim 是应用程序或用户发出的存储请求。Pod 不直接连接到 PersistentVolume，而是使用 PersistentVolumeClaim 声明作为中间层。声明指定所需的存储容量和访问模式。然后 Kubernetes 将其与可用的 PersistentVolume 匹配。这种分离意味着开发人员可以请求存储，而无需了解底层存储基础设施。

当声明与 PersistentVolume 连接后，Pod 就可以像使用任何文件系统一样读取和写入数据。 如果 Pod 被移动或重启，它仍然可以访问同一个声明和相同的持久数据。

在企业环境中，为每个应用程序手动创建存储卷会变得复杂且难以管理。Kubernetes 通过 StorageClass 解决了这一挑战。StorageClass 定义了不同类型的存储（例如高性能固态硬盘），并使用供给器按需自动创建数据卷。

当应用程序请求存储并引用某个 StorageClass 时，Kubernetes 会自动配置相应的卷，无需手动设置。此功能简化了整体存储管理。

容器存储接口 (CSI) 是一个标准化的、厂商中立的 API，使 Kubernetes 能够与各种存储系统进行交互。

CSI 允许存储提供商平台（例如 IBM Storage Fusion、NetApp）独立开发和更新自己的插件。这些插件管理完整的存储生命周期：根据需要创建、挂载、配置和删除卷。

容器的持久存储使组织能够在容器化环境中运行有状态应用程序，带来以下优势：

• 数据持久性与弹性：写入每个持久卷的数据在容器故障、重启和重新调度后仍然存在，防止数据丢失，并确保即使底层容器基础设施发生变化，有状态应用程序也能保持弹性。

• 简化运维：动态配置和自动化存储管理减少了人工工作量。平台团队只需定义一次存储策略，应用程序即可在其命名空间内将存储作为自助服务资源使用。

• 高性能与可扩展性：容器的持久存储提供了数据密集型工作负载（如 AI/ML 训练和实时分析）所需的吞吐量、低延迟和可扩展性。

• 灵活性与可移植性：Kubernetes 持久卷和 CSI 驱动抽象了存储，使组织能够在本地基础设施、私有云和公有云环境中运行应用程序，支持混合云 策略。

• 安全与合规性：由企业存储系统支持的持久卷提供数据保护功能，包括满足合规和法规要求所需的加密、复制和备份能力。

• 成本效率：动态配置根据需求扩缩存储，而自动数据分层将不常用的数据转移到经济高效的存储层，帮助组织优化成本。

• 共享访问：容器的持久存储使多个 Pod 能够同时读写相同的数据，在无需复制存储资源的情况下支持协作工作流。

组织可以通过一系列工具和解决方案来获得容器的持久存储：

• 容器编排平台
• 企业存储解决方案
• 公有云提供商 

容器编排平台（例如 Red Hat OpenShift）提供集成的持久存储管理，内置对 CSI 驱动和动态存储配置的支持。

这些平台简化了大规模运行容器化工作负载的组织的部署和运维。

企业存储平台（例如 IBM Storage Fusion）提供容器原生存储解决方案，具备高级数据服务，包括快照、克隆、复制和灾难恢复。

这些平台通过 CSI 驱动直接与 Kubernetes 集成，为有状态应用程序提供安全性、合规性能力和共享访问控制。

公有云提供商包括 AWS、Microsoft Azure、Google Cloud 和 IBM Cloud 在内的公有云提供商提供托管的 Kubernetes Service，并包含原生的持久存储选项，例如 Amazon Elastic Block Store (EBS) 和 IBM Cloud Block Storage。

容器的持久存储支持以下业务用例：

• 数据库与数据管理
• AI 工作负载
• DevOps 与 CI/CD
• 备份与灾难恢复 (BDR)