Upgrade Kubernetes

What this gets you

Your entire cluster moved to a newer Kubernetes version, one node at a time, with a recovery point taken before anything changes.

Before you start

• This is a cluster-wide action, unlike node maintenance — it isn’t run per node.
• Know the target version you want (Kubernetes moves one minor version at a time — e.g. from a v1.31.x cluster you can go to v1.32.x, not straight to v1.33.x).

The steps

1. Open Cluster → Kubernetes and find the Upgrade section. It shows every node’s current Kubernetes version and the next version you’re eligible to move to.
2. Type the target version, e.g. v1.32.4+k3s1, and confirm.

Buddy takes a recovery snapshot first, then upgrades the master, then rolls the workers one at a time — cordoning, draining, upgrading, confirming each is healthy at the new version, and returning it to service before moving to the next. Live logs and per-node progress stream the whole way, and you can Abort.

The Kubernetes API and the panel briefly blip while the master is upgraded — your workers and their workloads keep running. The panel reconnects on its own; there’s nothing to do but wait.

How you know it worked

Every node’s Kubernetes version on the Cluster → Kubernetes screen matches the target you typed, and each shows healthy.

What can go wrong

• The upgrade is refused before it starts
• “An agent is ahead of the server.”
• The panel blipped when the server upgraded
• A node is stuck at the old version / the roll halted on a worker
• The drain is stuck mid-roll
• The server upgrade itself failed (recovering with the etcd snapshot)
• “A cluster upgrade is already in progress” / “a maintenance op is active.”

See these symptoms in Troubleshooting.