Kubernetes 1.37: upgrade starts with deprecations and defaults, not new features

The signal and the facts that change the decision

Version 1.37 combines Stable, Beta, and Alpha enhancements, but operating change appears in maturity states and defaults. The official announcement includes Beta features enabled by default, features that remain opt-in, and one deprecation or removal; every cluster needs to compare current configuration with the final state.

The 1.37 announcement declares 16 Stable graduations, 23 Beta graduations, 27 Alpha entries, and one deprecation or removal. According to the official announcement, etcd RangeStream enters Beta enabled by default and requires etcd 3.7 or an automatic fallback.

Other functions, such as PodAndContainerStatsFromCRI, remain Beta but disabled by default; maturity alone does not determine behaviour. A manifest can remain schema-valid and still fail because of an incompatible controller, driver, or webhook. Enabling a Beta in production merely because it is available mixes release evaluation with functional change and expands rollback surface.

Decision, limits, and stop condition

Produce a behavioural diff covering changed feature gates, removed or deprecated APIs, and requirements around etcd, kube-proxy, cgroups, SELinux, webhooks, CSI, and metrics. Test new capabilities only after proving the existing path remains supported.

A manifest can remain schema-valid and still fail because of an incompatible controller, driver, or webhook. Enabling a Beta in production merely because it is available mixes release evaluation with functional change and expands rollback surface.

Execution and proof of completion

Execution should start by capturing actual flags and versions for control plane, nodes, etcd, runtime, cni, csi, admission, and observability. Then, running api scanners and compatibility tests with the same production workload and plugins. Closure requires keeping new features off in the first wave unless explicitly needed, isolating the version change from the product change.

The gate closes when the default-value diff is approved, no removed APIs remain, every add-on declares compatibility, and canary tests confirm equivalent behaviour and metrics before any additional feature is enabled.

• capturing actual flags and versions for control plane, nodes, etcd, runtime, CNI, CSI, admission, and observability.
• running API scanners and compatibility tests with the same production workload and plugins.
• keeping new features off in the first wave unless explicitly needed, isolating the version change from the product change.
• The gate closes when the default-value diff is approved, no removed APIs remain, every add-on declares compatibility, and canary tests confirm equivalent behaviour and metrics before any additional feature is enabled.