GKE 集群的存储概览


本文档介绍了 GKE 支持的存储选项,以及选择最符合您业务需求的选项的一些主要考虑因素。

GKE 支持以下存储类型和集成:

块存储 (Persistent Disk)

Persistent Disk 卷是由 Compute Engine 管理的持久性网络存储设备,GKE 集群可以像访问桌面设备或服务器中的物理磁盘一样访问它们。如果集群需要额外的存储空间,您可以将更多 Persistent Disk 卷挂接到节点或调整现有 Persistent Disk 卷的大小。您可以让 GKE 动态预配由 Persistent Disk 支持的 PersistentVolume,也可以手动预配磁盘。

GKE Autopilot 和 Standard 集群支持此存储选项。

默认情况下,Persistent Disk 卷是可用区级资源(保留在一个区域内的单个可用区中)。您可以创建区域级 Persistent Disk 卷(保留在同一区域内的两个可用区中)。您还可以同时将 Persistent Disk 卷以只读方式挂接到多个节点。可用区级和区域级 Persistent Disk 卷都支持此功能。

GKE 上的 Persistent Disk 存储是永久性的,也就是说,磁盘上存储的数据会保留,即使使用该数据的 Pod 被终止也是如此。

为何使用 Persistent Disk 存储

如果集群需要访问高性能、高可用性且耐用的块存储,请使用 Persistent Disk 存储。Persistent Disk 卷通常挂接到单个 Pod。此存储选项支持 ReadWriteOnce 访问模式。GKE 支持使用一系列延迟和性能选项配置 Persistent Disk 卷,其中包括:

  • 平衡永久性磁盘:适用于标准企业应用。此选项可在性能和费用之间取得平衡。以固态硬盘 (SSD) 作为支持。 这是在运行 GKE 1.24 或更高版本的集群和节点上动态预配卷的默认选项。
  • 高性能永久性磁盘:适用于扩容分析、数据库和永久性缓存。此选项非常适合具有较高性能要求的工作负载。以固态硬盘 (SSD) 作为支持。
  • 标准永久性磁盘:适用于大数据、计算密集型工作负载。此选项是最具成本效益的磁盘类型。以标准硬盘 (HDD) 作为支持。
  • 极端永久性磁盘:适用于 SAP HANA 和 Oracle 等企业应用。此选项提供最高的性能,可满足最大的内存中数据库的需求。以固态硬盘 (SSD) 作为支持。对于性能关键型应用,如果 Persistent Disk 无法提供足够的性能,请使用 Hyperdisk Extreme 磁盘。

如需开始使用此存储选项,请参阅以下资源:

块存储 (Google Cloud Hyperdisk)

Hyperdisk 卷使用新一代 Google Cloud 块存储。Hyperdisk 卷可让您根据工作负载动态调整块存储的性能。您可以为应用单独配置每秒输入/输出操作数 (IOPS) 和吞吐量,并适应随时间不断变化的性能需求。

GKE Autopilot 和 Standard 集群支持此存储选项。Hyperdisk 卷是可用区级资源,具体取决于区域级可用性。GKE 上的 Hyperdisk 存储是永久性的,也就是说,磁盘上存储的数据会保留,即使使用该数据的 Pod 被终止也是如此。

为何使用 Hyperdisk 存储

如果您需要动态调整 IOPS 或吞吐量,请使用 Hyperdisk 存储。Hyperdisk 卷通常挂接到单个 Pod。此存储选项支持 ReadWriteOnce 访问模式。您可以根据性价比需求从 GKE 的以下 Hyperdisk 存储选项中进行选择:

  • Hyperdisk Throughput:针对经济实惠的高吞吐量进行了优化,吞吐量高达 3 GB/秒(IO 大小 >=128 KB)。如果您的应用场景是扩容分析(例如 Hadoop 或 Kafka)、从备份服务器恢复冷数据以及面向吞吐量的费用敏感型工作负载,则这是一个不错的选项。GKE Autopilot 和 Standard 集群支持此存储选项。
  • Hyperdisk Extreme:针对 IOPS 性能进行了优化,预配的 IOPS > 320,000,吞吐量 > 4.8 GB/秒。如果您要部署高性能工作负载(例如数据库管理系统),则这是一个不错的选项。只有 Standard 集群支持此存储选项。

如需开始使用此存储选项,请参阅以下资源:

临时和原始块存储(本地 SSD)

本地 SSD 磁盘是直接挂接到节点的物理硬盘。这些磁盘可以提供更好的性能,但它们为临时磁盘。每个本地 SSD 卷都挂接到特定节点。您无法将卷移动到其他节点。

