Skip to content

Provision New AKS v1.27 Clusters using Rafay

Azure recently added support for Kubernetes v1.27 for AKS clusters. Customers can now use Rafay to provision new AKS clusters based on Kubernetes v1.27 as well.

This version of AKS was Generally Available (GA) starting July 2023 and go end of life in July 2024 i.e. with a 12 month support runway.

Kubernetes v1.27

Note

Customers have shared with us that they would like to provision new AKS clusters based on new Kubernetes versions so that they do not have to plan/schedule for Kubernetes upgrades for these clusters right away. For the last few releases, we have introduced support for new cluster provisioning for the new Kubernetes version first and then follow up with support for zero touch in-place upgrades.

New Cluster Provisioning

Users of the Rafay platform can provision new Azure AKS v1.27 clusters using ALL the supported interfaces. Shown below is a screenshot of a newly provisioned Azure AKS v1.27 using Rafay.

New AKS Cluster v1.27

Once a new aKS v1.27 cluster is provisioned, administrators can click on the node explorer to check the kubelet version. In the example shown below, notice that the kubelet version shows that the attached node is based on Kubernetes v1.27.

AKS v1.27 based Worker Node

When the admin uses the zero trust kubectl web shell to check the version, they should see something similar to the example below.

kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3

Important

In-place upgrades requires extensive validation for ALL supported interfaces in the platform. We will also add support for new preflight checks etc. It is strongly recommended that users be extremely careful and plan/test in-place upgrades for these. There is no benefit in rushing upgrades and impact mission critical applications etc.


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 AKS 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 AKS 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 aKS 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 AKS using Rafay.

5. APIs

This automation option is used primarily by our ISV type customers that use Rafay to deploy and operate AKS clusters in end customer Azure 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 Azure AKS using Rafay includes a number of hands-on exercises that will help you get familiar with capabilities of Rafay's Kubernetes Operations Platform. Sincere thanks to readers of our blog who spend time reading our product blogs. Please Contact the Rafay Product Team if you would like us to write about other topics.