Karpenter Arrives on OpenShift, etcd 3.7 Ships, and containerd Patches CRI: Kubernetes This July

The Kubernetes ecosystem is moving at a relentless pace this July, with major platform releases, new autoscaler capabilities, and foundational runtime updates that will reshape how teams operate clusters at scale. From Red Hat OpenShift 4.22 bringing Karpenter into the enterprise fold, to etcd 3.7.0 dropping with significant improvements, and containerd patching critical CRI bugs — there is a lot to unpack. Here is what matters right now.

Red Hat OpenShift 4.22: Karpenter Arrives, AI Foundations Strengthen

The biggest headline this month is the general availability of Red Hat OpenShift 4.22. This is not a minor point release — it represents a meaningful shift in how Red Hat approaches cluster scaling, security, and AI workload support. Platform teams who have been waiting for workload-aware autoscaling on OpenShift can finally stop waiting.

Karpenter Lands on OpenShift

For years, OpenShift users have relied on the Kubernetes Cluster Autoscaler to manage node pools. It works, but it is blunt: you define fixed machine pools with pre-configured instance types, and the autoscaler adds or removes entire nodes based on capacity thresholds. That approach inevitably wastes compute — either by over-provisioning to handle peak traffic, or by forcing workloads onto instance sizes that do not match their actual resource needs. Platform teams end up paying for headroom they rarely use.

With OpenShift 4.22, Red Hat is introducing the Red Hat build of Karpenter, initially available on Red Hat OpenShift Service on AWS (ROSA) with hosted control planes. Karpenter takes a fundamentally different approach. Instead of scaling fixed pools, it evaluates the collective resource requirements of pending pods — CPU, memory, scheduling constraints, taints, tolerations, and topology spread — and provisions the optimal EC2 instance just-in-time. When demand drops, Karpenter consolidates underutilized nodes and terminates them, continuously right-sizing the cluster footprint.

The consolidation logic is particularly clever. Karpenter does not just add nodes when pods are pending. It constantly evaluates whether workloads can be packed more efficiently onto fewer instances, then drains and removes the surplus nodes. This is not something Cluster Autoscaler does well — it scales up reactively and scales down conservatively, often leaving orphaned capacity. Karpenter treats the cluster as a bin-packing problem that it re-solves continuously.

The result is automatic right-sizing without manual intervention. Karpenter can also leverage Spot instances dynamically, comparing prevailing market rates against On-Demand pricing and selecting the cheapest viable option that satisfies workload constraints. For ML workloads, it integrates with Amazon EC2 On-Demand Capacity Reservations and Capacity Blocks for ML, which is critical for training jobs that need guaranteed compute. It can even dynamically choose between on-demand and reservation market types based on real-time utilization.

Notably, the Karpenter controllers run as part of the hosted control plane, not on worker nodes. That means zero overhead on your application capacity, and no extra pods competing for resources. Existing clusters upgraded to 4.22 can enable Karpenter without recreation, and it can coexist with the legacy Cluster Autoscaler during a gradual migration. Red Hat also notes that the build respects all Kubernetes scheduling constraints, taints, and tolerations, and slots into existing security postures including FIPS, SOC 2, and FedRAMP compliance.

Zero-Trust Security Hardens at the Core

OpenShift 4.22 also deepens its zero-trust posture. The platform is migrating core payload components to a minimal Red Hat Universal Base Image (UBI), stripping non-essential packages to shrink the attack surface. Fewer packages means fewer CVE disclosures, reduced patching cadence, and less time spent on emergency maintenance windows. Platform operators are also transitioning to dedicated, least-privilege identities, which reduces common audit findings and accelerates compliance sign-offs.

The zero trust workload identity manager is now generally available in version 1.1. Instead of relying on long-lived secrets or static certificates, it dynamically issues temporary, cryptographically attested identities to workloads at runtime. Combined with SPIRE and OpenShift Service Mesh, this eliminates static credential risk entirely. Workloads prove what they are, not just where they run.

For sensitive workloads, OpenShift sandboxed containers 1.12 brings confidential containers on bare metal to GA. Organizations can now isolate proprietary AI algorithms and sensitive data inside cryptographically isolated memory and CPU enclaves, providing hardware-level runtime protection. The release also introduces confidential AI as a technology preview, which could become significant for regulated industries running inference on sensitive models.

Hybrid Cloud Virtualization Advances

OpenShift Virtualization continues to close the gap between VMs and containers. The 4.22 release introduces ethernet virtual private network (EVPN) integration with user-defined networks, letting teams connect containerized and virtualized workloads to external infrastructure seamlessly. For organizations modernizing legacy VM estates, this removes a major networking friction point. The migration toolkit for virtualization also hit version 2.12, with advanced storage processing and AI-optimized migration paths.

