What is the difference between EKS upgrades and OpenShift upgrades?
Quick Answer
EKS typically uses a blue-green node group strategy — you create new node groups with the target version, migrate workloads, and terminate old nodes. OpenShift does in-place upgrades managed by the Machine Config Operator, which reboots existing nodes with the new OS and config. EKS gives more control, OpenShift is more automated.
Detailed Answer
Think of it like two different approaches to upgrading a fleet of delivery trucks. The EKS approach is like buying new trucks (new node group), gradually transferring packages and drivers to the new trucks, and then selling the old ones. The OpenShift approach is like driving each truck to the shop one at a time, upgrading the engine and transmission while the rest of the fleet keeps delivering, then putting it back on the road.
With EKS, the control plane upgrade is managed by AWS — you click 'upgrade' or run aws eks update-cluster-version, and AWS handles upgrading the API server, etcd, and other control plane components behind the scenes (it's a managed service, so you don't touch the masters). For worker nodes, the standard practice is to create a new managed node group running the target Kubernetes version, cordon/drain the old node group, let workloads reschedule onto new nodes, then delete the old node group. Some teams use Karpenter, which handles this more dynamically by replacing nodes as they're drained.
With OpenShift, everything is in-place. The Cluster Version Operator orchestrates the entire upgrade: Cluster Operators update first, then the Machine Config Operator updates master nodes one by one (cordon → drain → reboot with new RHCOS version → uncordon), then worker nodes through MachineConfigPools. The nodes themselves are upgraded — same machines, new OS and packages. You don't create new infrastructure.
Key differences in practice: EKS upgrades are more forgiving — if something goes wrong with the new node group, the old one is still running, so you can roll back by rerouting traffic. OpenShift upgrades are harder to roll back because nodes are modified in-place (though OpenShift does support limited rollback). EKS requires you to manage the node upgrade strategy yourself (or use tools like eksctl, Karpenter, or Terraform), while OpenShift's MCO handles node lifecycle automatically.
EKS typically has less downtime risk because old and new nodes coexist during migration. OpenShift has a tighter upgrade window because each node goes offline briefly for reboot. However, OpenShift's approach is simpler operationally — you run one command and the platform handles everything. EKS gives more flexibility but requires more orchestration effort.
A gotcha specific to EKS: you must upgrade add-ons (VPC CNI, CoreDNS, kube-proxy) separately from the control plane, and version compatibility matrices matter. OpenShift bundles everything together, reducing the chance of version mismatches.