Blue and green node upgrades keep a known-good fleet until the new one is proven.

In place

Rolling replace

n1n2n3

n1'n2n3

The managed node group replaces nodes one by one (maxUnavailable). Simple, no extra cost, but a bad new node reduces the only capacity you have.

Blue and green

New group, then shift

blueblueblue

greengreengreen

Create a node group on the new version, cordon and drain the old one gradually, and delete it when verified. Fast rollback, temporary extra cost.

Drift (Karpenter)

Automatic replacement

AMIdriftnew

When the AMI or NodePool spec changes, Karpenter replaces nodes under disruption budgets. Pin AMI versions; a floating @latest alias rolls nodes unannounced.

PDBs decide the pace

A budget that forbids any disruption blocks drains and stalls every strategy. Review PDBs before each upgrade.

Stateful workloads

EBS-backed Pods are pinned to a zone. Upgrade nodes zone by zone, one node group per zone, and watch volume re-attachment.

Node upgrades: in place, blue and green, or drift

There are three common ways to roll nodes onto a new version. In-place updates replace nodes within an existing managed node group, controlled by maxUnavailable. It is simple and cheap, but if a new node is faulty you have fewer healthy nodes in the group that serves that workload, and rollback means doing another update.

Blue and green creates a new node group on the new version beside the old one, shifts workloads by cordoning and draining the old group (or by changing node selectors or taints), verifies, and deletes the old group. It costs extra capacity for a while but gives a fast rollback path: uncordon the old group. It is the preferred approach for critical workloads.

With Karpenter, node replacement is automatic through drift: when the resolved AMI or NodePool spec differs from the node's, Karpenter replaces it, subject to disruption budgets. This is convenient and also dangerous if the EC2NodeClass uses a floating latest alias in production, because a new AMI release can start rolling your nodes without a deliberate change. Pin AMI versions and promote them through environments.

Whatever the method, PodDisruptionBudgets and graceful termination decide whether the process is smooth. A budget that allows no disruptions will stall drains; a missing budget on a single-replica service means brief downtime.