Planning a Kubernetes upgrade from 1.36 to 1.37 before the first node moves
A self-managed kubeadm cluster on 1.36 can move to 1.37 without breaking workloads, but only if the platform team plans the move one minor version at a time and verifies each control plane member and worker before starting the next step. The team owns the whole cluster, so the plan must name who drains which node, when each control plane member is upgraded, and how the team will respond if the kube-apiserver health check fails during the change. The upgrade belongs on the calendar now because 1.36 reaches end of life on June 28, 2027, and the team needs time to rehearse the change in a non-production cluster well before that date.
Kubernetes ships about three minor releases per year on a cycle of roughly 14 weeks. The project maintains the three most recent minor releases, and as of September 2026 those were 1.37, 1.36 and 1.35. Version 1.37 is the newest of the three and reaches end of life on October 28, 2027, while 1.35 ends on February 28, 2027. Each minor version receives patches for only about a year, so a cluster that waits for a convenient quarter can drift onto an unsupported version. Confirm the current list on the Kubernetes releases page before setting target dates, because the list changes each time a new minor version ships.
The supported path is one minor version at a time, so 1.36 moves directly to 1.37, and any cluster still on an older minor version must step through each intermediate release first. The version skew policy requires kube-apiserver to be upgraded first, followed by kube-controller-manager, kube-scheduler and the kubelets. Kubelets may run up to three minor versions older than kube-apiserver, which gives the team room to upgrade worker groups in batches. That allowance is a safety margin for scheduling work, and the plan should still finish every node on 1.37 within the agreed window. Write the upgrade order down and record the kubelet and kubectl versions at each stage.
Three decisions should be made before the first node moves. First, confirm the cluster topology: whether etcd is stacked on the control plane nodes or runs as an external cluster, and whether there are at least three control plane nodes behind a TCP load balancer on port 6443. That topology determines how many members can be taken out of service at once. Second, schedule a rehearsal on a copy of the cluster that uses the same add-ons and workloads. Third, name the person who approves the change window and the person who can stop it. Ask the internal owner or implementation partner to confirm the exact package versions and kubeadm upgrade steps for 1.37 against the official documentation before the change window is booked.
What changes between 1.36 and 1.37 and what each change asks of your team
This table lists the categories of change to review before upgrading a kubeadm cluster from 1.36 to 1.37, with the impact of each and the action your team needs to take. Use the 1.37 release notes on kubernetes.io as the authority for specific removals, defaults and flags, and treat each row as a question to answer for your cluster before the upgrade window opens. The main takeaway is that the control plane must move first, and every category should be cleared against the release notes before any node is drained.
| Change | Impact | Action needed |
|---|---|---|
| Version skew and support window | kube-apiserver must move to 1.37 first, one minor version at a time. Kubelets may run up to three minor versions behind it. | Upgrade kube-apiserver before other control plane components. Note that 1.36 patch support ends June 28, 2027, per kubernetes.io/releases. |
| Removed or deprecated APIs | Manifests, Helm charts and operators that call APIs removed in 1.37 will fail to apply or reconcile. | Check the API removals section of the 1.37 release notes and scan your manifests and charts before the upgrade starts. |
| Changed defaults | Default values in components can change behavior for existing workloads and cluster add-ons. | Read the defaults section of the 1.37 release notes and compare results with your current kubelet and apiserver settings. |
| Removed or changed flags | Systemd units, scripts and automation that pass removed or renamed flags will stop components from starting. | Search your automation for flags named in the 1.37 notes and confirm each new name in the component reference. |
| Container runtime and kubelet requirements | Minimum runtime and kubelet versions can change, and nodes below the minimum may fail to join or run pods. | Confirm the supported runtime versions in the 1.37 notes and upgrade any runtime that falls below them before draining nodes. |
| kubeadm configuration changes | Changes to kubeadm config API versions or fields can affect how upgrade plan and apply read your cluster settings. | Export the current ClusterConfiguration, review the kubeadm section of the 1.37 notes and migrate the config before running upgrade plan. |
| Control plane images and registry access | kubeadm needs the 1.37 control plane images. Clusters without internet access must have them mirrored in advance. | Run kubeadm config images list for 1.37 and confirm every image is available in your registry or pulled through your mirror. |
| Etcd state and backups | The control plane upgrade changes cluster state in etcd, so a failed step may need a restore from snapshot. | Take an etcdctl snapshot save backup of each etcd cluster and confirm the restore path with etcdutl before starting. |
Why 1.36 to 1.37 is a single step and how version skew shapes the rollout
Moving from 1.36 to 1.37 is one minor version step, and the rollout order is set by the Kubernetes version skew policy. The kube-apiserver must move first, and it can move only one minor version at a time. Only after it runs 1.37 do the kube-controller-manager, kube-scheduler and kubelets follow. For your cluster, the control plane nodes go to 1.37 first, and the change should not combine a minor jump with other changes. Treat the apiserver as the gate: nothing downstream should move ahead of it. Your change record should show that order explicitly, because it is the sequence a change board or auditor will ask you to explain.
Kubelets may run up to three minor versions older than kube-apiserver. That tolerance is what lets you move worker nodes in batches, and it is why a node still on 1.36 is within policy once the control plane reaches 1.37. Use the tolerance for scheduling, not as a standing arrangement. A node left behind keeps running an older kubelet, misses fixes and behavior changes in newer releases, and makes the next upgrade harder because the version gap widens. Set a finish date for the worker rollout and track which nodes still report older versions until the last one is moved. Report the version spread across the cluster at every checkpoint.
Concretely, the sequence for this topic is: upgrade the first control plane node, then the remaining control plane nodes, then drain and upgrade worker kubelets in batches. The controller manager and scheduler run on control plane nodes, so they move with that stage, not on a separate schedule. Before you start, check the kubectl version your operators and pipelines use against the version skew policy, and confirm that any automation or GitOps tooling that calls the API is compatible with 1.37. Choose the batch size from your spare capacity and your PodDisruptionBudgets, because those settings determine how many workloads can be evicted at once.
Confirm the exact patch release you will install on the day of the upgrade. Patch numbers change over time, so check the kubeadm documentation and the Kubernetes releases page on that day rather than relying on any earlier copy of this guidance. Record the target in your change ticket, along with the kubeadm version, the kubelet and kubectl package versions for each node pool, and the time you checked. If the target changes between planning and execution, rerun the plan step and update the record before continuing. This check helps prevent mismatched packages across nodes that were upgraded in different sessions.
Backups, inventory and a rehearsal cluster to complete before 1.37
Six items must be finished and written down before the first control plane node is changed. Together they make the upgrade reversible, show which workloads and add-ons will break, and let the team practice the exact steps on a copy of production.
Verified etcd snapshot
Take a snapshot with etcdctl snapshot save from a control plane node before any change, then copy it off that node. A snapshot that has never been restored is only a file, so run a restore rehearsal on a scratch host with etcdutl and confirm the cluster state comes back as expected. Record the etcd version, endpoint and certificate flags used, because the restore steps depend on them. For a stacked topology, also confirm where each control plane member keeps its data so the rehearsal matches your real layout.
Deprecated API usage inventory
List every manifest, Helm chart and operator that calls an API version removed or changed in Kubernetes 1.37. Scan the live cluster as well as the Git repositories, because applied objects can differ from what is stored in source control. Check each operator's release notes for its own minimum Kubernetes version, since an operator can block the upgrade even when your manifests are clean. Assign each finding an owner and a fix date, and use the deprecation guide and kubectl convert where a manifest needs rewriting.
Webhook, CRD, CNI and CSI compatibility list
Record every validating and mutating admission webhook, every custom resource definition, and the CNI and CSI components in use. For each one, note its namespace selectors, its failure policy and the Kubernetes versions its vendor documentation supports. A webhook with a fail-closed policy that cannot answer during control plane restarts can stop pods from being created, so flag those first. Confirm the compatibility status with each vendor for 1.37 and record the source and date of that confirmation.
Image mirror or private registry plan
For air-gapped clusters, run kubeadm config images list against the 1.37 target to get the control plane image set. Pull those images on a connected host with kubeadm config images pull, then push them to an internal registry. Include the images used by your CNI, CSI and monitoring components, which kubeadm does not manage. Point the upgrade at the mirror through the image repository setting in the kubeadm configuration, and confirm that every node can pull each image before the window opens.
Rehearsal cluster from production copy
Build a rehearsal cluster from a copy of the production kubeadm configuration, add-ons, admission policies, CRDs and representative workloads. Match the control plane topology, whether stacked etcd or an external etcd cluster, because the etcd steps differ between them. Run the upgrade plan, the apply step, the node drain order and the kubelet and kubectl package changes, then write down every deviation from the runbook. Redact secrets from the copy and apply the same access controls you use in production.
Change window and rollback owner
Schedule a change window and name one person with authority to call a rollback, plus a deputy. Write the rollback triggers in advance, such as failed health checks after a control plane node or a workload that stops serving, and link each trigger to the restore path from the etcd snapshot. Follow the version skew policy: kube-apiserver moves first and only one minor version at a time, and kubelets may trail the API server by up to three minor versions. Agree which partially upgraded states the team will hold and which it will reverse.
How etcd membership and backups change the kubeadm upgrade plan
The etcd topology decides the order of work in this upgrade and how much a single failed node can take with it. kubeadm supports two layouts. In the stacked control plane, each control plane node runs an etcd member alongside kube-apiserver, kube-controller-manager and kube-scheduler. In the external etcd layout, etcd runs on its own cluster and the control plane nodes only connect to it as clients. Confirm which layout your cluster uses before you read the rest of this plan, because the node-by-node sequence, the drain decisions and the rollback options differ between them. Write the layout down in the change record so every operator follows the same sequence.
In a stacked cluster, losing a control plane node also removes an etcd member, so the upgrade has no spare capacity while a node is out of rotation. etcd keeps quorum only while a majority of its members is healthy. Etcd should run with an odd number of members, because an even count adds a node without adding failure tolerance. The Kubernetes documentation recommends five members in production, and at least three control plane nodes is the floor for a highly available control plane. A three-member stacked cluster tolerates one unplanned failure, so a planned drain of one node uses up that tolerance until the node rejoins. Check member health before each node is drained, and stop the sequence if any member is unhealthy or missing.
The external layout separates the two upgrade streams. Control plane nodes can be drained and replaced without touching etcd quorum, but the etcd cluster needs its own version change, its own health gates and its own change window. Confirm the etcd version that the 1.37 release notes and the kubeadm documentation associate with your control plane, and read any etcd-specific notes in those release notes before the first node is touched. Do not assume that the etcd version you run today is the one the new release expects. Decide who owns the etcd nodes before the change window opens, because a plan that covers only the Kubernetes nodes will leave etcd on the old version and create a mixed state nobody planned for.
Behind the control plane, a TCP load balancer in front of kube-apiserver on port 6443 keeps kubectl, kubelets and controllers pointed at one address while individual API servers restart. Without at least three control plane nodes behind that address, a restart during the rolling sequence can leave a single API server answering all traffic, and any further fault then becomes an outage. Test the load balancer health check against each API server, and confirm that a node removed from the pool stops receiving requests before you drain it. Record the load balancer address and port in the runbook so that the people running the upgrade and the people on call use the same endpoint.
Take an etcd snapshot before the first change and copy it off the cluster. etcdctl snapshot save writes a point-in-time copy of the keyspace from a healthy member, and it is a safety net if an upgrade step corrupts cluster state. Restoring is a different operation. etcdutl restores a snapshot into a new data directory, which rebuilds the cluster from that point, so anything written after the snapshot is lost. Rehearse the restore on a non-production copy so the runbook is proven before it is needed. Treat restore as an incident decision, and write down who authorizes it, who runs it and how workloads are checked afterward.
How a kubeadm Kubernetes upgrade runs node by node, from the first control plane to the last worker
This sequence moves a kubeadm cluster from 1.36 to 1.37 one node at a time, starting with the first control plane node and ending with the last worker. Each node closes with a health check, and the first control plane node carries a documented etcd rollback point. The result is a cluster on the 1.37 line with every node verified before the next one changes.
Check health and snapshot etcd
Before any node changes, confirm that every node reports Ready, that control plane pods and etcd members are healthy, and that no workload is stuck in a failed state. Take a snapshot with etcdctl snapshot save, using the endpoint and certificate flags for your cluster, then verify the file with etcdutl snapshot status. Copy the snapshot to storage outside the control plane nodes. This step is done when the verified snapshot is stored off-node and the cluster state, including the kubeadm and kubelet versions on every node, is recorded in the change record.
Run kubeadm upgrade plan on one control plane
On the first control plane node, run kubeadm upgrade plan to list the 1.37 patch releases kubeadm can install and the component versions it will change. Confirm that the target is a 1.37 release and that the version skew policy allows the order you have planned, with kube-apiserver moving before kube-controller-manager, kube-scheduler and kubelets. Record the patch release you choose and the plan output in the change record. The step is complete when the plan names the target version and shows no blocking preflight errors that you have not resolved.
Upgrade kubeadm and apply the 1.37 patch
On the first control plane node, install the 1.37 line of the kubeadm package from the per-minor-version package repository, then run kubeadm upgrade apply with the patch release you chose. This upgrades the control plane static pods, including kube-apiserver, kube-controller-manager and kube-scheduler, along with the cluster configuration that kubeadm stores. Run kubeadm version to confirm the binary, then check that the control plane pods restart and report healthy. The step is done when kubeadm upgrade apply reports success and the API server answers requests with the new version.
Drain and upgrade kubelet on first control plane
Drain the first control plane node with kubectl drain, using --ignore-daemonsets and the other flags your workloads need after you review what will be evicted. Upgrade kubelet and kubectl from the same 1.37 package repository, run systemctl daemon-reload, restart kubelet, and uncordon the node. Confirm the node reports Ready with the 1.37 kubelet version and that its static pods are running. Check the drain flags against the kubectl documentation for your version, because eviction behavior depends on your workloads. The step is done when the node is Ready and schedulable.
Hold the first control plane rollback point
Once the first control plane node runs 1.37 and passes its health checks, keep the etcd snapshot from the first step as the rollback point for this stage. Record the version of every node, the snapshot name and checksum, and the time of each change. Document the etcd restore procedure before continuing, so the team knows the steps in advance. Any rollback after later nodes change is a restore decision that a package downgrade cannot replace. The step is done when the record is complete and the change owner approves continuing to the other control plane nodes.
Upgrade remaining control plane nodes
On each remaining control plane node, in turn, drain the node, install the 1.37 kubeadm package, and run kubeadm upgrade node to update the local control plane components and kubelet configuration. Then upgrade kubelet and kubectl, restart kubelet, and uncordon the node. After each node, confirm that etcd has the expected member count and a healthy leader, that the API server answers through the load balancer on port 6443, and that the node reports the 1.37 version. Do not start the next control plane node until these checks pass.
Upgrade worker nodes one at a time
Upgrade workers in a planned order, often grouped by node pool or zone so that enough capacity stays available for the workloads on each group. For each worker, drain the node, install the 1.37 kubeadm package, run kubeadm upgrade node, upgrade kubelet and kubectl, restart kubelet, and uncordon the node. After each worker, confirm that it is Ready at 1.37, that its pods have rescheduled and passed readiness, and that no PodDisruptionBudget blocks the next drain. The window is complete when every worker reports 1.37 and the health checks from the first step pass.
Which checks prove each node is safe before the next node moves
The gate after each node is a set of checks that must all pass before the next node is drained. Start with the control plane because every later step depends on it. Confirm that kube-apiserver answers through the TCP load balancer on port 6443 and that its readiness endpoint reports healthy, using a verbose readiness request so the individual checks are visible. Confirm that the kube-apiserver, kube-controller-manager and kube-scheduler static pods in kube-system are Ready on every control plane node. In a stacked topology, check etcd with endpoint health and endpoint status across all members, looking for healthy members, one elected leader and matching raft indexes. Run the same commands after every node so the results can be compared directly.
Next, check the upgraded node and the workloads around it. The node should report Ready, and the wide node listing should show the kubelet version you planned for the target release, matching the packages installed on that host. Check that system DaemonSets, including your CNI plugin and CSI node plugins, show desired and ready counts that agree on every node. Then schedule a small test workload pinned to the upgraded node and to at least one other node, and confirm it is reachable through a ClusterIP Service and through your ingress path. Run the test in a namespace whose Pod Security Admission level matches production, so the test does not depend on relaxed settings. Before you start, confirm with your CNI and CSI vendors that their current releases support Kubernetes 1.37, because a DaemonSet can be healthy and still run a build that does not suit the new control plane.
Write the pausing rules into the runbook before the first node moves. Any failed check stops the sequence: no further drain, no kubelet upgrade on the next host, and no control plane change until the cause is understood. Separate transient failures, such as a pod that becomes Ready after a slow image pull, from failures that persist past a wait window your team agrees in advance. Name who may resume the sequence and who must approve a rollback. Keep the uncordon step visible in the runbook so a node left cordoned after a failed attempt is found and returned to service. The version skew policy allows kubelets to be up to three minor versions older than kube-apiserver, so a node that stays on an older kubelet during the rollout does not by itself count as a failure. Track it as a deliberate exception with a named owner and a date by which it must be closed.
Keep evidence that a reviewer can replay later. For each node, store timestamped output of the checks: the readiness response, the control plane pod listing, the etcd health and status tables, the node list with kubelet versions, the DaemonSet status, and the test workload's responses through the Service and the ingress. Attach the kubeadm upgrade plan and apply output, the package versions installed on each host, and the etcd snapshot file name, checksum and time taken. Tie each record to the change ticket and the node name. Record every failure and the decision that followed, including who approved each pause and each resume. Store snapshots outside the cluster with access controls that match the sensitivity of the data, because etcd holds Secrets in unencrypted form unless encryption at rest is configured.
Decide in advance when to fix forward and when to restore. Fix forward when the control plane is healthy, etcd has quorum and a leader, and the fault sits in one node, one kubelet or one add-on that can be corrected without rolling back cluster state. Plan a restore from the etcd snapshot only when quorum is lost, the data is inconsistent, or the API server cannot serve the state the control plane expects. Restoring returns cluster state to the moment the snapshot was taken, so changes made after that point must be found and reapplied, and the restore steps in the etcd documentation must be followed member by member. Rehearse both paths in the rehearsal cluster, covering the workloads your teams run and every upgrade command, including the restore. Production validation then runs the same checks, in the same order, with the same scripts, so the rehearsal evidence applies to production.
What makes a 1.36 to 1.37 upgrade take longer than the kubeadm commands suggest
This table lists the factors that expand a 1.36 to 1.37 kubeadm upgrade beyond the command sequence, with the reason each one adds work and what to request in a quote. Read each row against your own inventory, since the largest effort often comes from extensions that touch the API server, image supply for air-gapped networks and the rehearsal that proves the sequence. The main takeaway is that a quote should state how each driver is handled, so scope does not shift after the change window opens.
| Driver | Why it adds effort | What to ask for in a quote |
|---|---|---|
| Control plane and worker node count | Each control plane node is upgraded in sequence behind the load balancer, and each worker needs a drain, package update and health check. More nodes mean more cycles and more verification points. | Node inventory with roles, the drain order to be followed, and whether the provider runs each node or hands over a runbook for your team. |
| etcd topology: stacked or external | Stacked etcd upgrades alongside each control plane node. External etcd adds a separate member upgrade path and requires a verified snapshot before the first change. | Confirmation of topology, the snapshot and restore test plan, and who owns etcd backups during the window. |
| Admission webhooks, custom controllers, operators and Helm charts | Webhooks that fail or reject requests during control plane restarts can block pods and reconciliation. Operators and charts may pin API versions or need a newer release before the cluster can move. | Inventory of webhooks with failure policy and owners, a chart and operator version matrix for 1.37, and a test case for each extension in the rehearsal. |
| CNI and CSI compatibility | Network and storage plugins must support the target minor version, and their upgrades can disrupt pod networking or volume attachment on each node. | Written confirmation of supported plugin versions from each vendor, the upgrade order for plugins, and rollback steps for each plugin. |
| Air-gapped image mirroring | Control plane, add-on and workload images must be in a private registry before the change. A missing image stops the upgrade at the point it is needed. | The image list for 1.37 and add-ons, the mirror location and sync process, and evidence that the mirror was tested from an isolated node. |
| Workload disruption tolerance and pod disruption budgets | Tight budgets, single replicas and stateful workloads slow node drains and can stall the sequence until workload owners agree on moves. | Workload inventory with replica counts and budgets, owner sign-off on acceptable disruption, and a drain plan for each workload tier. |
| Change window restrictions | Limited windows, freeze periods and approval gates split the work across sessions, and each restart needs a fresh health check before the next node. | The calendar of allowed windows, the escalation path during a freeze, and a plan for pausing safely between sessions. |
| Rehearsal environment size | A rehearsal cluster that differs from production in node count, add-ons or data can hide failures that appear only at full scale. | Rehearsal topology matched to production, the method for copying data, and the rehearsal steps included in the fixed scope. |
| Number of clusters | Each cluster repeats the full sequence, its own checks and its own rollback plan, while some tasks such as image mirroring and plugin testing are shared. | Effort listed separately for shared tasks and per-cluster tasks, and whether the same runbook is reused across clusters. |
What buyers ask before they upgrade Kubernetes 1.36 to 1.37 themselves or hire help
What drives the cost of a Kubernetes 1.36 to 1.37 upgrade, and what should a quote include?
Cost depends mainly on how many clusters and node pools are in scope, whether etcd is stacked on the control plane nodes or external, how current your manifests and add-ons are, and how much pre-production testing your environment needs. DeployOpen works from a fixed written scope, so the quote should list each cluster, its control plane layout, every worker node pool, and add-ons that need compatibility checks, such as the CNI, ingress, storage drivers and GitOps tooling. Ask whether a rehearsal in a non-production cluster, change window support and post-upgrade verification are included, and what written evidence you receive at the end. Ongoing support and the next minor upgrade are separate decisions, usually handled as a retainer. DeployOpen does not publish a price list, so the quote follows the scope.
How long does a kubeadm minor version upgrade take, and what changes the schedule?
Duration depends on the number of clusters and nodes, the control plane topology, how many workloads must be drained and rescheduled, and how long your change approval and test cycles take. Kubernetes publishes new minor releases about three times a year, and the version skew policy requires the API server to move one minor version at a time, so each cluster moves from 1.36 to 1.37 as a single step. Ask for the timeline to appear in the written scope, and confirm it against a rehearsal on a cluster that matches production node pools and add-ons. Common schedule extenders include PodDisruptionBudgets that block node drains, slow image pulls on restricted networks, and failed compatibility checks that need fixes before the production window.
What does a kubeadm upgrade need from our team before work starts?
The work needs administrative access to the control plane and worker nodes, including kubeconfig with cluster-admin rights, SSH access and sudo on each node, and read access to the cluster's current state. You also need a named change approver, an agreed maintenance window, and a non-production cluster that mirrors production versions, node pools and add-ons. Confirm that etcd snapshots can be taken and stored off the cluster before the window opens. For clusters without internet access, you need an internal package mirror for kubelet and kubectl and a private image registry that holds the control plane images. Finally, name an application owner who signs off on workload behavior after each node returns to service.
Can our internal team run a kubeadm 1.36 to 1.37 upgrade without a partner?
Yes, an internal team with kubeadm experience can perform the upgrade using the upstream kubeadm upgrade documentation. The deciding factors are hands-on experience with node drains, etcd snapshots and restores, add-on compatibility, and on-call coverage for the window. Check whether two or three engineers have performed a control plane upgrade end to end, whether someone can read API server and etcd logs under pressure, and whether there is a rehearsal environment. A partner adds fixed scope, a second set of hands during the window, and written verification records, which many teams need for change reviews. Either way, the decision should rest on a documented runbook and a tested rollback path, not on confidence alone.
What happens if a kubeadm upgrade fails partway through the cluster?
Stop the sequence and do not start the next node until the failed node is understood. Recovery depends on where the failure occurred: a failed control plane upgrade may leave the API server or etcd unhealthy, while a failed kubelet package install may leave one worker node cordoned or out of service. Before starting, take an etcd snapshot with etcdctl snapshot save, verify it, and store it outside the cluster. If control plane data is damaged, restore from that snapshot with etcdutl, following the documented procedure for your topology. Keep package versions recorded so kubelet and kubectl can be reverted or pinned. Confirm the rollback steps in your rehearsal, and agree on who makes the decision to restore.
Will DeployOpen make our Kubernetes cluster certified or compliant after the upgrade?
No. DeployOpen does not issue audit reports, attestations or certifications, and an upgrade alone does not make a cluster certified. CNCF Certified Kubernetes conformance is a program for distributions that checks required API support, and the CIS Kubernetes Benchmark is a secure configuration guide that assessors may use as a reference. DeployOpen can prepare the cluster and evidence for a compliance assessment, such as configuration records, version history, backup test results and a mapping of cluster controls to the framework your auditor uses. Independent auditors and certification bodies make the determination. Ask your assessor early which evidence they expect, so the upgrade records are gathered in the form they need.
Should we check for removed APIs in our manifests before moving to 1.37?
Yes, check before the upgrade starts, because manifests, Helm charts and operators that call removed APIs can fail after the API server changes. Review the Kubernetes release notes for 1.37, scan your Git repositories and running cluster for deprecated API versions, and confirm that each operator and Helm chart supports 1.37. Fix findings in a non-production cluster first, then re-test the affected workloads. Include CRD-based operators, such as ingress controllers, storage operators and GitOps controllers, because their maintainers may publish compatibility notes on their own schedules. Record the scan results and fixes, since they become part of the change file and the evidence you may need for review.
Do we need an etcd backup before upgrading the control plane?
Yes. Take an etcd snapshot before the first control plane node is changed, verify that it can be read, and store a copy outside the cluster. Kubernetes documentation uses etcdctl snapshot save for backups and etcdutl for restores, and it recommends an odd number of etcd members, with five members commonly used in production. Stacked and external etcd topologies need different handling, so confirm which one your cluster uses before the window. A snapshot that has never been restored in a test environment is an untested assumption, so schedule a restore rehearsal as part of the preparation. Keep the snapshot until the upgraded cluster has run through your agreed verification period.
How DeployOpen scopes, runs and supports a Kubernetes upgrade
DeployOpen treats the 1.36 to 1.37 upgrade as a planned change to your control plane, nodes and workloads, run in the infrastructure you already operate. Each engagement starts with a written scope that names the clusters, the topology and the checks to be run before, during and after each step.
How we scope
- The written scope names each cluster, its kubeadm topology and the 1.36 nodes included in the upgrade.
- Scope confirms whether the stacked or external etcd topology applies, since etcd steps change with it.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any node is touched.
How we build
- Preflight checks confirm the cluster is on 1.36, etcd snapshots are verified and workload manifests are reviewed.
- Control plane nodes move one at a time, beginning with kubeadm upgrade plan and apply on the first node.
- Worker nodes are drained, upgraded with kubelet and kubectl packages, then returned to service in sequence.
How we hand over
- Each node gets a post-change check record covering node status, control plane health and pod scheduling.
- Runbooks document the order of operations, rollback points, etcd snapshot locations and the verification commands used.
- Your team receives the cluster record, change log and handover session before the engagement closes.
How we support
- Retainers can cover later patch and minor upgrades; the 1.36 end-of-life date is June 28, 2027.
- Ask whether the retainer includes the next upgrade window, and confirm what is in and out of scope.
- Support scope should name who watches version skew, certificate expiry and etcd health between windows.
