Kubernetes 1.37: What’s New and Why It Matters

Kubernetes 1.37 represents a significant convergence of improvements built on real production experience. Learn what changed from 1.35 through 1.36 to reach this release, understand the actual breaking changes, and discover why this release matters for your infrastructure.

Quick Navigation

Why Kubernetes Releases Matter More Than You Might Think

You’re running Kubernetes in production. Your clusters are stable. Your applications are deployed. Then you hear about a new Kubernetes release, and someone asks: should we upgrade?

Most teams treat Kubernetes upgrades like a software update—a technical chore to handle eventually. But Kubernetes versions are fundamentally different. Each release isn’t just bug fixes. It’s the evolution of how you manage infrastructure based on what thousands of teams have learned in production.

Think of Kubernetes versions like the evolution of building blueprints. Each version doesn’t invent a new building technique. Instead, it takes feedback from architects and builders who’ve constructed real buildings, discovers what works and what doesn’t, and improves the blueprint for everyone else.

Here’s what matters: with each version, Kubernetes learns from real production systems. Teams run clusters with thousands of pods. They encounter problems. They report them. The community fixes them. By the time a new version comes out, it’s not theoretical—it’s battle-tested improvements built on actual experience.

Understanding this matters because it helps you decide not just whether to upgrade, but when. It helps you understand what problems the community solved that might apply to your specific infrastructure challenges.

The Journey: How We Got from 1.35 to 1.37

To understand Kubernetes 1.37, you need to understand the path that led here. It’s not three random versions. Each one solved specific problems, and each built on solutions from before.

Kubernetes 1.35 - December 17, 2025

The focus was on predictability and resource efficiency at scale. Teams running massive clusters struggled with resource allocation logic. 1.35 introduced improvements to how Kubernetes decides whether a pod can fit on a node and refined the logic for what “requesting resources” actually means. It wasn’t glamorous, but it made Kubernetes more predictable when running with hundreds or thousands of pods.

Kubernetes 1.36 - Late April 2026

Based on feedback from production systems running 1.35, 1.36 focused on operational smoothness and observability improvements. Teams discovered that while resources were allocated efficiently, understanding what was happening inside the cluster was still difficult. 1.36 enhanced what the kubelet tracks and reports, improved networking edge cases, and refined how pods are disrupted during updates.

Kubernetes 1.37 - August 26, 2026

This version represents a convergence of resilience improvements. It brings significant architectural enhancements to how Kubernetes handles watch operations (how you monitor cluster state), better metrics visibility, and improvements to how you express and manage pod security and trust. This release is where distributed systems hardening meets practical operational improvements.

The progression tells a story. 1.35 asked “how do we allocate resources correctly?” 1.36 asked “how do we understand what’s happening?” 1.37 asks “how do we make the infrastructure more resilient and observable?”

Kubernetes 1.35: Foundation and Efficiency

Let’s set the context by understanding 1.35. Imagine you’re running a cluster with 500 pods spread across 50 worker nodes. Everything is working, but something feels inefficient. The scheduler is sometimes making decisions that waste resources. Pod placements don’t seem optimal.

This was the challenge 1.35 tackled. The release introduced improvements to resource scheduling logic that made pod placement more predictable. When you request 512Mi of memory for a pod, Kubernetes now calculates more accurately what that means in terms of actual node capacity.

What Changed in 1.35

  • Resource request semantics: How Kubernetes interprets resource requests became more consistent and predictable across different scenarios
  • Scheduling improvements: The scheduler made better decisions about where to place pods, reducing fragmentation
  • Autoscaling refinements: Node autoscaling became more conservative, reducing unnecessary node additions

The key insight: 1.35 forced teams to be more intentional about resource management. If you were casual about setting resource requests and limits, 1.35 would surface those issues. This was necessary pain—it meant better efficiency for teams who paid attention.

Kubernetes 1.36: Building on Stability

By mid-2026, teams had been running 1.35 in production. What did they discover? That resource efficiency alone wasn’t enough. They needed better visibility and smoother operations.

Imagine debugging why a pod keeps getting evicted. You look at metrics and logs. Everything seems fine—your pod uses 800Mi of memory out of 2Gi available on the node. But it crashes anyway. What’s happening?

Kubernetes 1.36 was built to answer questions like this.

