Kubernetes 1.37 includes several changes that may cause components to fail at startup or make existing monitoring and workloads behave differently. The biggest upgrade risks include removed or locked feature gates, removed kubelet cAdvisor flags, the removal of scheduling.k8s.io/v1alpha2 Workload and PodGroup objects, static Pods referencing Secrets or ConfigMaps, and the removal of kubeadm v1beta3 configuration support. These should be handled before upgrading, especially because some failures only appear when a node or control-plane component restarts.
There are also quieter behavior changes to check. An explicit eventRecordQPS value of 0 now means unlimited instead of falling back to 5 events per second, so clusters should set an intentional value. Several API-server, DRA, and cAdvisor metrics have been renamed or removed, which can make Prometheus rules stop matching without producing errors. kube-proxy now warns when its Linux proxy mode is implicit, ahead of the planned nftables default, and IPVS is entering deprecation. SELinux mount-time labeling can also expose conflicting labels on shared volumes and leave Pods stuck in ContainerCreating.
For the common checks, inspect each node's effective kubelet configuration through configz, search PrometheusRules for removed cAdvisor series, and verify that kube-proxy has an explicit mode. Also test the upgrade in a non-production environment first. I help maintain an open-source upgrade-checking tool and recently updated its checks for 1.37, but I would be interested in hearing about other breaking changes people have encountered.
3 Answers
The batch-scheduling changes are probably the most important for anyone who experimented with the built-in gang-scheduling APIs. Remove manually enabled gates such as JobSuccessPolicy before upgrading; a component with a removed or incorrectly fixed gate can refuse to start. If you used scheduling.k8s.io/v1alpha2 Workload or PodGroup objects, delete those objects before the upgrade and recreate them as v1beta1 afterward. This is not an in-place conversion, and v1beta1 is only served once the control plane is on 1.37.
Set kube-proxy's Linux proxy mode explicitly instead of relying on the current implicit default. That avoids being surprised when the default changes to nftables in a future release and makes the upgrade behavior clear. If you're using IPVS, this is also a good time to plan a migration because its deprecation is being phased in.
A general cluster-hygiene tool can help catch probes, resource settings, RBAC issues, and deprecated APIs, but it will not necessarily know about release-specific items like removed gates, kubelet flags, eventRecordQPS, or the scheduling API removal. Use it alongside targeted 1.37 checks, and run the whole process in non-production first. Some failures only appear when a component restarts on the new binary, so a successful current-cluster scan alone is not enough.
Also make sure you distinguish those built-in objects from Kueue's Workload CRD. Kueue uses a different API group, so this particular served-API removal does not automatically affect Kueue workloads.