Kubernetes 1.37 Upgrade Readiness Checklist

Kubernetes 1.37 is scheduled for August 26. Use this operator checklist to test version skew, cgroup v2, static Pods, PDBs, feature gates, and rollback steps.

Kubernetes 1.37 is scheduled for Wednesday, August 26, 2026, according to the release team’s tracking page. The release is close enough that the useful question is no longer “what might be in it?” It is “which assumptions in our cluster will be tested the moment the first node moves?”

The Kubernetes 1.37 sneak peek calls out several operator-facing changes: Static Pods can no longer reference Secrets or ConfigMaps, kube-proxy IPVS mode is deprecated, and cgroup v1 is still on the path to removal. The same preview describes expected graduation for metrics.k8s.io, rootless kubelet work reaching Beta, and SELinux volume-mount behavior changing for opted-in CSI drivers. Treat these as rehearsal items, not a reason to upgrade production on release morning.

This checklist focuses on a one-minor-version move from 1.36 to 1.37. Confirm your managed Kubernetes provider’s gates and maintenance window before scheduling the change.

What can change at the 1.37 boundary?

The most concrete compatibility check is for Static Pods. Kubernetes 1.37 prohibits Static Pods from referencing Secrets or ConfigMaps through fields such as secretRef and configMapRef; the preview says the PreventStaticPodAPIReferences feature gate is removed. Search those files directly on every control-plane node.

sudo grep -RInE 'secretRef|configMapRef|envFrom|secretKeyRef|configMapKeyRef' \
  /etc/kubernetes/manifests

The command is a screening pass, not a complete validator. Review each match in context. A Secret or ConfigMap mounted by a normal API-created Pod is a different case from a reference inside a Static Pod manifest. The Static Pod documentation explains that the kubelet reads local files from staticPodPath and creates a mirror Pod in the API server; deleting that mirror does not delete the local workload.

Next, find kube-proxy instances configured for IPVS. The 1.37 preview says IPVS mode logs a deprecation warning and remains available for now, but the project expects it to be disabled by default by 1.40 and removed by 1.43. Test the replacement mode rather than treating the warning as harmless noise.

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

If the result is ipvs, record current service behavior, test the replacement in a disposable node pool, and schedule the migration before a later release makes the old setting unavailable. Do not change modes in the same window as a control-plane upgrade without a tested rollback.

The other node-level check is cgroup version. Kubernetes documents cgroup v1 as deprecated, and the kubelet no longer starts on a cgroup v1 node by default. The cgroup v2 requirements include a Linux kernel of 5.8 or later, a compatible runtime, and the systemd cgroup driver for both kubelet and runtime.

stat -fc %T /sys/fs/cgroup/

cgroup2fs indicates cgroup v2. A node reporting the older filesystem type needs a migration plan before it joins a 1.37 pool. The documented failCgroupV1: false kubelet override is temporary. Check monitoring and security agents that read the cgroup filesystem directly; they may need cgroup v2 support.

Check version skew before touching the control plane

During a rolling upgrade, mixed versions are expected. Unbounded skew is not. The Kubernetes version-skew policy says that highly available kube-apiserver instances must stay within one minor version. kubelet and kube-proxy must not be newer than the API server and may be up to three minor versions older. kubectl is supported within one minor version older or newer than the API server.

For a 1.36 control plane moving to 1.37, check the oldest and newest value for each component:

Capture the inventory before the change and again after each control-plane host:

kubectl version
kubectl get nodes -o \
  custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,OS:.status.nodeInfo.osImage
kubectl -n kube-system get pods -l k8s-app=kube-proxy \
  -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,IMAGE:.spec.containers[0].image

The output does not replace provider-specific health checks, but it makes an accidental version jump visible. In an HA cluster with mixed API servers, the oldest server constrains the transition.

Admission webhooks deserve their own review. The version-skew policy requires registered webhooks to handle new resource versions and fields sent by the newer API server; matchPolicy: Equivalent can help. List every validating and mutating configuration, then test each endpoint with production authentication, CA bundle, network policy, and failure policy.

kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations \
  -o custom-columns=NAME:.metadata.name,RULES:.webhooks[*].rules[*].resources,FAILURE:.webhooks[*].failurePolicy

An admission webhook that times out can turn an upgrade into an API write outage. Record each owner and rollback path. If a team cannot explain how a webhook handles a new API field, it is not ready for the change window.

Rehearse the upgrade in the same order as production

The official cluster-upgrade overview gives the high-level order: upgrade the control plane, upgrade nodes, upgrade clients such as kubectl, then adjust manifests and resources for API changes. The exact commands depend on whether the cluster is kubeadm-managed, provider-managed, or manually installed.

Start with a staging cluster that matches production’s Kubernetes minor version, admission configuration, CSI and CNI versions, and node image. A clean development cluster can prove that 1.37 starts; it cannot prove that production extensions and budgets will permit the change.

Before the rehearsal:

1. Export critical objects and verify that the backup can be read. Include namespaces, workloads, Services, Ingress or Gateway resources, RBAC, admission configuration, storage objects, and provider settings.
2. Verify control-plane and workload recovery procedures with the person who owns the service. A backup that nobody can restore is an archive, not a recovery plan.
3. Record the current versions of the CNI, CSI drivers, device plugins, metrics-server, ingress controller, and policy engine. Read their compatibility matrices for Kubernetes 1.37.
4. Run a deprecated-API report from your observability or audit pipeline. Kubernetes documents client warnings, metrics, and audit information for locating deprecated API use; its API migration guide recommends testing with deprecated API versions disabled.
5. Freeze unrelated platform changes for the maintenance window. A node-image change, CNI upgrade, and Kubernetes minor upgrade in one step make a failed rollback much harder to diagnose.