What Changed in 1.35

  • Enhanced observability: The kubelet started reporting more detailed breakdowns of memory and resource usage. You could now see not just total consumption, but system overhead versus application consumption
  • Pod Disruption Budget improvements: When Kubernetes drains nodes during updates, PDBs control how many pods can be evicted. 1.36 made this smarter with better topology-aware logic
  • Networking reliability: Subtle edge cases in connection tracking and service discovery were fixed

For operations teams, these weren’t flashy features. But they were transformative. Debugging mysterious pod crashes became possible because you had actual data instead of guesses. Node draining during updates became more predictable and reliable.

Here’s what 1.35 and 1.36 together tell you: the Kubernetes community was focused on the fundamentals. Not new features. Not bleeding-edge capabilities. But making the core orchestration better, more predictable, and more understandable.

Kubernetes 1.37: Convergence and Resilience

By August 2026, with more than a year of production experience with 1.35 and 1.36, the community had a clear understanding of what needed to happen next. Not efficiency. Not observability. But making the infrastructure fundamentally more resilient and trustworthy.

1.37 represents a convergence point. It brings together several architectural improvements that have been in development across multiple release cycles.

The Philosophy Behind 1.37

If you had to sum up 1.37: it’s about making Kubernetes more resilient and more trustworthy. This isn’t just technical polish. It’s about hardening the foundation for production systems that can’t afford to go down.

This release focuses on three core areas: making cluster state monitoring more reliable, improving how workloads can express trust and security requirements, and refining resource management at deeper levels.

The Major Features You Need to Know About

1. Resilient Watch Cache Initialization (Now Stable)

Here’s a problem that happens in large clusters: when the API server restarts, it needs to rebuild its internal cache of cluster state. In clusters with hundreds of thousands of objects, this rebuild can be a significant bottleneck.

Kubernetes 1.37 graduates “Resilient watchcache initialization” to stable. This feature improves cache rebuilding through multiple mechanisms: concurrent watch object decoding, graceful handling of overload during initialization, and support for etcd range streaming queries. Together, these improvements make the cache rebuild process faster and more reliable.

In benchmarks involving 150,000 pods, concurrent watch decoding reduced watch-cache initialization time by approximately 40%. When combined with etcd RangeStream, the improvement is even more significant.

Why This Matters

The watch mechanism is how Kubernetes stays coordinated. Everything from controllers to kubectl depends on reliable watch operations. Faster cache initialization means the API server recovers more quickly from restarts and stays more responsive under stress.

2. Metrics API Graduates to Stable

The Kubernetes Metrics API has been around for years, but it was in beta. This API is what tools like the Horizontal Pod Autoscaler and kubectl top use to get resource usage data. Graduating it to stable signals that the API is stable and reliable for production use.

More importantly, it means the Kubernetes community is committing to not breaking this API’s contract. For tools built on metrics, this means guaranteed compatibility going forward.

3. Pod Certificates and ClusterTrustBundles Graduate to Stable

One of the hardest problems in Kubernetes is certificate and trust management at scale. Pods need identifiable, verifiable credentials. Cluster operators need a way to distribute trusted certificate authorities. Kubernetes has had the infrastructure for workload identity and trust bundle distribution, but it was in beta.

In 1.37, Pod Certificates and ClusterTrustBundles graduate to Stable. This means Kubernetes now has a production-ready mechanism for issuing short-lived certificates to individual pods and distributing cluster trust bundles that workloads can use to verify other pods’ identities and validate certificates.

This infrastructure is essential for organizations that need strong workload identity, pod-to-pod mTLS, or compliance requirements around certificate management. For more details on this feature, the Kubernetes project published a dedicated blog post on August 28, 2026.

4. Resource Health Status Becomes Stable

Dynamic Resource Allocation (DRA) is how Kubernetes handles special resources like GPUs, custom accelerators, and other hardware. In 1.37, resource health status (the ability for pods to report the health state of device resources) graduates to Stable. This allows the Pod status to expose health information for both Device Plugin and DRA-provided resources.

For teams running machine learning workloads or GPU-heavy applications, this means Kubernetes can now reliably track whether special hardware is functioning correctly, enabling better resource management and faster detection of hardware failures.

5. Gang Scheduling Graduates to Beta

Kubernetes has historically scheduled pods independently. But in the real world, workloads often need multiple pods to be placed together as a group. If only some of those pods can be scheduled while others remain pending, the workload is stuck in a partially-scheduled state, wasting resources.

