GKE Adds Z4M Nodes for AI/ML Parallel File Systems

Google Kubernetes Engine (GKE) can now run nodes on Z4M, a storage-optimized machine series that Google's release notes say suits large parallel file systems for AI/ML workloads. GKE Z4M nodes are for the data tier that feeds your training and inference jobs, not for the accelerators themselves: Z4M doesn't support GPUs.

What GKE shipped for Z4M on October 19

The GKE release notes for October 19, 2026 set the minimum version by provisioning method:

• Manual node pools: GKE 1.36.3-gke.1767000 and later.
• Compute classes, cluster autoscaler, node pool auto-creation and Autopilot: GKE 1.37.0-gke.4713000 and later.
• Not supported: Z4M bare metal (-metal types), per GKE's machine support page.

The Compute Engine release notes list Z4M as generally available on October 15, four days earlier.

Per the storage-optimized machines docs, the series runs on fifth generation Intel Emerald Rapids Xeon processors. The standard types are z4m-highmem-16, z4m-highmem-32, z4m-highmem-48 and z4m-highmem-192, with 16 to 192 vCPUs and up to 1,488 GB of memory. The series offers up to 168,000 GiB of Titanium SSD (Google's local flash) and up to 400 Gbps of network bandwidth on two-NIC shapes. Cloud RDMA is supported.

Why GKE Z4M nodes matter for AI/ML storage

A parallel file system spreads data across many storage servers so many clients can read and write at once. That is the pattern behind dataset loading and checkpointing. When a training job can't read fast enough, the accelerators wait and you pay for the wait.

Google's target workloads also include I/O-intensive databases (SQL, NoSQL and vector), checkpointing and distributed KV cache. With Z4M supported in GKE, that storage tier can be a node pool in the same cluster as the jobs reading from it, scheduled and scaled with the tools you already use.

Two caveats. This release ships nodes, not a file system, so you still choose and operate the file system software. And Titanium SSD is local to the instance, so until you've tested what survives a node repair or upgrade, treat that data as tied to the node's lifetime. Compute Engine also limits live migration to instances with 42,000 GiB or less of attached Titanium SSD, so the biggest shapes need a plan for host maintenance.

What to check on Monday morning

Check your cluster version

gcloud container clusters describe <cluster-name> \
  --location=<control-plane-location> \
  --format="value(currentMasterVersion)"

Compare the result with the versions above, check your node pools' versions too, and run gcloud container get-server-config --location=<control-plane-location> to see what your location offers.

Check that Z4M exists in your zone

The docs say Z4M is available in "select zones and regions" without naming them, so ask the API:

gcloud compute machine-types list \
  --filter="name~^z4m AND zone~<region>" \
  --format="table(name,zone.basename())"

If nothing comes back, your region doesn't have it yet. The node pool must land in a zone that does.

Add a Z4M node pool by hand

gcloud container node-pools create z4m-storage \
  --cluster=<cluster-name> \
  --location=<control-plane-location> \
  --node-locations=<zone-with-z4m> \
  --machine-type=z4m-highmem-48 \
  --disk-type=hyperdisk-balanced \
  --num-nodes=3 \
  --node-labels=workload=parallel-fs

This creates three labeled nodes your file system pods can target with a nodeSelector. I set the boot disk to Hyperdisk Balanced because Z4M lists only NVMe Hyperdisk types and Titanium SSD as supported disks. The docs I read don't state GKE's default boot disk for Z4M, so if creation complains about disk type, start there.

Let a compute class pick Z4M for you

On 1.37.0-gke.4713000 or later, declare the machine in a compute class and let GKE provision it:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: pfs-storage
spec:
  priorities:
  - machineType: z4m-highmem-48
  nodePoolAutoCreation:
    enabled: true
  whenUnsatisfiable: DoNotScaleUp

Pods then request the class by name:

spec:
  nodeSelector:
    cloud.google.com/compute-class: pfs-storage

DoNotScaleUp leaves a pod pending if no rule can be met, which beats silently landing on a default node. The compute class docs recommend setting whenUnsatisfiable explicitly because its default depends on your GKE version. This shape is for Standard clusters. In Autopilot you request compute classes and GKE manages the machines.

Gotchas

• No bare metal (z4m-highmem-192-metal), GPUs, custom machine types or Windows images on Z4M.
• A working manual pool doesn't prove the autoscaled path works: it needs a newer GKE version.
• The release note doesn't cover pricing or how Titanium SSD is exposed to pods. Price one node and test a single-node file system before you size a cluster.

If your AI jobs are I/O-bound, GKE Z4M nodes let you put the storage tier inside the cluster, but only after you've confirmed the version, zone and disk setup that this release depends on.