Skip to content

Amazon EKS

Intelligent Cluster Autoscaling with Karpenter

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.

AWS Karpenter

Streamlining AMI Updates for Worker Nodes in Amazon EKS Clusters

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
    end

AWS Cross Account Support for EKS LCM in Rafay

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.

Cross Account Support

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

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

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