Three major versions crossed, one workload restarted on purpose
Kubernetes — version upgrade programme
Where they started
The cluster was five minor versions behind, which meant the supported upgrade path no longer existed in a single hop and several deprecated APIs were still in use.
The problem, precisely
A large share of manifests used removed APIs, and the team had no inventory of which workloads would break.
What we did
Ran a pre-upgrade scan to enumerate removed and deprecated API usage, converted manifests in Git before touching the cluster, then upgraded in three hops with a staging rehearsal for each.
Delivered
- Removed-API inventory across all manifests, with conversion applied in Git
- Add-on compatibility matrix checked against the target versions before starting
- Three staged upgrades, each rehearsed on staging with the same manifests
- Rollback plan per hop, exercised as a dry run rather than assumed
- Version policy written down: never more than two minors behind
Technologies used
Measured result
Every number below was measured and reported to the customer. Where we do not have a measured figure, the entry is a fact rather than a percentage — we would rather be precise than impressive.
- 3 major hops completed in planned windows
- 1 workload restarted deliberately, none unexpectedly
- 0 rollbacks required
- ≤ 2 minor versions behind, now a written policy
Convert manifests in Git before you touch the cluster. Almost every "the upgrade broke it" incident is a removed API that was sitting in a repository the whole time.