Gang scheduling, which graduates to Beta in 1.37, allows related pods to be treated as a scheduling group. The scheduler won’t place any of the pods in a gang unless a minimum number can be placed together. This reduces the risk of partially-scheduled workloads and improves resource utilization for batch jobs, machine learning training, and other grouped workloads.

Breaking Changes You Need to Know About

Every Kubernetes release includes breaking changes. These aren’t bugs—they’re intentional removals of old features. They require action before you upgrade.

⚠️ Important Changes in 1.37

1. Workload API Version Change

The scheduling.k8s.io Workload API has been promoted from v1alpha2 to v1alpha3, and v1alpha2 is completely removed. This affects users who have opted into the alpha Workload APIs for gang scheduling.

Impact: If you have any manifests using scheduling.k8s.io/v1alpha2, they will fail to apply after upgrading.

Action required: Update your Workload API manifests to use scheduling.k8s.io/v1alpha3 before upgrading. (This does not affect normal Deployments, Services, or PriorityClasses.)

2. Metrics API Graduation (No Breaking Changes)

The metrics.k8s.io API graduates from v1beta1 to v1 in 1.37. However, v1beta1 remains available during the transition, so existing clients can continue using the beta version without issues.

3. Feature Gate Removals (Scheduler-Related)

In 1.37, WorkloadAwarePreemption was merged into the GenericWorkload feature gate, while gang scheduling is now part of the GenericWorkload workflow.

Action required: Remove GangScheduling and WorkloadAwarePreemption from your scheduler configuration before upgrading.

4. SELinux Volume Labeling (CSI Driver Opt-In)

The SELinuxMount and SELinuxChangePolicy features graduate to Stable in 1.37 and are enabled by default. However, the new mount-based labeling behavior only applies when the CSI driver explicitly opts in via CSIDriver.spec.seLinuxMount: true.

Action required: If you’re running clusters with SELinux enforcement and custom CSI drivers, verify that CSI drivers have the correct seLinuxMount configuration before upgrading. In most cases, this won’t affect existing workloads unless the CSI driver opts in to the new behavior.

5. DRA Resource Health Status

Resource health status functionality for Device Plugin and DRA is now Stable in 1.37. If you have custom device plugins that interact with resource health APIs, verify they’re compatible with the stable API before upgrading. The v1alpha1 DRA resource health interfaces will be deprecated in future releases.

Action required: Update custom device plugins to use the stable resource health API if you’re actively using DRA.

Planning Your Upgrade to 1.37

Understanding the Upgrade Path

Here’s something important that’s easy to get wrong: you cannot skip Kubernetes versions. If you’re running 1.35 and want to go to 1.37, you must upgrade through 1.36. There’s no shortcut.

This is by design. Kubernetes maintains forward compatibility within a release stream, but it doesn’t guarantee you can skip versions. APIs might change, deprecated features might be removed, and the control plane components expect to migrate through each step.

So your upgrade path is: 1.35 → 1.36 → 1.37. Not 1.35 → 1.37.

Timeline and Support

Kubernetes currently releases roughly three minor versions per year, approximately every four months. The project supports the three most recent versions with patches. That means right now (August 2026), versions 1.37, 1.36, and 1.35 receive patches. Version 1.34 and older receive no security patches.

Each version receives roughly 14-15 months of total support. Version 1.35 (released December 17, 2025) enters maintenance mode on December 28, 2026 and reaches end-of-life on February 28, 2027.

The Upgrade Checklist

Pre-Upgrade Steps

  1. Inventory your API versions. Scan all your YAML manifests for uses of scheduling.k8s.io/v1alpha2 and metrics.k8s.io/v1beta1. These need to be updated before upgrading. Use kubectl get –all-namespaces -o json | grep -i apiVersion to find everything in your cluster.
  2. Check your feature gates. Review your scheduler configuration for GangScheduling and WorkloadAwarePreemption feature gates. If they exist, remove them.
  3. Test in staging. Always upgrade a test cluster first. Run your actual workloads, monitor for several hours, look for errors in logs and metrics.
  4. Review add-ons. Ingress controllers, service meshes, observability tools—check if their latest versions support Kubernetes 1.37.
  5. If you use SELinux: Test your workloads in a 1.37 staging cluster to identify any volume labeling issues before production upgrade.
  6. If you have device plugins: Ensure they’re updated to support the new DRA API if they implement Dynamic Resource Allocation.
  7. Plan your maintenance window. Document the upgrade process, estimate how long it will take (typically 2-4 hours for medium clusters), and ensure the right people are on-call.

