Google Cloud's recent Next '26 recap and release notes emphasize structural, cross-cutting changes rather than single-product launches. The announcements most relevant to platform engineering are: a new GKE cluster schema field to support Data Cache, Flexible Committed Use Discounts (CUDs) expanding to Cloud Run and to additional VM families, and reiterated platform-scale storage/networking targets (GDC: 6 PB/zone and a 30 IOPS/GB profile, plus networking improvements such as C4N updates).
What to look for in the signals
Concrete artifacts called out in the recap and release notes:
- GKE: a new cluster field spec.nodeConfig.ephemeralStorageLocalSsdConfig.dataCacheCount was added to the ContainerCluster schema. This formalizes how many local-SSD-backed data-cache devices or partitions are expected per node.
- Pricing / Cloud Run: Flexible CUDs were announced to apply to Cloud Run usage, bringing serverless consumption into the flexible discount model.
- Compute pricing: Flexible CUDs were also called out as covering specific VM families (memory-optimized M1–M4 and HPC-optimized H3/H4D) for committed-use planning.
There is also a Model Garden note: Claude Opus 4.7 appeared in Model Garden listings — relevant to Vertex AI model availability tracking but not to control-plane configuration.
Taken together, the signals indicate two trends: price-sensitive discounting is moving higher up the stack (serverless systems like Cloud Run can be included in committed discounts), and GKE is exposing first-class configuration for node-local caches tied to local SSDs.
GKE Data Cache: operational implications
The new dataCacheCount cluster field is primarily a schema/automation signal. It indicates the control plane will accept an explicit count of local-SSD-backed cache devices/partitions per node. Practical implications:
- Provisioning automation: include the new field in cluster creation and patch flows so IaC and CI can produce deterministic cache topology. Expect integer values (0 or greater); validate against the chosen machine types' available local-SSD topology.
- Node pool design: you will likely need distinct node pools for cache-heavy workloads vs compute-only workloads (different dataCacheCount), which affects autoscaling, scheduling, and taint/toleration strategies.
- Ephemeral lifecycle: local-SSD-backed caches are ephemeral. Draining, rolling upgrades, or preemptible node terminations require eviction and rehydration plans for cached data; bake cache-aware hooks into your node lifecycle automation.
Illustrative API example (operational, not a tested production script):
# PATCH cluster to set 2 local-SSD data-cache devices per node (illustrative)
# Use the clusters.patch method and an updateMask for the field you're changing.
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"nodeConfig": {
"ephemeralStorageLocalSsdConfig": {
"dataCacheCount": 2
}
}
}' \
"https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME?updateMask=nodeConfig.ephemeralStorageLocalSsdConfig.dataCacheCount"Notes: verify the RPC/method for your GKE API version and prefer official client libraries or gcloud commands in automation. Always validate that the selected machine type actually exposes the local SSD topology you expect (for example, many H-family instances expose NVMe drives).
Flexible CUDs for Cloud Run and new VM families: cost modeling
Bringing Cloud Run into Flexible CUD coverage and adding M1–M4 and H3/H4D families to Flexible CUDs changes sustained-cost calculations.
Key considerations:
- Cloud Run workload eligibility: steady, predictable Cloud Run vCPU/GB usage can now be part of committed capacity planning. Evaluate sustained services and background workloads for potential coverage.
- VM family coverage: memory-optimized and HPC families can be included in Flexible CUDs; if you run steady-state workloads on those families, include them in committed-use sizing.
- Billing and attribution: discounts are applied at the billing account level and may not map one-to-one to projects. FinOps and procurement must define mapping and reconciliation rules to attribute discount benefits correctly.
Small, realistic amortization example: estimate savings using actual usage volumes and SKU-level rates. This script requires you to supply monthly vCPU-seconds for Cloud Run and core-hours for VMs. Replace the example numbers with SKU prices from your billing export for accurate results.
Platform-scale storage and networking: architectural consequences
Recap numbers matter for stateful architectures: GDC quoted at 6 PB per zone and a 30 IOPS/GB profile, while C4N networking improvements are positioned to reduce jitter and increase throughput for high-volume transfers.
Operational consequences:
- State placement: a 6 PB/zone capacity with 30 IOPS/GB lets you design zonal high-I/O object datasets without immediate regional sharding. But 30 IOPS/GB is an average profile—run workload-specific sizing tests. For example, 1 TB at 30 IOPS/GB suggests ~30k IOPS; if your workload needs more, partition or stripe data.
- Local SSD + cache pattern: pair local-SSD-backed GKE nodes (with configured dataCacheCount) with zonal object storage to absorb spikes and perform local processing before write-back for durability.
- Networking: improved transport (C4N) reduces tail latency and increases throughput; revisit CNI, retransmit/backpressure, and service-mesh settings to exploit the improved network characteristics.
Practical week-one checklist
- Audit billing exports to identify steady-state Cloud Run vCPU and memory usage; identify candidate services for Flexible CUD coverage.
- Update IaC templates to accept spec.nodeConfig.ephemeralStorageLocalSsdConfig when GKE Data Cache is required; create separate node pools for cache vs compute workloads.
- Implement node-drain/eviction hooks that handle cache eviction and rehydration; test rolling upgrades and simulated node loss.
- Map VM family usage (M1–M4, H3/H4D) from billing exports and coordinate with procurement on Flexible CUD sizing.
- Run performance tests against GDC with realistic object sizes to validate the 30 IOPS/GB profile for your workload.
What this means for platform teams
These updates are incremental but operationally meaningful: Cloud Run entering Flexible CUD eligibility collapses some serverless vs VM cost boundaries, and the GKE Data Cache schema field formalizes local-cache topology in cluster config. Platform, FinOps, and procurement teams should coordinate earlier in the lifecycle; IaC and runbooks need modest updates; and targeted load tests should validate assumptions before committing.
Track model availability (e.g., Claude Opus 4.7 in Model Garden) separately for AI product decisions, but treat these platform changes as nudges that reduce friction for local-cache-backed GKE workflows and for sustained Cloud Run usage.