Amazon EKS — Cluster Upgrades
EKS releases a new Kubernetes version roughly every 4 months. Upgrading is a multi-step process: control plane first, then node groups, then add-ons. Planning prevents downtime.
Topics Covered
| # | Topic | Description |
|---|---|---|
| 1 | Upgrade Planning | Version lifecycle and pre-upgrade checks |
| 2 | Control Plane Upgrade | In-place API server upgrade |
| 3 | Node Group Upgrade | Rolling node updates |
| 4 | Add-on Upgrades | VPC CNI, CoreDNS, kube-proxy updates |
| 5 | Blue-Green Cluster Upgrade | Full cluster replacement strategy |
| 6 | Hands-On Lab | Plan and execute a cluster upgrade |
| 7 | Practice Questions | Test your upgrade knowledge |
EKS Upgrade Order
| Step | Component | Method | Downtime |
|---|---|---|---|
| 1 | Control plane | In-place (AWS manages) | No (rolling update) |
| 2 | Add-ons | Update via EKS API or Helm | No |
| 3 | Managed node groups | Rolling update (new AMI) | No (if PDBs configured) |
| 4 | Self-managed nodes | Replace launch template + ASG | Depends on strategy |
| 5 | Fargate pods | Delete and recreate pods | Brief (pod restart) |
Rule: Control plane must be upgraded before nodes. Nodes can be at most one minor version behind the control plane.
