Skip to content

In-Place Upgrades to Amazon EKS v1.26 using Rafay

In our recent release in July, we added support for in-place upgrades of existing EKS clusters to Kubernetes v1.26. Customers tell us that they wish to be extremely careful with in-place upgrades of their existing EKS clusters because there is no benefit in rushing this and impacting mission critical applications etc. Provisioning of new EKS v1.26 clusters using Rafay has been supported for a while now.

Upgrade to EKS v1.26

Note

Organizations that wish to perform sophisticated checks for API deprecation etc are strongly recommended to use Rafay's Fleet Operations for Amazon EKS.

Upgraded EKS v1.26 Cluster

The EKS cluster in our example below is provisioned and managed by the Rafay Kubernetes Operations Platform. This was recently upgraded in-place to EKS v1.26. As you can see in the screenshot below, the AWS managed EKS control plane is reporting Kubernetes v1.26.

EKS v1.26 Cluster

Nodes

Let's click on a node to view additional details. As you can see in the screenshot below, kubelet on the node reports Kubernetes v1.26. So, this has been successfully upgraded as well.

EKS v1.26 Node

Upgrade History & Details

This EKS cluster was originally provisioned long back with Kubernetes v1.24 and was subsequently upgraded in place to v1.25 and then to v1.26. The upgrade history for the EKS cluster managed by Rafay displays the timestamp when the upgrade was initiated and how long the upgrade job took to complete.

EKS v1.26 Upgrade History

Administrators can click on each upgrade job to view additional details. The screenshot below displays detailed information on the various steps that were performed during the in-place upgrade to EKS v1.26. Note that the Rafay Platform automatically included a pre-flight check for the correct version the AWS CNI before it allowed the upgrade process to be initiated.

Important

In-place upgrades to EKS v1.26 requires users to upgrade the Amazon VPC CNI plugin to v1.12 or higher. Earlier versions of the Amazon VPC CNI plugin will result in a crash. The Rafay platform includes a pre-flight check for this AWS CNI version.

Upgrade Details

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.

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.