How to Upgrade Kubernetes Cluster to v1.36: Step-by-Step Guide

By Kedar Salunkhe | March 2026

Introduction to Upgrade Kubernetes cluster to v1.36

If you are running Kubernetes in production, staying current with the latest release is not optional — it is essential. Every new Kubernetes version brings security patches, performance improvements, and new features that help your cluster run more reliably at scale. This guide walks you through the complete Kubernetes v1.36 upgrade process, from preparation to verification, so you can carry it out with confidence.

The Kubernetes project follows a roughly quarterly release cadence. The latest Kubernetes version, v1.36, continues that momentum with meaningful additions to the control plane, networking, and storage subsystems. Whether you manage a small development cluster or a large multi-node production environment, knowing how to execute a Kubernetes cluster upgrade safely is one of the most critical skills in a DevOps engineer’s toolkit.

In this Kubernetes upgrade guide you will learn:

Why the Kubernetes v1.36 upgrade matters and what risks it mitigates
An overview of new features introduced in the latest Kubernetes version
How to back up your cluster before making any changes
A detailed, command-by-command upgrade walkthrough for control plane and worker nodes
How to verify a successful upgrade and troubleshoot common failures
The correct way to roll back if something goes wrong

What’s New in Kubernetes v1.36

Before diving into the upgrade steps, it is worth understanding what has changed. Each Kubernetes release graduates features from alpha to beta to stable, and v1.36 is no different.

Key Improvements in Kubernetes v1.36

Dynamic Resource Allocation (DRA) graduates to beta, making GPU and accelerator scheduling significantly more flexible
In-place pod resize moves closer to stable, allowing CPU and memory limits to be updated without restarting pods
Improved scheduler performance for large clusters with thousands of nodes
Structured authorization configuration is now generally available, replacing the older webhook-only model
Enhanced lease coordination for improved control plane resilience in multi-master setups

Security Enhancements

Node authorization improvements that further restrict what kubelet can access via the API server
Pod security admission policy refinements for stricter enforcement without breaking existing workloads
Service account token improvements with tighter expiration and audience binding
Audit logging enhancements that give operators more granular visibility into control plane activity
Removal of several long-deprecated insecure API endpoints, reducing the attack surface

Networking Improvements

LoadBalancer IP mode field graduates to stable, giving more control over how external IPs are allocated
Multiple service CIDR support allows operators to define more than one service IP range
Improved kube-proxy performance under heavy connection churn
Gateway API v1.2 compatibility improvements for next-generation ingress management

Storage Improvements

VolumeAttributesClass graduates to beta, allowing dynamic tuning of volume performance parameters
CSI migration for several legacy in-tree drivers moves to complete, pushing workloads to modern drivers
Improved volume health monitoring with richer status conditions on PersistentVolumeClaims

Prerequisites Before Upgrading Kubernetes

A successful Kubernetes cluster upgrade starts well before you run a single command. Skipping these prerequisites is the most common cause of failed upgrades. Take your time here — rushing pre-flight checks is never worth it.

Check Current Kubernetes Version

Always confirm what version you are running before you begin. You should only upgrade one minor version at a time — jumping from v1.34 directly to v1.36 is not supported and will likely break your cluster.

# Check cluster version (control plane + client)
kubectl version --short

# Check all node versions
kubectl get nodes -o wide

# Verify kubeadm version
kubeadm version

Backup Kubernetes Cluster

This is non-negotiable. Before touching any upgrade commands, create a verified backup of etcd — the key-value store that holds all cluster state. Without a good backup, a failed upgrade can result in permanent data loss.

etcd Backup:

# Backup etcd (run on control plane node)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key

# Verify the snapshot
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot-$(date +%Y%m%d).db

Cluster Resource Backup:

# Export all cluster resources to YAML
kubectl get all --all-namespaces -o yaml > /backup/cluster-resources-$(date +%Y%m%d).yaml