The Upgrade Process

For managed Kubernetes (AKS, EKS, GKE, etc.): Your cloud provider handles most of the complexity. They’ll notify you when upgrades are available, let you choose a maintenance window, and manage the upgrade automatically. You mainly need to ensure your applications are compatible.

For self-managed Kubernetes:

  1. Upgrade control plane components first. Update the API server, controller manager, and scheduler to 1.36 (if you’re currently on 1.35). These can usually be updated without taking the cluster fully offline.
  2. Upgrade each node’s kubelet sequentially. For each node, drain its pods, upgrade the kubelet and container runtime, then mark the node as schedulable again. This ensures your applications keep running while you upgrade the infrastructure underneath them.
  3. Verify the upgrade worked. Check that all nodes are Ready, all system pods are Running, and your applications are functioning.
  4. Finally, upgrade kubectl and other client tools. This is the least critical step—kubectl can be one minor version ahead or behind the cluster.

Post-Upgrade Validation

After upgrading, don’t assume everything is fine. Check:

  • Are all nodes reporting as Ready? (kubectl get nodes)
  • Are all pods running? (kubectl get pods --all-namespaces)
  • Do your smoke tests pass?
  • Are your application logs clean? Look for deprecation warnings or compatibility issues.
  • Monitor API server performance and latency for the first few hours.
  • Check if any alerts fired that didn't fire before (might indicate incompatibilities)

What This Means for Your Infrastructure

If You're Running 1.35

You should plan to upgrade. 1.36 has operational improvements that make day-to-day management easier, and 1.37 brings resilience improvements that matter if you care about uptime. Since you must upgrade sequentially, plan for the 1.35 → 1.36 upgrade in the next month or two, then 1.36 → 1.37 after that.

If You're Running 1.36

Upgrade soon. 1.37 builds directly on 1.36 and the upgrade path is lower risk. The breaking changes are relatively minimal, mostly affecting edge cases and advanced APIs.

The Bigger Picture

Understanding what changed in each Kubernetes version is crucial for anyone operating Kubernetes. It’s not just about knowing features—it’s about understanding the philosophy of how Kubernetes evolves and where it’s heading.

One way to interpret the progression from 1.35 to 1.36 to 1.37: each release focused on different operational dimensions. 1.35 improved resource scheduling predictability. 1.36 enhanced observability and operational smoothness. 1.37 advanced resilience and workload identity. This trajectory shows the maturity arc of the platform. The community isn’t chasing flashy new features. It’s solving real production problems that teams encounter at scale.

This is how infrastructure matures—not through revolutionary features, but through steady, relentless improvement of the fundamentals.

What's Next

Kubernetes 1.38 is coming in late 2026. Based on the trajectory, we can expect continued focus on stability and reliability, possibly with improvements to storage orchestration, enhanced security primitives, and better multi-cluster management.

But that’s speculation. What’s certain is that Kubernetes continues to evolve based on what thousands of teams learn in production. Your experience running Kubernetes, the issues you encounter, the solutions you need—that feedback shapes the next release.

Deepening Your Knowledge

Understanding Kubernetes release evolution, upgrade strategies, and production operations is becoming increasingly critical. If managing Kubernetes infrastructure at scale matters to your career, consider learning:

  • How to design Kubernetes architectures for your specific use cases
  • Advanced networking, storage, and security in Kubernetes
  • Observability and debugging at scale with Kubernetes
  • GitOps workflows and continuous deployment strategies
  • Building incident response and disaster recovery procedures

Organizations are increasingly looking for engineers who understand not just how to deploy to Kubernetes, but how to operate it reliably, scale it confidently, and solve real production problems. This skill is becoming a career multiplier.

Summary: Kubernetes 1.37 represents significant progress in resilience and observability, building on improvements from 1.35 and 1.36. The upgrade path requires going through 1.36, there are specific breaking changes to address, but the improvements to watch cache initialization, metrics stability, and security are worth the effort. Understanding how Kubernetes evolves through versions like these helps you make better infrastructure decisions and run more reliable systems.

Ready to Master Kubernetes and Real-World DevOps?

Knowing how to deploy applications is only the beginning. Learn how to manage infrastructure, troubleshoot production issues, automate deployments, and build reliable DevOps workflows.

Build practical DevOps skills with CodeKerdos through hands-on learning and real-world projects.

Scroll to Top