Kubernetes Weekly: Karpenter Comes to OpenShift, GKE Agent Sandbox Hits GA, and containerd 2.3.3 Lands

The Kubernetes ecosystem kept moving fast this week, with major announcements from Red Hat, Google Cloud, and the containerd project landing within days of each other. From a new workload-aware autoscaler for OpenShift to a secure runtime for AI agents and critical CRI patches in containerd, here is what mattered in Kubernetes between July 14 and July 22, 2026.

Red Hat Ships Karpenter for OpenShift Service on AWS

On July 17, Red Hat announced the Red Hat build of Karpenter, bringing the upstream Karpenter project’s just-in-time node provisioning to Red Hat OpenShift Service on AWS (ROSA) with hosted control planes. The release coincides with OpenShift 4.22 and marks a meaningful shift in how ROSA clusters scale their compute.

Traditional machine pools require administrators to pre-define instance types and sizes. When demand spikes, the cluster scales out within those fixed boundaries. Karpenter flips that model: instead of scaling static pools, it evaluates the collective resource requirements of pending pods, provisions the optimal EC2 instance automatically, and consolidates underutilized nodes when they are no longer needed.

Key capabilities in the Red Hat build include:

Controllers in the hosted control plane — Karpenter runs as part of the managed control plane, not on worker nodes, eliminating extra pods and resource contention.
Enable on existing clusters — The feature can be turned on for existing ROSA clusters after upgrading to OpenShift 4.22, with no need to recreate infrastructure.
Independent upgrades — Karpenter can be updated separately from the cluster’s OpenShift version, decoupling autoscaler releases from platform releases.

What makes Karpenter different from traditional cluster autoscalers is its awareness of workload topology. Instead of waiting for a node pool to scale, Karpenter looks at the specific resource requests, scheduling constraints, and affinity rules of pending pods, then provisions the smallest EC2 instance that satisfies the combined requirements. When workloads finish or pods are rescheduled, Karpenter evaluates whether nodes have become underutilized and can be terminated, consolidating workloads onto fewer instances and reducing waste.

For teams running diverse workloads on ROSA, this removes the manual work of right-sizing instance families and provides a path to lower compute bills without sacrificing availability. The just-in-time approach is particularly valuable for workloads with irregular traffic patterns, such as batch processing jobs, development environments, and CI/CD pipelines.

GKE Agent Sandbox Hits General Availability

Google Cloud announced that GKE Agent Sandbox is now generally available, giving production workloads a secure, Kubernetes-native execution environment built specifically for AI agents. Since its preview at KubeCon NA in November 2025, sandbox adoption on GKE has grown more than 16x in under five months.

Agent Sandbox addresses a real problem: AI agents increasingly run untrusted code, call external functions, and maintain persistent terminal sessions. A standard Kubernetes pod is not designed for that threat model. Traditional containers share the host kernel, which means a compromised agent process can potentially escape to the underlying node. Agent Sandbox isolates agent execution using gVisor-inspired sandboxing, providing a boundary between the agent’s runtime and the host kernel.

The GA release delivers on several core requirements:

Pod snapshots — Agents often have bursty execution cycles followed by long idle periods. Pod snapshots let operators checkpoint agent state and resume later, reducing idle compute consumption.
Stable APIs — APIs that were in flux during preview are now stable, which has accelerated integration into the broader agent ecosystem.
Open-source foundations — Agent Sandbox is built on an open-source Kubernetes special interest group, avoiding single-vendor lock-in.

Google also introduced Agent Substrate, a new open-source project aimed at pushing agentic infrastructure density even further. While Agent Sandbox provides the isolation layer, Agent Substrate is designed to optimize how millions of agent sandboxes are scheduled, networked, and managed at scale. Early adopters like Langchain and Lovable are already deploying millions of agents into production on this stack, and the stable APIs have allowed other tooling vendors to integrate directly.

For platform engineers, Agent Sandbox represents a new category of Kubernetes workload. It is not a general-purpose container with a different label, but a fundamentally different isolation boundary designed for agents that execute untrusted logic on behalf of users.

GKE Standby Buffers Cut Cold-Start Latency

Alongside the Agent Sandbox GA, Google Cloud rolled out GKE standby buffers, a new autoscaling primitive that maintains low-cost suspended capacity inside a cluster. Under identical traffic loads, clusters with standby buffers kept P50 scheduling latency in the single-digit seconds, while unbuffered clusters suffered latency spikes of 4–6 minutes. The cost overhead is in the low single-digit percent.

Standby buffers build on the active buffers feature Google launched earlier this year. The difference is simple: active buffers hold warm, allocatable capacity; standby buffers hold suspended capacity that can be resumed quickly. Both map to the upstream Kubernetes CapacityBuffers API, which is making its way through the autoscaling working group.

Traditionally, autoscaling with standard Kubernetes has been effective but slow. Traffic surges or batch jobs require cluster autoscalers to provision fresh nodes, leaving pods in a pending state. To circumvent delays, platform engineers have resorted to workarounds like lowering Horizontal Pod Autoscaler thresholds or managing balloon pods. These approaches are expensive and operationally complex.

