In the introductory blog on Auto Mode for Amazon EKS, we described the basics of this new capability that was announced at AWS re:Invent 2024. In this blog, we will review considerations that organizations need to factor in before using EKS in Auto Mode.
Note
Please consider this as a living/evolving document. EKS Auto Mode is relatively new and we update this blog with new learnings/findings.
The Rafay team just got back late last week from an incredibly busy AWS re:Invent 2024. Congratulations to the EKS Product team led by our friend, Nate Taber for the launch of Auto Mode for EKS.
Since this announcement last week, we have had several customers reach out and ask us for our thoughts on this newly launched EKS Auto Mode service. There are several blogs that already describe "How Auto Mode for EKS works etc". In this blog series, I will attempt to provide perspective on "Why", "Why Now?" and "What this means for the industry".
When it comes to running workloads on Amazon Web Services (AWS), two popular choices are Amazon Elastic Compute Cloud (EC2) and AWS Fargate. Both have their merits, but understanding their cost implications is crucial for making an informed decision.
In this blog, we'll dive into a cost comparison of EC2 and Fargate configurations within an Amazon Elastic Kubernetes Service (EKS) cluster.
We frequently get asked by users that are currently on AWS whether they should be using Amazon ECS or EKS to deploy and operate their containerized applications. Since this is such a common question and the answers are somewhat nuanced, we wanted to share our thoughts and recommendations for the benefit of all users.
Congratulations to the maintainers of the Karpenter project!
The Karpenter project graduated to beta on 1st Nov, 2023. This is a major milestone for the Karpenter project.
We were very early adopters of Karpenter and have collaborated extensively with our customers and AWS to ensure that Karpenter works seamlessly for their EKS clusters when used with the Rafay Kubernetes Management platform. In this blog, we will describe the benefits of Karpenter and how our customers use Karpenter with Rafay.
Imagine this scenario: your clusters, the backbone of your infrastructure, are currently running worker nodes based on an older AMI version. An alarming email from the security team informs you that the AMI ID being used has serious security vulnerabilities. The urgency to address issues like this becomes paramount because these pose a direct threat to the integrity and security of your infrastructure.
Critical security issues like this call for the ability for quick action. How can nodes across all clusters be updated quickly?
Scenarios like this are exactly why we have invested heavily in developing the Fleet Plans functionality. This can help you identify and update all of the impacted worker nodes in various clusters smoothly in this situation.
sequenceDiagram
autonumber
participant admin as Admin
participant rafay as Rafay
rect rgb(191, 223, 255)
Note over admin,rafay: Upgrades of Insecure AMIs
admin->>rafay: Identify Impacted EKS Clusters <br> (Input = AMI ID)
admin->>rafay: Create Fleet Plan <br> (Impacted Clusters)
admin->>rafay: Execute Fleet Plan
admin->>rafay: Verify all EKS clusters <br>in fleet are using new AMI
endIn 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.
Our recent release update in July to our Preview environment adds support for a number of new features and enhancements. This blog is focused on Cross Account Role ARN Support for Amazon EKS.
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".
graph LR
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.
graph LR
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".