Kubernetes just flipped on a capability a lot of platform teams have hacked around for years: in v1.37 the HorizontalPodAutoscaler can scale workloads down to zero and that behavior is Beta and enabled by default. If your infra team still assumes always-on pods, this release will change your economics and your runbooks overnight.
Making scale-to-zero a default-enabled Beta is a pragmatic move. The ecosystem already solved many of the hard bits — event-driven frameworks like KEDA and systems built on Knative have been scaling to zero in production for years — but enabling the HPA itself to accept minReplicas: 0 without feature gates removes a major friction point. You can use standard HPA APIs with external or custom metrics to gate pod creation instead of piecing together ad-hoc controllers or service meshes to tear down idle workloads.
Why scale-to-zero matters (and where it will break you)
-
Cost and density: For bursty or infrequently used services, scale-to-zero turns idle CPU and memory into real savings. At scale that effect compounds quickly. For platform teams managing large dev namespaces or ephemeral preview environments, this is immediate value.
-
Observability and metrics: HPA decisions still rely on metrics. If your metrics pipeline assumes pod-level telemetry present at all times, HPA scale-from-zero will appear to fail. You need an external signal (external/custom metrics, push metrics, or event-driven adapters) and adapters like the Prometheus Adapter or KEDA will behave differently when pods are absent.
-
Cold start and readiness: Containers that take long to initialize, rely on heavy images, or depend on sidecars will incur latency spikes. Service meshes and L7 proxies often assume stable pod IPs; expect more 503s if your routing topology doesn’t tolerate short-lived backends. Fix probes, reduce image sizes, and re-evaluate in-cluster DNS/sidecar expectations before turning everything loose.
This is the right call from upstream. HPA is the obvious abstraction for workload autoscaling; enabling scale-to-zero stops teams from reinventing the same feature with fragile glue. But it will bite organizations that treat scaling as a pure control-plane toggle rather than a cross-cutting systems problem.
StorageVersionMigration v1 is GA — control plane finally takes responsibility
v1.37 also graduates StorageVersionMigration to GA: the StorageVersionMigration API and its controller are stable and enabled by default. That is a quieter but meaningful operational win. The control plane can now coordinate migration of persisted objects to the cluster’s preferred storage versions without the old manual dance of ns-copy, etcd snapshots, or bespoke tooling.
Practically, that reduces upgrade risk when CRDs evolve or APIs deprecate: the API server will be able to rewrite stored objects to the chosen storage version, and you can inspect migration status via StorageVersionMigration resources. GA isn't a magic bullet — custom conversion webhooks, incompatible schema changes, or CRDs without proper versioning still require human attention — but routine migrations now live in the control plane instead of brittle operator scripts.
One more practical signal: if your node images still pin an old or unsupported containerd release, schedule a runtime upgrade and verify behavior. Use this platform release as an opportunity to test both scale-to-zero flows and storage migrations against a supported container runtime and your distro's packaged containerd.
If you run clusters at anything like scale, v1.37 is more than a checklist release: it changes the default operating model. Expect teams to quickly adopt scale-to-zero for cost reasons — and to be surprised by the operational fallout if probes, metrics, and network assumptions aren’t revisited. StorageVersionMigration going GA signals a healthier control plane that will shoulder tedious migration work going forward; teams that ignore it will be the ones still scripting around etcd in 2027.
If you want a narrower read on other 1.37 cleanup items (cgroup v1 removal, kube-dns/IPVS deprecations), see my companion notes on the Garhwal release: Kubernetes v1.37 (Garhwal): cgroup v1 removed, kube-dns and IPVS legacy cleanup.
Final note: platform work used to be about installing and configuring features; increasingly it's about unblocking defaults that let engineering teams behave sensibly at scale. Enabling scale-to-zero and stabilizing storagemigration are both examples of upstream moving responsibility away from every cluster operator and into sane defaults — great for teams that pay attention, painful for those that don't.