In a short few weeks, on 11th Oct, 2023, Kubernetes clusters based on Amazon EKS v1.23 will reach end of support. In this blog, we describe Rafay's reference implementation of a fleet upgrade plan that will help users perform in-place upgrades of their EKS v1.23 clusters to EKS v1.24 with zero risk to application downtime.
In July 2023, Rafay introduced a new feature to its Kubernetes Operations Platform: Cross Account Role ARN support for Amazon Elastic Kubernetes Service (EKS). This feature is designed to cater organizations that operate multiple AWS accounts, providing a seamless and efficient way to manage EKS clusters across these accounts. In this blog post, we'll delve into the significance of this enhancement, explore its use cases, and understand how it simplifies EKS cluster management across multiple AWS accounts.
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 EKS clusters are upgraded to v1.24, the nodes in the EKS cluster's data plane are seamlessly migrated from "Dockershim" to "containerd".
A[Dockershim] --> B[Containerd];
Although this transition is mostly "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.
Earlier this year, AWS added support for Kubernetes v1.23 for their Amazon EKS offering. One significant change with this version is with the Container Storage Interface (CSI) for working with AWS Elastic Block Store (Amazon EBS) volumes.
Specifically, the updates to the CSI driver require customers to take action to ensure a seamless upgrade process for EKS clusters from previous versions. The CSI was developed in Kubernetes to replace the in-tree driver. With the CSI, there is now a simplified plug-in model that makes it easier for storage providers to decouple their releases from the Kubernetes release cycle.
A[In-Tree Storage Driver] --> B[CSI Plugin for EBS CSI];
In a nutshell, this transition is good for Amazon EKS users because they do not have to upgrade Kubernetes versions for their EKS clusters just to get some additional functionality or bug fixes for EBS storage via the "in-tree driver".