Considerations for In-Place Upgrades to Amazon EKS v1.24

Recently, AWS added support for Kubernetes v1.24 for their Amazon EKS offering. One significant change with this version is the removal of Dockershim as the Container Runtime (CRI). Amazon EKS clusters v1.24 onwards are standardized on containerd.

New Amazon EKS v1.24 clusters are provisioned with containerd. Watch a brief video showcasing how customers can use Rafay to configure and provision an Amazon EKS v1.24 cluster. When existing EKS clusters are upgraded to v1.24, the nodes in the EKS cluster’s data plane are seamlessly migrated from Dockershim to containerd.

graph LR
  A[Dockershim] --> B[Containerd];

Although this transition is mainly behind the scenes for users, the transition from Dockershim -> containerd can cause disruptions to deployed applications that may be dependent on Docker. In this blog, we will look at what Rafay has done to protect our customers during an in-place upgrade to EKS v1.24.

How does Rafay help?

For our customers that use the Rafay Kubernetes Operations Platform for lifecycle management of Amazon EKS clusters, the platform provides peace of mind and simplicity with upgrades of Amazon EKS clusters.

For in-place upgrades of Amazon EKS clusters to Kubernetes v1.24, users will experience a seamless and zero-impact upgrade. We have specifically implemented pre-flight logic that will block the upgrade from proceeding if it detects that there are existing applications dependent on Docker.

sequenceDiagram
  participant Admin
  participant Controller
  participant EKS Cluster
  participant App
  Admin->>Controller: Upgrade EKS Cluster to v1.24
  App->>EKS Cluster: App using Docker
  activate EKS Cluster
  Controller->>EKS Cluster: Pre-Flight Check Failure
  Controller->>Admin: Upgrade Blocked
  App->>EKS Cluster: App updated to use Containerd
  deactivate EKS Cluster
  Admin->>Controller: Upgrade EKS Cluster to v1.24
  Controller->>EKS Cluster: Pre-Flight Check Success
  Controller->>EKS Cluster: Cluster upgraded to v.124
  Controller->>Admin: Upgrade Successful

Shown below is a screenshot showcasing a failed pre-flight check for the in-place upgrade where it detected a deployed application using Docker. Once these applications are either removed or updated to use containerd, the pre-flight checks will pass and the upgrade process can continue.

Watch a video showcasing the in-place upgrade of an Amazon EKS cluster from Kubernetes v1.23 to v1.24. Notice the Container Runtime seamlessly transitions from Docker to containerd as part of the upgrade process.

Want to Learn More?

Learn more about how the Rafay Platform can help you with “Kubernetes Operations for Amazon EKS“