Storage for GKE clusters overview

This document covers the storage options that GKE supports and some key considerations for selecting the best option for your business needs. To determine which machine family is appropriate for your selection, see Machine series comparison.

GKE supports the following storage types and integrations:

Block storage (Persistent Disk)

Persistent Disk volumes are durable network storage devices managed by Compute Engine that your GKE clusters can access like physical disks in a desktop or a server. When your clusters require additional storage space, you can attach more Persistent Disk volumes to your nodes or resize your existing Persistent Disk volumes. You can let GKE dynamically provision PersistentVolumes backed by Persistent Disk, or you can manually provision disks.

This storage option is supported on GKE Autopilot and Standard clusters.

By default, Persistent Disk volumes are zonal resources (kept in a single zone within a region). You can create regional Persistent Disk volumes (kept across two zones in the same region). You can also attach a Persistent Disk volume as read-only to multiple nodes simultaneously. This is supported for both zonal and regional Persistent Disk volumes.

Persistent Disk storage on GKE is persistent, meaning that the data stored on your disks will persist even if the Pod that is using it is terminated.

Why use Persistent Disk storage

Use Persistent Disk storage if your clusters require access to high-performance, highly available durable block storage. A Persistent Disk volume is typically attached to a single Pod. This storage option supports the ReadWriteOnce access mode. GKE provides support for configuring Persistent Disk volumes with a range of latency and performance options, including the following:

  • Balanced Persistent Disk: Suitable for standard enterprise applications. This option provides a balance of performance and cost. Backed by solid-state drives (SSD). This is the default option for dynamic volume provisioning on clusters and nodes running GKE 1.24 or later.
  • Performance Persistent Disk: Suitable for scale-out analytics, databases, and persistent caching. This option is ideal for performance-sensitive workloads. Backed by solid-state drives (SSD).
  • Standard Persistent Disk: Suitable for big data, big compute workloads. This option is the most cost-effective disk type. Backed by standard hard disk drives (HDD).
  • Extreme Persistent Disk: Suitable for enterprise applications such as SAP HANA and Oracle. This option offers the highest performance to meet the needs of the largest in-memory databases. Backed by solid-state drives (SSD). For performance-critical applications, where Persistent Disk does not provide enough performance, use Hyperdisk Extreme disks.

To start using this storage option, see these resources:

Block storage (Google Cloud Hyperdisk)

Hyperdisk volumes use the next generation of Google Cloud block storage. Hyperdisk volumes let you dynamically tune the performance of your block storage to your workload. You can configure input/output operations per second (IOPS) and throughput independently for your applications and adapt to changing performance needs over time.

This storage option is supported on GKE Autopilot and Standard clusters. Hyperdisk volumes are zonal resources, subject to regional availability. Hyperdisk storage on GKE is persistent, meaning that the data stored on your disks will persist even if the Pod that is using it is terminated.

Why use Hyperdisk storage

Use Hyperdisk storage if you need to dynamically resize and adjust IOPS or throughput. A Hyperdisk volume is typically attached to a single Pod. This storage option supports the ReadWriteOnce access mode. You can select from the following Hyperdisk storage options for GKE based on your price-performance needs:

  • Hyperdisk Balanced: The best fit for most workloads. This is a good option for deploying most enterprise and line-of-business apps, as well as databases and web servers.
  • Hyperdisk Throughput: Optimized for cost-efficient high-throughput. This is a good option if your use case targets scale-out analytics (for example, Hadoop or Kafka), restoring cold data from backup servers, and throughput-oriented cost-sensitive workloads.
  • Hyperdisk Extreme: Optimized for IOPS performance. This is a good option if you're deploying high-performance workloads, such as database management systems.
  • Hyperdisk ML: Optimized for AI/ML training and inference workloads that need to load model weights quickly. Use this option to reduce idleness of GPU/TPU resources due to latency bottlenecks.

Hyperdisk storage options are supported on GKE Autopilot and Standard clusters.

To start using this storage option, refer to these resources:

Block storage (Hyperdisk Storage Pool)

A Hyperdisk Storage Pool is a pre-provisioned pool of storage resources (capacity, throughput, and IOPS) that disks in your GKE cluster can use. The storage resources are shared across all Hyperdisks that you create within the storage pool.

