AWS EKS Version Rollback

Amazon EKS has introduced Kubernetes version rollback, but one detail is easy to miss:

You cannot always roll back the control plane first.
EKS now allows an upgraded cluster to return to its previous Kubernetes minor version within seven days.
For example:
1.33 → 1.32
But if Managed Node Groups were also upgraded to 1.33, they must be rolled back before the control plane.
Why?
Kubernetes does not support worker nodes running a newer version than the control plane.

The practical rollback order becomes:
-> Check EKS rollback readiness insights
-> Verify application and API compatibility
-> Downgrade incompatible add-ons
-> Roll back Managed Node Groups
-> Roll back the EKS control plane

EKS Auto Mode handles the worker-node rollback automatically. For Managed Node Groups, self-managed nodes and hybrid nodes, this remains our responsibility.

Another important distinction:
EKS rolls back:
-> Kubernetes API server
-> Control-plane components
-> Platform version

EKS does not automatically roll back:
-> Managed or self-managed worker nodes
-> EKS add-ons
-> Application deployments
-> Resources created using newer Kubernetes APIs
The cluster’s etcd data, workloads and persistent volumes are preserved. This means rollback changes the Kubernetes version, but it does not restore the entire cluster to an earlier point in time.

A useful upgrade strategy is therefore to keep worker nodes on N-1 during the initial control-plane bake period. If rollback becomes necessary, the data plane may not need to be downgraded first.

The feature provides a valuable recovery path, but only when the upgrade sequence is designed with rollback in mind.
Official announcement: https://lnkd.in/gusJKA9n

#AmazonEKS #Kubernetes #AWS #DevOps #SRE #CloudNative #PlatformEngineering #ReliabilityEngineering #DevOpsEngineer