GKE Standard 集群支持此存储选项。在运行 GKE 1.27 及更高版本的集群和节点池中,Autopilot 对本地 SSD 的支持在 A2 Ultra A100 机器上目前为预览版。

GKE 上由本地 SSD 存储提供支持的临时存储与 Pod 的生命周期相关联。Pod 终止后,与该 Pod 关联的临时存储也会被删除。

为何使用本地 SSD

如果您需要为数据库和实时分析使用热缓存,或者使用提供最低延迟的闪存优化临时存储,则在 GKE 集群中使用本地 SSD 存储是非常适合的。对于 AI/机器学习、批处理、分析和内存中数据库应用场景而言,本地 SSD 存储作为 Cloud Storage 前面的缓存层尤其有效。

如需开始使用此存储选项,请参阅以下资源:

文件存储

Filestore 为非结构化数据提供了基于云的共享文件系统,具有网络文件系统 (NFS) 访问权限。Filestore 实例充当 Google Cloud 上的文件服务器,可为 GKE 集群提供具有 ReadWriteMany 访问权限的持久性存储。Filestore 实例与主机分离,并且需要最少的手动操作。工作负载故障切换是无缝的,因为没有用于挂接或分离卷的基础架构操作。

GKE Autopilot 和 Standard 集群支持此存储选项。企业服务层级的 Filestore 存储默认为具有区域级可用性,而其他服务层级具有可用区级可用性。GKE 上的 Filestore 存储是永久性的,也就是说,实例中存储的数据会保留,即使使用该数据的 Pod 被终止也是如此。

为何使用 Filestore 存储

如果您的应用需要网络文件系统 (NFS) 访问权限以及多个读取者和写入者,请使用 Filestore 存储。如果您的应用场景涉及内容管理系统、应用迁移、数据分析、渲染和媒体处理,则此存储选项适合。

为了提高成本效益,Filestore Multishares for GKE 可让您与最多 80 个 PersistentVolume 共享 10 GiB 或更大的 Filestore 企业层级实例。

如需开始使用此存储选项,请参阅以下资源:

对象存储 (Cloud Storage FUSE)

Cloud Storage 是一种用于二进制文件和对象数据、blob 以及非结构化数据的对象存储服务。Cloud Storage FUSE CSI 驱动程序管理 Cloud Storage FUSE 与 Kubernetes API 的集成,以将现有 Cloud Storage 存储桶用作卷。您可以使用 Cloud Storage FUSE CSI 驱动程序,将存储桶作为文件系统装载到 GKE 节点上。

Cloud Storage FUSE CSI 驱动程序支持 GKE Autopilot 和 Standard 集群上的 ReadWriteManyReadOnlyManyReadWriteOnce 访问模式。Cloud Storage 对象具有区域级可用性。GKE 上的 Cloud Storage 数据是永久性的,也就是说,存储桶中存储的数据会保留,即使使用该数据的 Pod 被终止也是如此。

为何使用 Cloud Storage FUSE

如果您需要在 Cloud Storage 前面使用文件语义以实现可移植性,则 Cloud Storage FUSE 选项适合。对于希望作为 Cloud Storage 中的对象存储和访问机器学习 (ML) 训练和模型数据的开发者而言,Cloud Storage FUSE 也是一个常见的选择。

如需开始使用此存储选项,请参阅以下资源:

代管式数据库

Cloud SQLSpanner 等代管式数据库可降低运营开销,并针对 Google Cloud 基础架构进行了优化。与直接在 Kubernetes 中部署的数据库相比,代管式数据库需要的维护和运营工作量更少。

为何使用代管式数据库

借助 Google Cloud 代管式数据库,GKE 上的有状态工作负载可以访问永久性数据,同时可自动执行备份、修补和扩缩等维护任务。您需要创建一个数据库,构建您的应用,并让 Google Cloud 为您扩缩应用。但是,这也意味着您可能无权访问数据库的确切版本、扩展程序或您所需的数据库确切变种。

GKE 支持与 Google Cloud 代管式数据库服务建立连接,这些服务包括:

如需开始使用此存储选项,请参阅以下资源:

构建工件 (Artifact Registry)

Artifact Registry 是您构建和部署的容器映像、操作系统软件包和语言软件包的制品库管理器。

为何使用 Artifact Registry

Artifact Registry 是一种适合于存储私有容器映像、Helm 图表和其他构建工件的选项。

如需将映像从 Artifact Registry Docker 制品库拉取到 GKE,请参阅 Artifact Registry 文档中的部署到 Google Kubernetes Engine

后续步骤