Keep clusters inside their support window
Kubernetes releases frequently and each cloud service has its own support window. Falling behind forces risky multi-version jumps and, on some services, extra support charges. We turn upgrades into a routine.
Signs this is your moment
- A cluster is on a version close to or past its support end date
- Nobody owns the upgrade calendar, so upgrades happen when something breaks
- Deprecated APIs are still used in manifests and Helm charts
- Add-ons such as ingress, CNI and autoscalers are several versions behind
- A previous upgrade caused an incident and the team is nervous
How we approach it
-
Version audit
Record each cluster version, node group, add-on and the support end date for its cloud service.
-
Deprecation scan
Check manifests, charts and controllers for removed or deprecated APIs before touching a cluster.
-
Test environment first
Upgrade a representative non-production cluster and run the same checks you use in production.
-
Staged production upgrade
Control plane first, then add-ons and nodes in a safe order, with a rollback or replace plan.
-
Make it routine
Hand over a runbook and a calendar so the next upgrade is a scheduled task.
What you receive
- A cluster and add-on version register with support dates
- A deprecation report and fixes for your manifests and charts
- A tested upgrade runbook for each cloud service you use
- An upgrade calendar your team can own
Start with a defined piece of work: Kubernetes and EKS Production Readiness Review. Scope and timeline are agreed in writing before anything starts.
Always confirm support dates on your cloud provider's own documentation, because they change.
Common questions
How often should we upgrade?
Can you upgrade without downtime?
Do you cover AKS and GKE as well as EKS?
Talk it through with an engineer
A free 30-minute working session that ends with a short written roadmap.
Book a working session