Kubernetes 1.37 arrived with 67 enhancements.
Platform teams do not need to understand all 67 before planning an upgrade.
Three changes are worth looking at more closely because they affect how clusters can be secured, how idle workloads can be scaled, and how a long-used metrics API is supported.
They are:
- rootless kubelet moving to Beta;
- HPA scale-to-zero moving to Beta;
- the Kubernetes Metrics API becoming stable.
None of these means you should upgrade immediately.
But they are worth understanding before your next Kubernetes upgrade cycle.
Rootless kubelet is getting closer to practical use
Kubernetes node components have traditionally run with root privileges on the host.
Kubernetes 1.37 moves KubeletInUserNamespace, often described as rootless Kubernetes, to Beta.
The idea is straightforward.
Instead of running the kubelet and related node components with full root access to the host, they can run inside a Linux user namespace as a non-root host user.
If a container-runtime or node-component vulnerability is exploited, reducing host-level privileges can reduce the damage an attacker is able to cause.
That is a useful security improvement.
But there is an important detail.
The feature gate is enabled by default in Kubernetes 1.37, but existing clusters do not suddenly become rootless. The node still has to be deliberately configured to run inside a user namespace.
For platform teams, that means this is something to test rather than something that automatically changes during an upgrade.
Compatibility matters too.
Some CNI or CSI drivers may still expect privileges that are available on a normal rootful node. Kubernetes itself notes that some drivers can have compatibility problems in rootless environments.
So the useful question is not:
Can Kubernetes now run without root?
It can.
The practical question is:
Can our Kubernetes stack run correctly that way?
That includes the container runtime, networking, storage drivers, node monitoring and any software that needs host-level access.
Rootless mode is a security improvement worth testing.
It is not a switch I would enable across production nodes without a staging cycle first.
Scale-to-zero is especially interesting for expensive workers
Horizontal Pod Autoscaler normally keeps at least one replica running.
Kubernetes 1.37 changes that.
HPA scale-to-zero is now Beta and enabled by default. A workload can scale all the way down to zero replicas and later start again when work arrives.
For ordinary lightweight workloads, that may be useful.
For GPU-backed AI or batch workloads, it can be much more interesting.
If a worker exists only to process jobs from a queue, keeping a GPU-backed pod alive while the queue is empty can waste expensive capacity.
With scale-to-zero, Kubernetes can remove that last idle replica.
There is a catch.
The HPA cannot use normal CPU or memory utilisation to wake the workload again.
Once there are no pods, there is no CPU or memory usage to measure.
The scaling signal therefore has to come from something that still exists while the pods are gone, such as:
- queue depth;
- pending jobs;
- another object metric;
- an external metric.
There is also cold-start time.
When work arrives, Kubernetes has to notice the metric, schedule a pod and start the application before processing begins.
That may be fine for background workers.
It is less suitable for a user-facing HTTP service that is expected to respond immediately. Kubernetes Services do not hold requests until a scaled-down application starts, so request-driven workloads need another buffering mechanism.
For AI platforms, this creates a useful trade-off:
lower idle cost versus slower first response.
That is the part teams should measure.
Do not enable scale-to-zero simply because it can save money.
Test how long the workload takes to become useful again.
Metrics API becoming stable is less dramatic, but still important
Kubernetes 1.37 also promotes metrics.k8s.io to stable v1.
This is the API used for CPU and memory metrics behind tools such as kubectl top and resource-based autoscaling.
For most teams, nothing dramatic changes.
The resource types and fields remain the same as the previous v1beta1 API.
That is actually the point.
This is not a new observability feature.
It is Kubernetes formally giving a long-used API the stability guarantees associated with a GA API.
For platform teams maintaining integrations, automation or internal tooling around Kubernetes resource metrics, that reduces uncertainty around a dependency that has remained in Beta for years.
Useful, but not something that requires redesigning your monitoring stack.
What should teams test before upgrading?
The Kubernetes 1.37 release contains many more changes, but these three lead to a fairly short upgrade checklist.
If you want to explore rootless nodes, test your CNI, CSI, runtime, monitoring and host-level tooling before considering production use.
If you plan to use scale-to-zero, make sure your workload has a reliable external or object metric and measure the full cold-start time.
If your internal tools consume the Metrics API directly, check whether they are ready for metrics.k8s.io/v1, even though the API structure itself has not materially changed.
And as with any Kubernetes upgrade, test the actual platform you run rather than assuming that a feature becoming Beta or GA means every component around it is ready.
The useful part of Kubernetes 1.37
Kubernetes releases can easily become long lists of feature gates and enhancement numbers.
For most platform teams, that is not the useful way to read them.
Kubernetes 1.37 has some important changes, but three stand out for practical reasons.
Rootless kubelet gives teams another way to reduce node-level privilege.
Scale-to-zero can reduce the cost of workloads that do not need to stay running, particularly expensive workers such as GPU-backed jobs.
And the Metrics API finally moves from a long Beta period into a stable API.
None of them requires an immediate production change.
But all three are worth putting into the next staging and upgrade discussion.