RANCHER-1318: Investigate and define EKS upgrade plan
At the moment all our EKS clusters are running Kubernetes v1.23.
1.23 version was released three years ago in December 7, 2021.
On October 4, 2023, Amazon Elastic Kubernetes Service (Amazon EKS) announced the public preview of extended support for Kubernetes versions, which gives an additional 12 months of support for Kubernetes minor versions. Amazon EKS clusters running on a Kubernetes version in the extended support window will be charged a total of $0.60 per cluster per hour, effective from the April 2024 billing cycle (starting April 1, 2024). Pricing for clusters running Kubernetes versions in standard support is unchanged — you will continue to pay $0.10 per cluster per hour.
Kubernetes version | Upstream release | Amazon EKS release | End of standard support | End of extended support |
---|---|---|---|---|
| December 13, 2023 | January 23, 2024 | March 23, 2025 | March 23, 2026 |
| August 15, 2023 | September 26, 2023 | November 26, 2024 | November 26, 2025 |
| April 11, 2023 | May 24, 2023 | July 24, 2024 | July 24, 2025 |
| December 9, 2022 | April 11, 2023 | June 11, 2024 | June 11, 2025 |
| August 23, 2022 | February 22, 2023 | May 1, 2024 | May 1, 2025 |
| May 3, 2022 | November 15, 2022 | January 31, 2024 | January 31, 2025 |
| December 7, 2021 | August 11, 2022 | October 11, 2023 | October 11, 2024 |
| August 4, 2021 | April 4, 2022 | June 4, 2023 | September 1, 2024 |
| April 8, 2021 | July 19, 2021 | February 16, 2023 | July 15, 2024 |
To avoid unwanted cost expansion we should upgrade Kubernetes version of EKS clusters to at least v1.27
Because Amazon EKS runs a highly available control plane, we can update only one minor version at a time. Assume that our current cluster version is version 1.23
and we want to update it to version 1.25
. We must first update our version 1.23
cluster to version 1.24
and then update our version 1.24
cluster to version 1.25
.
The preffered way to upgrade Kubernetes version on EKS clusters is to run it in place. Such approach allows us avoid extra cluster creation (save costs) and populating it with significant amount of specific application configurations (save time).
Our Kubernetes Version Upgrade Plan is going to be iterative (due to EKS upgrade limitations) to give us one minor version update on each iteration.
Once we updated to a new minor version we need to run existing smoke tests to be on the safe side and make sure everything looks good after version rise.
Only after successful smoke tests run we can proceed to the next iteration to upgrade up to desired Kuvernetes Version (1.27).
We should be aware of that fact once EKS Cluster upgraded to the newer version we can’t roll back to the previous one.
So to upgrade EKS Cluster v1.23 to desired v1.27 we need exactly four iterations in a row.
Used Link References:
Amazon EKS extended support for Kubernetes versions pricing | Containers
Updating an Amazon EKS cluster Kubernetes version - Amazon EKS
Plan an upgrade strategy for your Amazon EKS cluster | AWS re:Post (repost.aws)
Blue/Green or Canary Amazon EKS clusters migration for stateless ArgoCD workloads | Containers
kubernetes/CHANGELOG/CHANGELOG-1.24.md at master · kubernetes/kubernetes (github.com)
Cluster Upgrades - EKS Best Practices Guides (aws.github.io)