Kubernetes

Kubernetes cluster upgrades

Kubernetes releases three versions a year and managed providers drop old ones on a schedule. Skipping upgrades means one day you are forced across several versions at once with removed APIs breaking workloads.

We run upgrades as routine maintenance: check manifests for deprecated APIs, upgrade add-ons first, rotate nodes with pod disruption budgets respected and verify workloads after each step.

At a glance

Toolspluto, kubent for deprecation scans; provider CLIs; Cluster API
CadenceOne minor version per quarter keeps you inside support
RisksRemoved APIs, CNI/CSI compatibility, PDB deadlocks, kubelet memory leaks on old nodes
RollbackControl plane rarely; workloads via GitOps revert

What RackLedge does

How we work

Every cluster we build starts from Git. Infrastructure as code creates the cluster, Flux or Argo CD reconciles everything inside it, and no change reaches production without a pull request. That is what makes a rebuild after a bad day a matter of hours instead of weeks.

Operations are the product: monitoring with alerts that mean something, backups of cluster state and persistent volumes, upgrades on a quarterly cadence and an on-call engineer who already knows the environment. We run production Kubernetes for our own platforms, so the runbooks are ones we use ourselves.

We are honest about fit. A handful of stable services on a couple of VMs does not need Kubernetes, and we will say so. Teams that ship weekly, need to scale or run many services get real value from it.

Related services

More on kubernetes

Frequently asked questions

Why did my upgrade hang draining a node?

A PodDisruptionBudget that cannot be satisfied, often a single-replica deployment with minAvailable set. We find and fix those before starting.

Need a hand with this?

Tell us what you are running and what is slowing you down. You get a straight assessment and a plan, with no obligation. Support desk is staffed 24/7.

Get in touch