Google GKE to Make Cloud Filestore the Default StorageClass for RWX PVCs

Google Cloud is changing how Google Kubernetes Engine (GKE) handles shared persistent storage. GKE will introduce Cloud Filestore as the default StorageClass for ReadWriteMany (RWX) PersistentVolumeClaims (PVCs).

The change is designed to simplify the deployment of Kubernetes workloads that require multiple pods or applications to access the same storage simultaneously.

What is changing?

Previously, GKE users who needed RWX storage generally had to manually enable the Cloud Filestore API (file.googleapis.com) and configure an appropriate StorageClass.

With the new approach, GKE will automatically enable the Cloud Filestore API for projects hosting GKE clusters. The backfill operation for existing GKE projects is scheduled to begin October 27, 2026.

The rollout will progressively apply to GKE control planes running version 1.37 and later.

Why does this matter?

RWX storage is commonly required by workloads such as:

• Web applications with multiple replicas

• Content management systems

• Shared file repositories

• CI/CD workloads

• AI and machine learning pipelines

• Applications that require shared persistent files

By making Filestore available automatically, GKE reduces the amount of manual configuration required to deploy these workloads.

However, the change also introduces an important cost consideration.

If a PVC uses:

accessModes:
  - ReadWriteMany

and does not specify a storageClassName, GKE may automatically provision a Filestore instance to satisfy the request.

Unlike standard Persistent Disk storage, Filestore has its own pricing model and capacity requirements. Therefore, an application that unintentionally triggers dynamic Filestore provisioning could result in unexpected cloud storage costs.

Important consideration for VPC Service Controls

Organizations using VPC Service Controls (VPC-SC) should pay particular attention to this change.

If a GKE cluster operates inside a VPC-SC perimeter and uses RWX PVCs, the Cloud Filestore API must be permitted within the relevant service perimeter.

Otherwise, GKE operations attempting to communicate with Filestore may be blocked, potentially causing:

• VPC-SC violations

• Security alerts

• Persistent volume provisioning failures

• Application deployment issues

Administrators should therefore review their VPC-SC configuration before the change becomes active.

Terraform and Infrastructure-as-Code impact

Organizations managing Google Cloud services through Terraform or other authoritative Infrastructure-as-Code tools should also review their API configuration.

For example, if Terraform explicitly manages enabled Google Cloud APIs, file.googleapis.com should be included where appropriate.

Otherwise, the automatic API enablement performed by GKE could create configuration drift, and a subsequent Terraform deployment might attempt to disable the API.

What administrators should review

Before the rollout, GKE administrators should:

1. Identify PVCs using ReadWriteMany.

2. Check whether those PVCs explicitly define a storageClassName.

3. Review workloads that could automatically provision Filestore.

4. Review expected Filestore storage costs.

5. Update VPC-SC service perimeters where applicable.

6. Update Terraform or other IaC configurations managing Google Cloud APIs.

7. Decide whether Filestore should be the preferred shared-storage solution.

Organizations that do not want GKE to use managed Filestore can also consider disabling the GcpFilestoreCsiDriver add-on. However, this does not prevent the Filestore API from remaining enabled at the project level.

Summary

Google’s change makes RWX storage in GKE easier to configure, particularly for applications that require shared persistent storage. At the same time, automatic provisioning means Kubernetes administrators need to be more aware of storage classes, cloud costs, VPC-SC policies, and Infrastructure-as-Code configuration.

The key date to remember is October 27, 2026, when Google will begin the backfill process for existing GKE projects.

For production environments, reviewing RWX PVCs and storage-class configurations before the rollout can help prevent unexpected storage provisioning, cost increases, or security-policy violations.