GKE Standard clusters allow both Hyperdisk boot disks (for operating systems) and attached Hyperdisks (for data storage) to be part of a storage pool. GKE Autopilot clusters support only attached Hyperdisks for storage pools.

To start using this storage option, refer to the following resources:

Ephemeral and raw block storage (Local SSD)

Local SSD disks are physical drives that are attached directly to your nodes. They can offer better performance, but are ephemeral. Each Local SSD volume is attached to a specific node. You can't move the volume to a different node.

This storage option is supported on GKE Standard clusters. Autopilot support for Local SSD is available in preview on A2 Ultra A100 machines, on clusters and node pools running GKE 1.27 and later.

Ephemeral storage backed by Local SSD storage on GKE is tied to the lifecycle of a Pod. When your Pod is terminated, the ephemeral storage associated with that Pod is also deleted.

Why use Local SSD

Using Local SSD storage in GKE clusters is suitable if you need hot caching for databases and for real-time analytics, or flash-optimized ephemeral storage offering the lowest latencies. Local SSD storage can be particularly effective as a caching layer in front of Cloud Storage for AI/ML, batch processing, analytics, and in-memory databases use cases.

To start using this storage option, refer to these resources:

File storage

Filestore provides a cloud-based shared file system for unstructured data, with network file system (NFS) access. Filestore instances function as file servers on Google Cloud that provide durable storage with ReadWriteMany access for your GKE clusters. Filestore instances are decoupled from the host and require minimal manual operation. Workload failovers are seamless because there are no infrastructure operations to attach or detach volumes.

This storage option is supported on GKE Autopilot and Standard clusters. Filestore storage with the enterprise service tier defaults to regional availability, while the other service tiers have zonal availability. Filestore storage on GKE is persistent, meaning that the data stored in your instances will persist even if the Pod that is using it is terminated.

Why use Filestore storage

Use Filestore storage if your applications need network file system (NFS) access and multiple readers and writers. This storage option is suitable if your use case involves content management systems, application migration, data analytics, rendering, and media processing.

For additional cost efficiency, Filestore multishares for GKE lets you share a Filestore enterprise tier instance of 10 GiB or larger with up to 80 PersistentVolumes.

To start using this storage option, refer to these resources:

Object storage (Cloud Storage FUSE)

Cloud Storage is an object store for binary and object data, blobs, and unstructured data. The Cloud Storage FUSE CSI driver manages the integration of Cloud Storage FUSE with Kubernetes APIs to consume existing Cloud Storage buckets as volumes. You can use the Cloud Storage FUSE CSI driver to mount buckets as file systems on GKE nodes.

The Cloud Storage FUSE CSI driver supports the ReadWriteMany, ReadOnlyMany, and ReadWriteOnce access modes on GKE Autopilot and Standard clusters. Cloud Storage objects have regional availability. Cloud Storage data on GKE is persistent, meaning that the data stored in your buckets will persist even if the Pod that is using it is terminated.

Why use Cloud Storage FUSE

The Cloud Storage FUSE option is suitable if you need file semantics in front of Cloud Storage for portability. Cloud Storage FUSE is also a common choice for developers who want to store and access machine learning (ML) training and model data as objects in Cloud Storage.

To start using this storage option, refer to these resources:

Managed databases

A managed database, such as Cloud SQL or Spanner, provides reduced operational overhead and is optimized for Google Cloud infrastructure. Managed databases require less effort to maintain and operate than a database that you deploy directly in Kubernetes.

Why use managed databases

Using a Google Cloud managed database lets your stateful workloads on GKE to access persistent data while automating maintenance tasks such as backups, patching, and scaling. You create a database, build your app, and let Google Cloud scale it for you. However, this also means you might not have access to the exact version of a database, extension, or the exact flavor of database that you want.

GKE provides support for connecting with Google Cloud managed database services, including the following:

To start using this storage option, refer to these resources:

Build artifacts (Artifact Registry)

Artifact Registry is a repository manager for container images, OS packages, and language packages that you build and deploy.

Why use Artifact Registry

Artifact Registry is a suitable option for storing your private container images, Helm charts, and other build artifacts.

To pull images from Artifact Registry Docker repositories to GKE, see Deploying to Google Kubernetes Engine in the Artifact Registry documentation.

What's next