Kubernetes upgrades get planned like moon landings. Teams read release notes line by line, rehearse on staging, pick a maintenance window and agree who presses which button. Then the control plane comes back on the new version, nodes roll over, everyone types “looks good” in the channel and goes to lunch. The trouble usually starts a few days later, when a rarely used CronJob runs for the first time on the new version, or a Helm release that nobody touched during the window gets redeployed. Kubernetes upgrade aftercare is the work of planning those days in advance instead of discovering them. Here are ten things to line up before you upgrade, so the period afterwards is boring in the best possible way.
1. Name a watch owner for the days after the upgrade
The person who runs the upgrade is often not the person who will notice problems later. Pick one engineer to own the post-upgrade period for a fixed stretch, typically through at least one full business week and one weekend. Their job is not to stare at screens. It is to be the obvious person to ask when something odd happens, to coordinate fixes and to decide when the watch period can close.
Put their name in the upgrade plan itself, alongside the person executing the change. If the owner is going on holiday mid-week, choose someone else now rather than improvising a handover later.
2. Decide what “rollback” really means for you
Control plane downgrades are often unsupported or risky, so “we’ll just roll back” is not a real plan. Be precise about what reversal looks like: restoring from a snapshot of cluster state, failing over to a second cluster, pinning node pools to the old version while you investigate, or rolling forward with a fix. Our explainer on what a cluster upgrade involves and how teams approach it walks through why these options differ.
Whatever you choose, test it before the upgrade, not after something breaks. Knowing your reversal route lowers the stress of the whole after-period.
3. List the workloads that will not be exercised during the window
During the maintenance window, your busiest services get tested immediately because traffic hits them. Quiet workloads do not. Make a list of things that run rarely or only on certain triggers:
- CronJobs that run weekly or monthly.
- Batch jobs started by business events, such as month-end reports.
- Operators and controllers that act only when resources change.
- Admission webhooks for resource types that are seldom created.
- Disaster-recovery tooling that only runs during drills.
For each, note when it next runs and who will check it. Some teams trigger a manual run of each quiet workload in the days after the upgrade to flush out surprises on their own terms.
4. Re-check deprecated and removed APIs after the fact
You probably scanned manifests for deprecated APIs before upgrading. Do it again afterwards. Charts, templates and pipelines that were not deployed during the window can still carry old API versions, and they will fail the next time someone ships them. Schedule a sweep of repositories and chart values a few days in, and fix anything that slipped through.
If your platform relies heavily on packaged releases, it is worth reviewing how your Helm chart templates and values are versioned, so future sweeps are quicker.
5. Book a follow-up review before the upgrade starts
Put a short review meeting in the calendar for the end of the watch period, and send the invitation the same day you schedule the upgrade itself. Agenda: what broke or nearly broke, what the quiet-workload checks found, whether any API stragglers remain, what to change in the runbook and whether the watch can formally close.
Reviews that are arranged only “if something goes wrong” tend to be skipped when nothing dramatic happens, and that is exactly when small lessons get lost.
6. Tell application teams what to look out for
Platform teams sometimes treat upgrades as an internal affair. Application teams then encounter unexpected behaviour and do not connect it to the upgrade. Send a brief note before and after: what changed, what symptoms might relate to the new version, where to report issues and who the watch owner is. A clear reporting route turns vague complaints into actionable tickets.
7. Watch autoscaling and capacity behaviour
New versions can subtly change scheduling, resource accounting or how add-ons behave. Over the following days, keep an eye on whether nodes scale up and down as expected, whether pods schedule where they should and whether resource requests still fit comfortably. If you run automated node scaling, our guide to how the cluster autoscaler decides when to add or remove nodes is a handy refresher for what normal should look like.
The point is not to add new monitoring for the occasion. It is to make sure someone actually looks at capacity behaviour during the watch period rather than assuming it is fine.
8. Update the runbook while the details are fresh
Every upgrade teaches you something: an add-on that needed a manual step, a node pool that drained slowly, a permission that had to be adjusted. Capture these in the upgrade runbook during the watch period, not months later when the next upgrade is due and nobody remembers. Assign this explicitly to the watch owner or the executing engineer, with a deadline before the follow-up review.
9. Put the next upgrade on the calendar
Kubernetes versions move on a regular cycle, and support windows close. The best moment to schedule the next upgrade is right after finishing this one, while the effort and lessons are fresh. Add a tentative date to the team roadmap and link it to the updated runbook. This turns upgrades into routine maintenance rather than dreaded projects.
10. Plan rest for the people who ran the window
Upgrades often happen early in the morning, late at night or at weekends to minimise disruption. The engineers who carried out the change then roll straight into a normal working day, tired and still mentally attached to the upgrade. Tired people make sloppy follow-up decisions. Decide beforehand who gets a late start or a lighter day afterwards, and make sure the watch owner is not the same exhausted person who executed the change at dawn.
This is also a good moment to think about knowledge spread. If the same two engineers always run upgrades, the rest of the team never learns the process. Pair a less experienced colleague with the executor, and let that colleague own part of the watch period. Next time, they can lead. Over a few cycles, upgrade knowledge stops living in one or two heads and becomes a genuine team capability, which is the most durable form of aftercare there is.
Borrowing a habit from elsewhere
Other fields have long treated the after-period as part of the plan. In medical travel, for example, a planner such as SurgeryPlanet, which organises treatment abroad, folds the stay near the hospital, the ride from the airport and post-treatment support into the itinerary rather than leaving the patient to sort them out alone. Platform teams can apply the same thinking to cluster upgrades: the window is the headline, but the days that follow decide whether it went well.
A compact pre-upgrade checklist
Before your next maintenance window, confirm you have:
- A named watch owner and a defined watch period.
- A tested, specific reversal route.
- A list of quiet workloads with owners and check dates.
- A scheduled post-upgrade API sweep.
- A follow-up review already in calendars.
- A note ready for application teams.
- Someone assigned to look at capacity behaviour.
- An owner and deadline for runbook updates.
- A provisional date for the next upgrade.
- Rest arranged for whoever executes the change.
None of these items is difficult. Together they shift attention from the hour of the upgrade to the fortnight after it, which is where most upgrade pain actually lives. Plan that fortnight properly and your cluster upgrades become the kind of change nobody remembers, which is exactly what you want.