# Backup persistent volume claims
kubectl get pvc --all-namespaces -o yaml > /backup/pvcs-$(date +%Y%m%d).yaml

⚠️ Important: Store backups off-cluster — on S3, NFS, or another durable location. A backup stored only on the same node you are upgrading is not a real backup.

Verify Node Compatibility

Kubernetes has strict version skew policies. Violating them will cause unexpected behavior that is difficult to debug.

The kubelet version cannot be newer than the API server version
The kubelet can be at most two minor versions behind the control plane
kubectl should be within one minor version of the API server in either direction
Your container runtime (containerd, CRI-O) must support the CRI API version required by v1.36

# Check container runtime on each node
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'

Kubernetes Version Compatibility Matrix

The table below summarizes the supported version ranges for each component when upgrading to Kubernetes v1.36. Always refer to the official Kubernetes documentation for the definitive compatibility matrix before proceeding.

Component	Supported Version	Notes
kubeadm	v1.36.x	Required for upgrade
kubelet	v1.35 – v1.36	Must match ±1 minor version
kubectl	v1.35 – v1.36	Client can be one version ahead
API Server	v1.36.x	Always upgrade first
etcd	v3.5+	Verify compatibility
Container Runtime	containerd 1.7+	CRI-compatible required

📌 Version Skew Policy: The control plane must always be upgraded before worker node components. Kubernetes guarantees backward compatibility for one minor version — never upgrade worker nodes ahead of the control plane.

Step-by-Step Kubernetes v1.36 Upgrade Process

Follow these steps in order. Do not skip steps or run commands out of sequence. The process below assumes a kubeadm-managed cluster running on Ubuntu/Debian. Adjust package manager commands accordingly for RHEL/CentOS.

Step 1: Drain the Control Plane Node

Draining the control plane node gracefully evicts all workloads running on it, ensuring pods are safely rescheduled on worker nodes before the upgrade begins.

# Replace <control-plane-node> with your actual node name
kubectl drain <control-plane-node> \
  --ignore-daemonsets \
  --delete-emptydir-data

The --ignore-daemonsets flag skips DaemonSet-managed pods (like Calico or node-exporter) since these are intentionally cluster-wide. Confirm the node shows SchedulingDisabled after this command.

Step 2: Upgrade kubeadm

kubeadm orchestrates the upgrade of the control plane components. It must be upgraded first, before any other Kubernetes binaries.

# Update package repository
sudo apt-get update

# Find available kubeadm versions
apt-cache madison kubeadm | grep 1.36

# Install the target version (replace x with patch version)
sudo apt-get install -y kubeadm=1.36.x-00

# Verify kubeadm version
kubeadm version

For RHEL/CentOS/Amazon Linux, use: sudo yum install -y kubeadm-1.36.x

Step 3: Upgrade Kubernetes Control Plane

This is the most significant step. kubeadm will upgrade the API server, scheduler, controller-manager, and other control plane components. Always do a dry run first.

# Dry run first — check for warnings or errors
sudo kubeadm upgrade plan v1.36.x

# Apply the upgrade
sudo kubeadm upgrade apply v1.36.x

The upgrade plan command will list all components being upgraded, flag any deprecated API usage in your manifests, and confirm etcd version compatibility. Read this output carefully before running the apply command. The apply step typically takes 5 to 15 minutes — do not interrupt it.

Step 4: Upgrade kubelet and kubectl

After the control plane is upgraded, update the node agents and CLI tool on the control plane node.

# Install matching kubelet and kubectl versions
sudo apt-get install -y kubelet=1.36.x-00 kubectl=1.36.x-00

# Pin the versions to prevent accidental auto-upgrade
sudo apt-mark hold kubelet kubeadm kubectl

Step 5: Restart kubelet

After installing the new binaries, reload the systemd daemon and restart kubelet to apply the changes.

sudo systemctl daemon-reload
sudo systemctl restart kubelet

