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".