Standby buffers solve this by maintaining a pool of nodes that are suspended rather than fully running. When demand spikes, the suspended nodes are resumed almost instantly, providing near-zero scheduling latency. The cost overhead is minimal because suspended nodes do not consume the same compute resources as active nodes. For platform engineers, this removes the need for awkward workarounds and provides a native, cost-effective path to responsive autoscaling.

containerd 2.3.3 Patches CRI and Image Distribution Bugs

The containerd project shipped containerd 2.3.3 on July 10, the third patch release in the 2.3 series. While it is a maintenance release, it contains fixes that matter to anyone running Kubernetes with the Container Runtime Interface (CRI).

Notable fixes include:

CRI nil pointer fix — A nil pointer dereference in NRI GetIPs during pod sandbox teardown or container exit could crash the runtime. This is now resolved.
Sandbox shutdown on hook failures — When a RunPodSandbox hook fails, containerd now ensures the sandbox is shut down properly, preventing mount leaks that could accumulate over time.
Reject CreateContainer for non-running sandboxes — The runtime now rejects CreateContainer calls targeting a sandbox that is not running, avoiding inconsistent states that previously required manual intervention.
OCI error body surfacing — Registry 403 responses now fall back to GET requests to surface OCI error bodies, making authentication failures easier to diagnose without resorting to packet captures.
Windows SYSTEM temp directory override — On Windows, the SystemTemp environment variable is now set so that temp directory overrides work correctly for SYSTEM services.

Teams running containerd 2.3.x should plan to roll this out during their next maintenance window, especially if they use NRI or have seen mysterious sandbox cleanup issues. The registry error body fix is also worth noting for teams troubleshooting image pull authentication problems in restricted environments.

Upstream Kubernetes: Custom Metrics Exporters for HPA

The Kubernetes project published a new blog post on July 14 walking through how to build a custom Prometheus metrics exporter from scratch. The tutorial covers metric type selection (counters, gauges, histograms), registration with the Go Prometheus client, and wiring the exporter into the HorizontalPodAutoscaler (HPA).

The post is worth reading for teams that have outgrown CPU-and-memory-based autoscaling. Real-world scaling decisions often depend on signals like queue depth, active WebSocket connections, or batch job duration — none of which Kubernetes tracks natively. A small exporter bridging application state to Prometheus can unlock far more precise autoscaling.

The tutorial walks through a complete Go implementation, including how to package the exporter as a container and deploy it into a cluster. It also covers the distinction between direct instrumentation (embedding the Prometheus client in your application) and standalone exporters, which make more sense when the data source is external or when you do not control the application code. For teams hitting scaling limits with standard metrics, this is a practical starting point.

AWS: JVM Best Practices for Java Containers on EKS

On July 20, the AWS Containers team published a deep dive on JVM configuration for Java containers running on Amazon EKS and ECS. The article explains two categories of production issues that can cause containers to fail even when application code has not changed.

The first category is nondeterministic classpath resolution. Wildcard classpaths expand in filesystem-dependent order, which can shift after host kernel updates and silently load the wrong JAR version. This can trigger ClassNotFoundException or NoClassDefFoundError after routine OS patches, making root cause analysis particularly frustrating.

The second category is resource allocation mismatches between JVM defaults and container limits. Modern JVMs (Java 10+, backported to 8u191+) are container-aware for resource detection, but low-level operations still depend on the host kernel. The article recommends bundling dependencies into fat JARs, using explicit classpath ordering when fat JARs are not feasible, and configuring JVM memory flags to align with cgroup limits.

For Java shops on EKS, this is a practical reference that can prevent a class of hard-to-debug production issues.

OpenShift Edge Gets More Reliable with Two-Node Fencing

Also from Red Hat this week: two-node OpenShift with fencing is now available, improving reliability at the edge for retail, industrial, and telecommunications deployments. Traditionally, achieving high availability required a three-node cluster to establish a quorum. The cost of deploying a third node across thousands of edge locations has driven demand for alternative topologies.

The new two-node OpenShift configuration uses fencing to ensure that if one node fails, the surviving node can safely take over workloads without risking a split-brain scenario. This reduces hardware requirements while maintaining the availability guarantees that edge use cases demand.

What This Means for Platform Engineers

Three themes emerge from this week’s Kubernetes news:

Autoscaling is getting smarter — Karpenter on OpenShift and standby buffers on GKE both move beyond “add more of the same node” to right-size compute based on actual workload requirements. The cost savings and latency improvements are significant enough that these features should be on every platform team’s evaluation list.
AI workloads are reshaping Kubernetes — Agent Sandbox is not a generic container runtime with a new label. It is a fundamentally different isolation boundary designed for agents that run untrusted code. As AI agents become a standard workload type, expect more Kubernetes features to be designed with agentic execution in mind.
Patch discipline still matters — containerd 2.3.3 is a reminder that even mature runtimes need regular maintenance, especially when CRI stability is on the line. The nil pointer fix alone is worth the upgrade for anyone using NRI.

If you are running OpenShift on AWS, test Karpenter on a non-production cluster after upgrading to 4.22. If you are experimenting with agentic AI on GKE, the Agent Sandbox GA is a green light for production pilots. And if you are on containerd 2.3.x, add 2.3.3 to your next patch cycle.