# Verify kubelet is running
sudo systemctl status kubelet

Step 6: Upgrade Worker Nodes

Repeat the following process for each worker node, one at a time. Never drain all nodes simultaneously — that would take down your entire workload.

# Step A: Drain the worker node (run from control plane)
kubectl drain <worker-node-name> --ignore-daemonsets --delete-emptydir-data

# Step B: SSH into the worker node
ssh user@<worker-node-ip>

# Step C: Upgrade kubeadm on the worker
sudo apt-get update
sudo apt-get install -y kubeadm=1.36.x-00

# Step D: Upgrade node configuration
sudo kubeadm upgrade node

# Step E: Upgrade kubelet and kubectl
sudo apt-get install -y kubelet=1.36.x-00 kubectl=1.36.x-00
sudo apt-mark hold kubelet kubeadm kubectl

# Step F: Restart kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Wait for each worker node to show Ready status before draining the next one. Monitor with kubectl get nodes -w.

Step 7: Uncordon Node

After the worker node is upgraded and kubelet is running, uncordon it to re-enable scheduling.

# Run this from the control plane for each worker node
kubectl uncordon <worker-node-name>

Verify Kubernetes Cluster After Upgrade

Never consider an upgrade complete until you have verified the cluster is healthy and your workloads are running normally. Run these checks immediately after upgrading all nodes.

# Confirm all nodes are running v1.36 and in Ready state
kubectl get nodes -o wide

# Check all system pods are running
kubectl get pods -n kube-system

# Check all pods across all namespaces
kubectl get pods -A

# Verify control plane component versions
kubectl version

# Check cluster health
kubectl cluster-info

All nodes should show v1.36.x in the VERSION column and a STATUS of Ready. All kube-system pods should be Running or Completed. If you see pods in CrashLoopBackOff or Pending state, refer to the troubleshooting section below.

Kubernetes Upgrade Best Practices

These practices are drawn from real production experience. Following them will significantly reduce the risk of a failed or disruptive upgrade.

Always upgrade control plane components before worker node components — this is enforced by Kubernetes version skew policy.
Upgrade one minor version at a time. Never skip minor versions (e.g., 1.34 → 1.36 is unsupported).
Always take a verified etcd backup immediately before starting. Test restoration in a non-production environment.
Upgrade worker nodes one at a time. Monitor workload stability before moving to the next node.
Run kubeadm upgrade plan before kubeadm upgrade apply. Read every line — it flags deprecated APIs that could break your applications.
Test the upgrade in a staging cluster that mirrors production before touching production.
Schedule upgrades during low-traffic windows even if you expect zero downtime.
Check your application manifests for deprecated API versions using tools like Pluto before upgrading.
Keep your CNI plugin upgrade plan ready — some CNI versions are tied to specific Kubernetes versions.
Monitor cluster metrics and application SLOs for at least 30 minutes after completing the upgrade before declaring success.

Common Kubernetes Upgrade Issues and Fixes

Even well-planned upgrades encounter problems. Here are the most common issues and how to resolve them.

kubelet Version Mismatch

Symptom: kubectl get nodes shows a node with an old version, or the node shows NotReady after the upgrade.

# Check kubelet version and status on the problem node
kubelet --version
sudo systemctl status kubelet
journalctl -u kubelet -n 50 --no-pager

# If kubelet failed to restart, check for config issues
sudo kubeadm upgrade node --dry-run

Most kubelet version mismatch issues come from forgetting to restart the kubelet after installing the new binary. Run sudo systemctl daemon-reload && sudo systemctl restart kubelet and check the status again.

Pods Stuck in Pending State

Symptom: After uncordoning a node, pods remain Pending and are not scheduled.

# Describe the stuck pod for scheduling events
kubectl describe pod <pod-name> -n <namespace>

# Check node conditions and taints
kubectl describe node <node-name>

# Look for unmet resource requests
kubectl get events --sort-by=.lastTimestamp -A | tail -30

