Upgrade Strategies
Users may have vastly different operational requirements for their business applications. As a result, a "one size fits all" strategy is not a good idea especially for workflows that can result in application and cluster downtime. Multiple upgrade strategies are possible for upgrades of Amazon EKS clusters and high level details are described below.
In-Place¶
This approach first upgrades the EKS managed control plane and then the worker nodes in each node groups until everything has been upgraded to the desired Kubernetes version. This approach is well suited for scenarios where it may be "impossible" or "impractical" to pursue a migration based upgrade strategy. Users need to understand that upgrades of EKS clusters are a 1-way road and cannot be undone. Review the other options described below for lower business and operational risk scenarios. The visual below describes the high level steps that need to be performed for an "in-place" upgrade strategy.
Important
Unlike actual in-place, software only upgrades, upgrades of Amazon EKS clusters require "cycling" of instances backing the control plane and worker nodes. As a result, administrators should plan for substantial time (~40 minutes) for upgrades to complete end-to-end.
Watch for a quick demo on In-Place Upgrade of Amazon EKS Clusters
Canary¶
This approach is well suited for scenarios where a lower blast radius is required and costs for additional infrastructure is not a major concern. With a canary upgrade strategy, the risk of compatibility and stability is removed by performing this validation out of band on the canary cluster with the new Kubernetes version. The visual below describes the high level steps that need to be performed for a "canary" upgrade strategy.
Blue-Green¶
This approach is well suited for scenarios where an extremely low blast radius is required. This upgrade strategy will essentially duplicate infrastructure costs and users need to factor this in at least for the time period the duplication infrastructure is operated. With a blue-green upgrade strategy, users have the advantage of running their applications for an extended time period (Blue/Green type) on two clusters, one with the "older" Kubernetes version and the replacement with the "newer" Kubernetes version. Administrators have the option to switch back and forth between the old and new clusters as required. The visual below describes the high level steps that need to be performed for a "blue-green" upgrade strategy.