For kubeadm clusters, follow the version-specific kubeadm upgrade procedure rather than copying commands from a different minor release. For a manual deployment, the overview lists etcd, kube-apiserver, kube-controller-manager, and kube-scheduler as the control-plane sequence, followed by clients and drained nodes. Managed services usually hide these component steps but still expose equivalent maintenance states.

Make node draining a designed test, not a surprise

Node upgrades create voluntary evictions. A PodDisruptionBudget limits concurrent disruptions, but it can also prevent a drain. A PDB with maxUnavailable: 0, minAvailable: 100%, or a minimum equal to the replica count allows no voluntary eviction.

Inspect PDB status before the rehearsal:

kubectl get poddisruptionbudgets -A
kubectl get poddisruptionbudgets -A -o \
  custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ALLOWED:.status.disruptionsAllowed,CURRENT:.status.currentHealthy,DESIRED:.status.desiredHealthy

Treat ALLOWED as a precondition, not a number to override. If it is zero, find out why: too few replicas, failed readiness, an overly strict budget, or a degraded workload. Fix the availability plan before the maintenance window. Do not delete a PDB just to make a command finish without service-owner approval and a restoration step.

Drain one canary node with the production flags and timeout. Confirm replacement Pods land on healthy nodes, Services regain ready endpoints, and stateful workloads reattach storage. The Pod lifecycle documentation defines Ready as the condition that puts a Pod into matching Service load-balancing pools; Running alone is not readiness.

Verify the platform after each stage

Do not wait until every node is upgraded to look for regressions. Verify after the control plane, after the first node pool, and after the full rollout.

Control plane checks

• Confirm every API server reports the intended minor version and remains reachable through the normal endpoint.
• Create and read a harmless test object in a staging namespace to exercise admission, RBAC, and storage.
• Check controller and scheduler logs for repeated errors, leader-election churn, and rejected resources.
• Confirm that custom resources, conversion webhooks, and API aggregation services answer successfully.

Node checks

• Confirm every node is Ready and reports the expected kubelet version.
• Check CNI and CSI DaemonSets, device plugins, and node-level policy agents.
• Run kubectl describe node on the canary and inspect conditions, allocatable resources, taints, and pressure signals.
• Confirm cgroup2fs on new Linux nodes and verify that agents still report CPU and memory correctly.

Workload checks

• Roll a representative Deployment and StatefulSet through the normal deployment path.
• Confirm readiness and liveness probes behave as they did before the upgrade.
• Exercise one request through each critical Service, including a path that depends on an admission policy or external secret integration.
• Check kubectl get events -A --sort-by=.lastTimestamp for image, mount, scheduling, and probe failures.

Resource metrics are a useful smoke test. The Metrics API documentation says metrics.k8s.io supplies basic CPU and memory data for nodes and Pods and supports HPA, VPA, and kubectl top. It also requires the API aggregation layer plus metrics-server or another adapter. Run:

kubectl top nodes
kubectl top pods -A
kubectl get apiservice v1beta1.metrics.k8s.io

A missing metrics API may not stop workloads from serving traffic, but it can silently impair autoscaling. Check it before declaring the upgrade healthy.

For queue workers that are designed to sleep when idle, the HPA scale-to-zero guide explains why the wake-up metric must remain available after the last worker exits. Treat that external-metrics path as a separate upgrade check from CPU and memory telemetry.

Feature gates need a before-and-after record. The feature-gate reference explains that stable features are always enabled, while alpha and Beta features can be configured with component-specific --feature-gates values. Export the effective configuration from your deployment system, compare it with the 1.37 supported table, and remove gates whose Until release has passed. Avoid introducing a new alpha gate during the same window as a minor-version change.

Three changes to rehearse this week

1. Test the node image, not only the Kubernetes binaries. Build a 1.37 node pool with cgroup v2, the production kernel, container runtime, CNI, CSI, monitoring agents, and security agents. Schedule a representative workload, drain a canary, and verify metrics plus network and volume paths.
2. Make Static Pod references and IPVS visible. Run the manifest search on every control-plane host, inspect the kube-proxy ConfigMap, and attach an owner and due date to every finding. Warnings without an owner tend to survive several release cycles.
3. Run the rollback on paper and in staging. Define the stop conditions, the last known-good node image, the control-plane recovery procedure, the workload restore point, and the person with authority to halt the rollout. A rollback plan that begins with “investigate” is not a rollback plan.

The release date is a useful forcing function, not a deadline to ignore evidence. If the staging rehearsal cannot drain a node, restore a workload, serve metrics, and keep admission healthy, keep production on its current supported patch level and finish the missing test first. The project maintains the most recent three minor release branches; check the release page for current support status and patch versions before choosing your maintenance target.

Read next

• Kubernetes readiness probe debugging
• Kubernetes KYAML: a safer YAML output format
• Kubernetes YAML linter
• Kubernetes version skew policy

Tags: #kubernetes, #upgrades, #kubelet, #platform engineering