Common causes include resource quota exhaustion after the node was drained, leftover taints on the node, or image pull failures on the upgraded node.

API Server Not Starting

Symptom: The control plane is unreachable after the upgrade, or the kube-apiserver pod is in CrashLoopBackOff.

# Check control plane pod logs directly via crictl
sudo crictl ps -a | grep apiserver
sudo crictl logs <container-id>

# Check kube-apiserver static pod manifest
cat /etc/kubernetes/manifests/kube-apiserver.yaml

# Check for certificate expiry
sudo kubeadm certs check-expiration

The most common cause of API server startup failure post-upgrade is a malformed static pod manifest or an expired certificate. If certificates have expired, run sudo kubeadm certs renew all and restart the kubelet.

How to Rollback Kubernetes Upgrade

Rolling back a Kubernetes upgrade is not as simple as running a single command — Kubernetes does not support automated downgrade. However, with a good etcd backup, recovery is straightforward.

Option 1: Restore from etcd Backup

# Stop the API server by moving the static pod manifest
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/

# Restore etcd snapshot
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot-<date>.db \
  --data-dir=/var/lib/etcd-restored

# Update etcd manifest to point to restored data dir, then restore the API server manifest
sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/

Option 2: Downgrade kubeadm / kubelet

# Remove version hold
sudo apt-mark unhold kubeadm kubelet kubectl

# Install the previous version
sudo apt-get install -y kubeadm=1.35.x-00 kubelet=1.35.x-00 kubectl=1.35.x-00

# Restart kubelet
sudo systemctl daemon-reload && sudo systemctl restart kubelet

Note that downgrading the kubelet without restoring etcd may leave your cluster in an inconsistent state. A full etcd restore is always the safest rollback path — which is exactly why that pre-upgrade backup is so critical.

Conclusion

Upgrading your Kubernetes cluster to v1.36 is a straightforward process when approached methodically. The key to a successful upgrade is preparation: verify your current version, back up etcd, check component compatibility, and test in staging before touching production.

Kubernetes v1.36 delivers meaningful improvements in dynamic resource allocation, security hardening, networking flexibility, and storage management. These changes make a compelling case for upgrading even if you are only one minor version behind.

The recommended upgrade strategy remains the same across all Kubernetes versions: upgrade the control plane first, verify it is healthy, then roll worker nodes one at a time while monitoring your workloads. With the steps in this guide, a well-prepared team can complete a full cluster upgrade with zero application downtime.

Frequently Asked Questions

Is Kubernetes v1.36 stable?

Yes. Kubernetes v1.36 is a general availability (GA) release. All features that graduated to GA in this version have gone through alpha and beta phases with extensive testing. It is production-ready, though thorough testing in a staging environment is strongly recommended before rolling it out to production clusters.

How long does a Kubernetes upgrade take?

For a single-master, three-worker-node cluster, the full upgrade typically takes 30 to 60 minutes including pre-flight checks, backups, and post-upgrade verification. Larger clusters with many worker nodes can take several hours, since each worker node must be drained, upgraded, and uncordoned sequentially. The control plane upgrade itself usually completes in under 15 minutes.

Can Kubernetes be upgraded without downtime?

Yes, in most production configurations. Because the upgrade process drains one node at a time and reschedules pods onto other healthy nodes, applications with multiple replicas and proper pod disruption budgets (PDBs) configured will experience no downtime. Single-replica deployments or stateful workloads without proper leader election may see brief interruptions during the node drain step.

What is the safest way to upgrade Kubernetes?

The safest approach is: take a verified etcd snapshot backup, run the upgrade in a staging environment that mirrors production, use kubeadm upgrade plan to check for deprecated APIs before applying, upgrade the control plane first and verify it is healthy, upgrade worker nodes one by one with monitoring between each, and keep the previous version’s kubeadm binary available for emergency downgrade.

About the Author

Kedar Salunkhe

DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee

I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy.