Kubernetes doesn't stand still, and neither should the platform decisions built on top of it. Over the past several weeks, the project shipped a new stable release, Gartner published its latest view of the container management vendor landscape, and AI workloads continued pulling the roadmap in a new direction. Here's what happened, in plain terms, and what it means if you're responsible for an enterprise container platform in the US or Australia.
1. Kubernetes 1.37 Garhwal: What Shipped and Why It Matters
The Cloud Native Computing Foundation released Kubernetes 1.37, codenamed Garhwal, in late August 2026, with the project explicitly framing the release around stability, security, and AI/ML workload optimisation. The release totals 67 enhancements across alpha, beta, and stable stages.
The headline change is the Metrics API (metrics.k8s.io) reaching general availability after roughly nine years in beta. This API underpins the Horizontal Pod Autoscaler, Vertical Pod Autoscaler, and the everyday kubectl top command, so its graduation to stable gives operators a dependable, versioned foundation for autoscaling decisions rather than a technically-still-beta dependency.
• Resilient watchcache initialisation reached general availability, preventing the API server from overwhelming etcd with requests after a restart in large clusters.
• HorizontalPodAutoscaler scale-to-zero support graduated to beta, enabled by default useful for cost control on GPU-backed AI/ML workloads that sit idle between jobs.
• Native histogram support for Kubernetes metrics graduated to beta, enabled by default, improving observability precision.
• The next release, Kubernetes 1.38, is expected by December 2026, keeping the project on its established roughly four-month cadence.
2. Security Hardening Takes Center Stage
Several 1.37 changes point toward the same goal: shrinking what an attacker can reach if a node or pod component is compromised.
Rootless kubelet (beta):
controlled by the KubeletInUserNamespace feature gate and enabled by default, this lets core node components including the kubelet, container runtime, and kube-proxy run as non-root on the host via Linux user namespaces, while still behaving as root inside the namespace. It's a meaningful reduction in blast radius for node-level vulnerabilities.
Native pod certificates for mTLS (stable):pods can now request short-lived X.509 certificates directly via a PodCertificateRequest, without standing up cert-manager or SPIFFE/SPIRE, giving workloads native, short-lived identity out of the box.
Manifest-based admission control (beta, default-on):administrators can now load validating and mutating admission policies and webhooks from files on the API server host, tightening how cluster-wide policy gets applied.
Handling undecryptable resources (beta):administrators can now remove resources the API server can no longer decrypt through the normal Kubernetes API with a dry-run mode instead of hand-editing etcd directly.
3. AI and GPU Workloads Are Reshaping the Kubernetes Roadmap
The through-line across this release and the broader 2026 ecosystem is AI. Kubernetes is increasingly described across the industry as the default operating layer for AI-driven services, not just traditional microservices coordinating bursty, GPU-hungry training jobs alongside continuously running inference services on one common control plane.
• Alpha support for workload-aware scheduler preemption (InPlacePodVerticalScalingSchedulerPreemption) lets the scheduler free up resources on an at-capacity node by preempting lower-priority workloads directly relevant to clusters juggling GPU contention.
• Alpha support for pod-level checkpoint and restore, backed by a new Kubernetes Checkpoint/Restore Working Group, opens the door to pausing and resuming long-running training jobs more cleanly.
• Kubeflow, the Kubernetes-native MLOps toolkit, passed 260 million cumulative downloads roughly nine years after its debut a concrete signal of how much AI/ML tooling now assumes Kubernetes underneath it.
4. Gartner's 2026 Magic Quadrant for Container Management
Gartner published its 2026 Magic Quadrant for Container Management on September 2, 2026, evaluating 16 vendors including AWS, Google, Microsoft, Red Hat, Broadcom (VMware), Nutanix, Oracle, and several others. Gartner's framing is direct: infrastructure and operations leaders now need to prioritise vendors that deliver AI capabilities including GPU orchestration and agent infrastructure alongside operational consistency and security, to support modernisation at scale.
Nutanix was recognised as a Challenger for the second consecutive year with its Nutanix Kubernetes Platform (NKP), notable for running Kubernetes consistently across virtualised, bare-metal, public cloud, edge, and air-gapped environments a reminder that container management evaluations increasingly weigh hybrid and disconnected deployment support, not just public-cloud-native capability.
The broader takeaway for enterprise buyers: container management is no longer scored primarily on orchestration basics. AI/GPU support, operational consistency across environments, and security posture are now first-order evaluation criteria.
5. Broader Ecosystem Moves Worth Watching
• Amazon EKS expanded advanced control plane configuration options in mid-August 2026, giving enterprise customers finer-grained control over managed cluster behaviour.
• Consolidation continued across the virtualization-to-Kubernetes vendor landscape through the second half of 2026, a trend worth tracking for any business currently standardised on a single hyperscaler-adjacent platform vendor.
• CNCF continues to publish regular case studies on large-scale GPU-sharing and heterogeneous compute setups, reflecting how quickly AI infrastructure patterns are maturing on top of Kubernetes.
6. What This Means for Enterprise Platform Teams
None of this news is reason to panic-upgrade a production cluster, but it is reason to plan deliberately. The pattern across 1.37, the AI/GPU roadmap direction, and Gartner's evaluation criteria all point the same way: platform teams that treat Kubernetes upgrades and vendor selection as routine, scheduled decisions — rather than reactive, once-a-year scrambles are better positioned to take advantage of features like rootless mode and scale-to-zero autoscaling as they mature.
7. Preparing Your Cluster for 1.37 and 1.38 Ahead
Check your node OS and container runtime for cgroup v1 usage several 1.37 changes assume cgroup v2, so this is the one item worth verifying immediately.
Review which alpha and beta feature gates are enabled by default in 1.37 against your cluster's risk tolerance before upgrading.
Confirm your autoscaling tooling (HPA/VPA integrations, custom dashboards) is compatible with the now-stable Metrics API v1 endpoint.
If you're running GPU workloads, evaluate whether scale-to-zero autoscaling and workload-aware scheduler preemption (alpha) fit your cost and scheduling goals.
Set a recurring review cadence aligned to Kubernetes' roughly four-month release cycle, rather than upgrading reactively.
8. Security and Compliance Considerations (US & Australia)
United States
US enterprises running regulated workloads on Kubernetes typically map cluster hardening decisions like adopting rootless kubelet and native pod identity against existing frameworks such as the AWS Well-Architected Framework's security pillar and SOC 2 Type II control requirements.
Australia
Australian enterprises, particularly those in APRA-regulated sectors already operating under CPS 230's operational resilience requirements, should treat Kubernetes cluster security posture as part of their broader technology risk register, especially as admission control and workload identity features mature from beta to stable.
9. Managed vs. Self-Managed Kubernetes in 2026
As the platform gets more capable, it also gets more to operate. Many enterprises are re-evaluating whether tracking every feature-gate change, security hardening option, and quarterly release themselves is the best use of a platform team's time versus working with a managed provider who tracks the release cycle, tests upgrades, and applies hardening changes like rootless mode on a defined schedule.
Conclusion
Kubernetes 1.37 is a stability-and-security release wrapped around a clear AI-workload subtext, and Gartner's 2026 evaluation confirms the market now judges container platforms on the same terms. For enterprise teams in the US and Australia, the practical takeaway is the same either way: treat Kubernetes as a platform that needs a deliberate upgrade and security review cadence, not a set-and-forget layer underneath the applications that matter.
Not sure whether your clusters are ready for what's shipped this cycle or what's coming in 1.38? Nuwair Systems can review your current Kubernetes platform against the latest release and security guidance.Start with a Kubernetes Readiness Review with us
FAQ Section
What's new in Kubernetes 1.37?
Kubernetes 1.37, codenamed Garhwal, shipped 67 enhancements including general availability of the Metrics API, beta rootless kubelet mode, stable native pod certificates for mTLS, and beta scale-to-zero support for the Horizontal Pod Autoscaler.
When was Kubernetes 1.37 released?
Kubernetes 1.37 was released in late August 2026, with the next minor release, 1.38, expected by December 2026 on the project's roughly four-month cadence.
What is rootless kubelet mode?
Rootless kubelet mode, reaching beta in 1.37, lets core node components run as non-root on the host through Linux user namespaces, reducing the impact of a compromised node-level component.
Why does the Metrics API matter for enterprises?
The Metrics API underpins the Horizontal and Vertical Pod Autoscalers and the kubectl top command. Its move to general availability in 1.37 gives operators a stable, dependable API for autoscaling after nearly nine years in beta.
How is AI changing Kubernetes’ adoption?
Kubernetes is increasingly used as the common control plane for AI/ML workloads, coordinating GPU-intensive training jobs alongside inference services, with recent releases adding features like workload-aware scheduler preemption and scale-to-zero autoscaling to support this.
What is the Gartner Magic Quadrant for Container Management?
It's Gartner's evaluation of container management vendors, published September 2, 2026, for its 2026 edition, assessing 16 vendors on their ability to support AI capabilities, operational consistency, and security at enterprise scale.
Which vendors lead in Kubernetes container management?
Gartner's 2026 evaluation covers major hyperscalers (AWS, Google, Microsoft), enterprise infrastructure vendors (Red Hat, Broadcom/VMware, Nutanix, Oracle, SUSE), and others; specific quadrant placements are detailed in Gartner's comprehensive published research.
How often does Kubernetes release new versions?
Kubernetes follows a roughly four-month release for minor versions, with 1.37 shipping in August 2026 and 1.38 expected by December 2026.
What should enterprises check before upgrading Kubernetes?
Check node OS and runtime cgroup version compatibility, review which new alpha/beta feature gates are enabled by default and confirm monitoring and autoscaling tooling is compatible with any newly stable APIs.
What is the difference between managed and self-managed Kubernetes?
Managed Kubernetes has a provider that operates the control plane and often helps with upgrades and security hardening; self-managed Kubernetes puts the full operational burden, including tracking releases like 1.37, on the internal platform team.
