Kubernetes in July 2026: Custom Metrics Exporters, etcd 3.7 Streaming Reads, and DRA for GPUs

July 2026 has been an unusually busy month in the Kubernetes ecosystem. The upstream project published a practical guide to building custom metrics exporters, etcd shipped a major release with streaming reads and control-plane efficiency gains, and the surrounding tooling from Helm to GPU schedulers kept moving forward. Here is what platform engineers need to know.

Kubernetes Publishes a Guide to Custom Metrics Exporters

On July 14, 2026, the Kubernetes blog ran a hands-on tutorial titled “Building a Custom Metrics Exporter for Kubernetes”. While the topic is not new, the timing matters. As more teams move beyond CPU-based autoscaling, the gap between what Kubernetes natively understands and what applications actually need is becoming a bottleneck.

The tutorial walks through writing a small HTTP server in Go that exposes application-specific metrics on a /metrics endpoint. Prometheus scrapes that endpoint, stores the time-series data, and makes it available to the HorizontalPodAutoscaler through a metrics adapter. The natural next step — which the post explicitly nudges readers toward — is wiring those custom metrics into the HPA so workloads scale on signals that actually drive load, not just processor utilization.

The guide covers the three Prometheus metric types with clear rules of thumb:

Counters for values that only increase, such as total jobs processed or errors encountered.
Gauges for snapshot values that rise and fall, such as queue depth or active connections.
Histograms for distributions like request latency, enabling percentile calculations rather than simple averages.

It also explains when to instrument an application directly versus running a standalone exporter. The standalone approach is better when the data source is external or when you do not control the application code. For teams that have been scaling on CPU alone, this is a gentle but firm push toward more intelligent autoscaling.

etcd 3.7: Streaming Reads and a Leaner Control Plane

etcd, the distributed key-value store at the heart of every Kubernetes cluster, released v3.7.0 in early July, followed by v3.7.1 shortly after. SIG-etcd called it one of the most consequential releases in recent memory.

RangeStream Changes the Read Model

The most visible addition is RangeStream. Before v3.7, etcd buffered the entire result set of a range request before sending anything to the client. For large keyspaces, that meant unpredictable latency spikes and memory pressure on both sides of the connection. RangeStream breaks result sets into chunks, letting clients start processing data immediately while the server streams the rest.

Kubernetes users will get access to RangeStream in v1.37 through the EtcdRangeStream feature gate. This coordinated rollout is possible because etcd and Kubernetes development merged in 2023 under a shared governance model.

Keys-Only Reads Skip the Backend

For workloads that only need key names and not values, etcd v3.7 introduces a keys_only optimization. When this flag is set, etcd reads solely from its in-memory index and skips the bbolt backend entirely. The only exception is when sorting by value is required. In practice, this reduces both backend reads and transient memory use for inventory and discovery-style queries.

Lease Reliability and v2 Store Removal

Lease operations are more reliable in v3.7. Lease revocation is now prioritized during leader transitions, preventing stale leases from hanging around longer than they should. Lease renewals have also been streamlined.

More consequentially, etcd now boots entirely from v3store, eliminating the last dependency on the legacy v2 store. That legacy code has been a maintenance burden for years, and its removal shrinks the attack surface and simplifies future development.

The release also completes a long-running protobuf overhaul, replacing outdated protobuf libraries with fully supported alternatives. Updated dependencies include bbolt v1.5.1 and raft v3.7.0.

containerd 2.3.3 Patches Critical CRI Bugs

The containerd project shipped v2.3.3 on July 10, 2026. This patch release fixes a nil pointer dereference in the NRI GetIPs call during pod sandbox teardown, rejects CreateContainer calls when the target sandbox is not running, and ensures sandbox shutdown on RunPodSandbox hook failures to prevent mount leaks. There is also a Windows-specific fix for SYSTEM temp directory overrides.

The 2.3 line is under extended support through September 2026 for Kubernetes versions 1.32, 1.31, and 1.30. If you are running containerd in production, this patch belongs on your next maintenance schedule.

GPU Scheduling in Kubernetes: DRA Reaches Production

Dynamic Resource Allocation, the Kubernetes API framework that lets workloads request specialized hardware by attributes rather than simple counts, has been a slow burn. In 2026, it is finally becoming real.

Red Hat shipped DRA as GA in OpenShift 4.21 in March, and Kubernetes 1.36 graduated four DRA enhancements to stable. The implications are significant for AI and machine learning teams. Instead of requesting “one GPU” and hoping the scheduler places it sensibly, workloads can now specify exact device attributes, request fractional GPU slices, or express affinity constraints.

At KubeCon Europe 2026, NVIDIA contributed a set of open-source enhancements spanning resource allocation, scheduling, and isolation. The DRA driver replaces the legacy device plugin and enables fine-grained GPU resource allocation through the Kubernetes Dynamic Resource Allocation API. For organizations running training or inference workloads at scale, this moves GPU scheduling from a black art to a first-class Kubernetes primitive.

Helm Releases 4.2.3 and 3.21.3

Helm, the package manager for Kubernetes, published patch releases on July 9, 2026: 4.2.3 for the v4 line and 3.21.3 for the v3 line. Both are routine maintenance releases, but they reflect the reality that Helm v3 remains in wide production use while v4 gradually gains adoption.

For platform teams managing chart repositories and deployment pipelines, staying current on patch releases is low-effort insurance against regressions and security issues. The Helm public calendar shows future releases well in advance, making it easy to slot updates into existing maintenance windows.

AWS Fine-Tunes Multi-AZ Routing in ECS Service Connect

On July 23, 2026, AWS announced zone-aware routing for Amazon ECS Service Connect. While this is an ECS feature, the pattern is one Kubernetes service meshes have also been chasing: keep traffic inside the same Availability Zone unless there is a health reason to cross boundaries.

ECS Service Connect uses Envoy sidecars to handle service discovery and load balancing. With zone-aware routing enabled by default, traffic is prioritized to healthy endpoints in the same AZ as the caller. Existing services require a one-time redeployment to activate the behavior. The payoff is lower latency and smaller cross-zone data transfer bills, with no application changes required.

What Platform Teams Should Prioritize

July’s updates paint a clear picture of where Kubernetes is headed:

Autoscaling is getting application-aware. The custom metrics exporter guide is a signal that CPU-based scaling is no longer sufficient for serious workloads. Teams should audit their HPA configurations and evaluate whether custom metrics would improve responsiveness.
The control plane is becoming leaner. etcd 3.7’s streaming reads and keys-only optimizations reduce the memory footprint of large clusters. For operators managing clusters with thousands of nodes, this translates to more stable API servers.
GPU scheduling is finally predictable. DRA graduating to stable in Kubernetes 1.36, combined with vendor drivers from NVIDIA and Red Hat, means AI workloads can be scheduled with the same rigor as any other Kubernetes resource.
Service mesh is becoming transparent. Zone-aware routing in ECS, and similar patterns in Kubernetes-native meshes, shows the industry converging on reliability and cost optimization without developer friction.