etcd 3.7.0: The Data Plane Gets Attention

While etcd often lives in the background, it is the beating heart of every Kubernetes cluster. The release of etcd 3.7.0 this month is significant enough that operators should read the upgrade guide before touching production clusters.

This is a major version bump, which means there may be breaking changes. The etcd maintainers have been careful to document the upgrade path, and the release includes improved platform support and operational enhancements. Given that etcd stores the entire state of a Kubernetes cluster — every pod, service, configmap, and secret — any version upgrade requires careful planning. Back up your data, test the upgrade in staging, and follow the documented procedure.

What makes 3.7.0 worth the effort? Major etcd releases typically bring performance improvements, better compaction behavior, and refined Raft consensus handling. For large clusters with high churn rates, these changes can translate directly into lower API server latency and more stable control plane behavior. The etcd team also updates supported platforms with each release, so organizations on newer operating systems or architectures may find 3.7.0 resolves compatibility issues that have been nagging them.

containerd 2.3.3 Patches Critical CRI Bugs

The containerd project shipped version 2.3.3 on July 10, and this patch release contains fixes that matter for anyone running Kubernetes in production.

Three CRI-specific fixes stand out:

Nil pointer dereference in NRI GetIPs during pod sandbox teardown or container exit — a crash bug that could destabilize node-level operations and require kubelet restarts
CreateContainer calls rejected when the target sandbox is not running — preventing race conditions where containers get created against dead or dying sandboxes, which previously led to orphaned resources
Sandbox shutdown on RunPodSandbox hook failures — ensuring that when a sandbox hook fails, the sandbox is properly torn down instead of leaving mounts and network namespaces behind

On the image distribution side, containerd now surfaces OCI error bodies in registry 403 responses by falling back to GET requests when HEAD fails. This makes authentication and authorization debugging significantly less painful — no more opaque 403s with no explanation. The snapshotter layer also aligns the default 4K mkfs block size for EROFS across all platforms, improving consistency for filesystem-heavy workloads.

Containerd also updated its Go toolchain to 1.26.5 and migrated CI from Vagrant to Lima, showing the project continues to modernize its own infrastructure alongside the runtime itself.

AWS EKS Argo CD: Private Git Repositories Solved

AWS published a detailed walkthrough this month on connecting Amazon EKS capability for Argo CD to private Git repositories. This has been a persistent pain point for GitOps practitioners: Argo CD needs access to application manifests, but those manifests often live in privately hosted GitHub Enterprise Server or self-managed GitLab instances behind a corporate VPC.

The challenge is that the managed Argo CD capability does not have direct access to customer VPC networks. Without a bridge, teams were forced to either expose their Git servers publicly — a non-starter for many enterprises — or run self-managed Argo CD inside their VPC, losing the benefits of the managed service.

The solution uses AWS CodeConnections as a secure bridge. You create a CodeConnections host inside your VPC with connectivity to your private Git server, establish an IAM-authenticated connection, and let Argo CD pull manifests through it. The integration supports TLS certificates for privately signed CAs and maintains the security posture by avoiding direct VPC exposure. For organizations running GitOps at scale with private source control, this closes a long-standing architecture gap and makes the managed Argo CD capability viable for enterprise deployments.

Kubernetes Custom Metrics: Building Your Own Exporter

The upstream Kubernetes blog published a practical guide this month on building custom metrics exporters. The premise is simple but underappreciated: HorizontalPodAutoscaler can scale on CPU and memory out of the box, but real-world scaling decisions need richer signals — queue depth, batch job duration, active WebSocket connections, or business-specific metrics like orders-per-minute or payment-processing latency.

The guide walks through writing a Prometheus metrics exporter in Go, choosing the right metric types (counters for monotonically increasing totals, gauges for values that rise and fall, histograms for latency distributions), and wiring the exporter into the cluster so HPA can consume it via the custom metrics API. For platform engineers building internal developer platforms, this is essential reading. Custom metrics are the difference between naive autoscaling that reacts to CPU spikes, and intelligent elasticity that responds to actual business demand.

What This Means for Platform Teams

Taken together, July 2026’s Kubernetes news points to three converging trends:

Intelligent autoscaling is becoming table stakes. Karpenter’s arrival on OpenShift, combined with its existing AWS-native support, means the era of static machine pools is ending. Platform teams should evaluate workload-aware provisioning now, because the cost and efficiency advantages are too large to ignore.
Security is shifting left and down the stack. Minimal base images, dynamic workload identities, and confidential containers are not niche features anymore — they are becoming standard platform capabilities that every regulated industry will need.
The runtime layer keeps maturing. containerd and etcd releases may not grab headlines, but they are the foundation everything else runs on. Keeping these components current is non-negotiable for production stability. The CRI bug fixes in containerd 2.3.3 alone justify upgrading.