Skip to content


Upgrade Strategies for Your Rafay MKS Cluster

In the past, there was only one way to upgrade your Rafay provisioned upstream Kubernetes cluster. The worker nodes were upgrade sequentially one worker node at a time. For large clusters with 100s of worker nodes, upgrades can take a very long time. In this blog, we will describe optimizations we have incorporated in our August 2023 release to allow users to configure faster upgrades. We now offer two ways to upgrade, and you have the freedom to choose the one that suits you best.

Upgrade strategies

CIS Benchmark for Kubernetes using Rafay

The Center for Internet Security (CIS) benchmark for Kubernetes consists of secure configuration guidelines especially for Kubernetes infrastructure set-up. These benchmarks encapsulate best practice security recommendations for configuring Kubernetes to support a strong security posture. The CIS Kubernetes Benchmark is written for the open source, upstream Kubernetes distribution and intended to be as universally applicable across distributions as possible.

In this blog, we describe how our customers perform CIS benchmark scans of their fleet of Kubernetes clusters using Rafay.

HashiCorp's New License

Last week, HashiCorp announced that they would be adopting the Business Source License for future releases of its products. In this blog, we describe how and if this impacts Rafay customers.

There is no impact to our mutual customers and users due to this recent license change by HashiCorp.

Many of our customers benefit from our native support of HashiCorp product offerings, such as Terraform and Vault, and our strong partnership ensures that they will continue to do so. In this blog, I'll describe these integrations, and provide more detail on the recent licensing change.

Integrated Grep Plugin for the Kubectl Web Shell

In our recent release, we added support for plugins in the web based kubectl shell that users have access to after they authenticate to their Rafay Org. In this blog, we will describe how we have enhanced the developer experience for users of this feature by providing them with a "grep plugin".

Rafay's zero trust kubectl web shell is one of the most heavily used features by users of the Rafay platform because it provides secure kubectl access to authenticated users from any device from anywhere. They just need a web browser to login and perform kubectl operations on their cluster.

Grep Plugin for Kubectl

Amazon EKS v1.27 Clusters using Rafay

In our recent release, we added support for new EKS cluster provisioning based on Kubernetes v1.27.

Kubernetes v1.27

Customers have shared with us that they would like to provision new EKS clusters using 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.

Vector Databases for Generative AI on Kubernetes

Many of our customers use Kubernetes extensively for AI/ML use cases. This is one of the reasons why we have turnkey support for Nvidia GPUs on EKS, AKS, Upstream Kubernetes in on-prem data centers. Recently, we have had several customers look at adding support for Generative AI to their applications. Doing so will require looking at a slightly different technology stack.

Traditional relational databases are adept at handling structured data. They do this by storing data in tables. However, AI use cases are focused on handling unstructured data (e.g. images, audio, and text). Data like this is not well suited for storage and retrieval in a tabular format. This critical technology gap with relational databases has opened the door for a new type of database called a Vector Database that can natively store and process vector embeddings. The rapid rise of large-scale generative AI models has further propelled the demand for vector databases.

In this blog, we will review why vector databases are well suited and critical for AI and Generative AI. We will then look at how you can deploy and operate vector databases on Kubernetes using the Rafay Kubernetes Operations Platform in just one step.

Least Privilege Developer Access for Kubernetes Clusters

In our recent release in July, we enhanced our zero trust kubectl service to address the needs to two completely different cohorts of customers. At a high level, users of the Rafay Platform fall into two ends of the access spectrum when it comes to answering the following question.

Should developers be allowed to view Kubernetes Secrets?. Should they be allowed to exec into running containers/pods for troubleshooting purposes?

Opposite Ends of the Spectrum

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


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

Declarative Cluster Lifecycle Management

Every Kubernetes user is familiar with the kubectl apply command. This is used to create or modify Kubernetes resources as defined in a manifest file.

This pattern is referred to as Declarative usage where the state of the resource is "declared" in the manifest file and the command is used to implement the declared state. Unlike an imperative approach where the user needs to specify both what and how to perform a task, with the declarative approach, the user just needs to specify what to do and not worry about how to do it.

The apply approach is preferred and recommended because it is well suited for version control. The kubectl apply command works extremely well for resources inside the Kubernetes cluster.

What if there was a way to bring this declarative approach for cluster lifecycle management as well?