Amazon EKS v1.25 using Rafay¶

Our recent release update in May to our Preview environment adds support for a number of new features and enhancements. We will write about the other new features in separate blogs. This blog is focused on our turnkey support for Amazon EKS v1.25.

Both new cluster provisioning and in-place upgrades of existing EKS clusters are supported. As with most Kubernetes releases, this version also deprecates and removes a number of features. To ensure there is zero impact to our customers, we have made sure that every feature in the Rafay Kubernetes Operations Platform has been validated on this Kubernetes version.

This release will be promoted from Preview to Production in a few days and will be made available to all customers.

Note that no action is needed on the part of our SaaS customers with the new release. Once the rollout is completed, all they need to do is learn about the new features and determine how and when they would like to use them.

New Cluster Provisioning¶

Users of the Rafay platform can provision new Amazon EKS clusters based on Kubernetes v1.25 using ALL the supported interfaces. Shown below is a screenshot of an Amazon EKS v1.25 cluster in Rafay.

New EKS Cluster v1.25

In-Place Upgrades¶

Users of the Rafay platform with existing Amazon EKS clusters under management will be prompted to upgrade their clusters to Kubernetes v1.25. Users have fine grained control over how they want to upgrade. For example,

They can upgrade both the EKS control plane and all node groups in one fell swoop
They can upgrade just the EKS control plane first and then upgrade one node group at a time etc.

In-Place Upgrade Prompt

All upgrade operations are centrally audited and a detailed history of the steps followed for an upgrade is available for admins. We find that this history is critical for new admins that takeover responsibilities for a cluster from another person. An illustrative example is shown below.

In-Place Upgrades of EKS

Preflight Checks¶

To ensure there is zero impact to the workloads deployed on their EKS clusters due to a Kubernetes upgrade, the Rafay platform will automatically perform "preflight checks" and determine if the EKS cluster is a suitable candidate for an in-place upgrade. Outside generic checks that apply for evert Kubernetes version, there are preflight checks specific and unique to the target Kubernetes version. For example, for upgrades to Kuberbetes v1.25, admins need to worry about the following items that are unique to this Kubernetes version.

PSPs: Are there existing Pod Security Policies (PSPs)? PSPs were removed in Kubernetes v1.25

AWS Load Balancer: If you are using the AWS Load Balancer Controller with the enable-endpoint-slices flag, you will have to upgrade it to v2.4.7 before you upgrade to Kubernetes 1.25. Failure to upgrade the AWS Load Balancer controller to v2.4.7 before upgrading to EKS 1.25 will cause a disruption to your workloads.

The Rafay platform checks for these as part of the "preflight checks". See an illustrative screenshot below.

Preflight Checks for EKS v1.25

Alternate Upgrade Strategies¶

In addition to in-place upgrades, we find our customers employing alternate upgrade strategies for mission critical (read production) and complex (100s of applications) clusters. There are scenarios where it may be impractical for the Ops/SRE team to employ an in-place upgrade strategy. We see them using approaches such as:

Canary Upgrade Strategies
Blue/Green Upgrade Strategies

Read a step-by-step getting started guide for blue/green upgrades for EKS

Interfaces for Automation¶

Different organizations have different standards and preferences for how they would like to automate. With Rafay, we see users employing the following approaches for provisioning, scaling and upgrades.

1. Web Console¶

In many ways, the easiest approach for organizations with small teams and cannot afford to invest resources or time on IaC etc. They login into the Rafay web console, click on upgrade and wait for the operation to complete. The Rafay platform implements all the necessary automation and provides them with a simple abstraction on top.

2. RCTL CLI¶

This approach is commonly used by organizations that have existing investments in external automation pipelines based on platforms such as Jenkins, GitHub Actions etc. They prefer to maintain declarative cluster specifications for their Rafay managed EKS clusters in a Git repo. They update these specs in the Git repo and have their pipelines interact with the Rafay Controller to perform provisioning, upgrades, scaling etc. This approach is frequently referred to as "Push based Infra GitOps".

If you are interested, read through our step-by-step Getting Started Guide for Lifecycle Mgmt of EKS using Rafay's RCTL CLI. Ensure you select the "CLI" tab for CLI specific instructions.

3. Rafay Terraform Provider¶

Frequently used by larger organizations that have the staffing and resources in place to invest in the development and maintenance of Infrastructure as Code (IaC). These organizations typically have already standardized on HashiCorp's Terraform and use Rafay's Terraform Provider to use all the capabilities of the Rafay Kubernetes Operations Platform.

If you are interested, read through our step-by-step Getting Started Guide for Lifecycle Mgmt of EKS using Rafay's Terraform Provider. Ensure you select the "Terraform" tab for specific instructions.

4. GitOps with Write Back to Git¶

This the fastest growing IaC based lifecycle management approach preferred by our large customers, especially the ones with larger fleets (>10) of Kubernetes clusters. They specifically like the following capabilities:

Auto generation of cluster specs with write back to Git
Drift Detection and Reconciliation
ClickOps to GitOps i.e. automatically generate IaC specs and write this to the Git repo

If you are interested, read through our step-by-step Getting Started Guide for ClickOps to GitOps for EKS using Rafay.

5. APIs¶

This automation option is used primarily by our ISV type customers that use Rafay to deploy and operate EKS clusters in end customer AWS accounts. With these APIs, they are able to interact directly with the Rafay Platform programmatically from their application.

Brownfield EKS Clusters?¶

One question we get asked frequently by new customers and teams is

What do we do about our existing, brownfield EKS clusters? How can Rafay help us with managing Kubernetes upgrades and lifecycle management?

These are EKS clusters that already existed before they started using the Rafay platform. Rafay provides the means for customers to Import and Takeover Lifecycle Management of brownfield EKS clusters. Once the Rafay platform takes over lifecycle management of an EKS cluster, it is absolutely no different from an EKS cluster provisioned by Rafay.

If you are interested, read through our step-by-step Getting Started Guide for Takeover of Brownfield EKS Clusters using Rafay.

Try It Out¶

Sign up here for a free trial and try it out yourself. Get Started with EKS using Rafay includes a number of hands-on exercises that will help you get familiar with capabilities of Rafay's Kubernetes Operations Platform.