Skip to content

Product Blog

Optimizing Amazon's VPC CNI for your EKS Clusters Made Easy with Rafay

Amazon Elastic Kubernetes Service (EKS) is a managed service that you can use to run Kubernetes on AWS without needing to install, operate, and maintain your own Kubernetes control plane or nodes. Kubernetes clusters require a Container Network Interface (CNI) that is responsible for cluster networking. One of the options available with EKS is the Amazon VPC CNI, which allows your Kubernetes Pods to utilize IP Addresses defined within your VPCs Subnets. While this provides more control and flexibility to businesses, it also comes with its own set of challenges.

While the benefits of managing and customizing the Amazon VPC CNI on EKS are significant, it’s important to note that the process can be challenging and time consuming, particularly if you lack experience with kubernetes or Amazon's VPC and its resources.

This is where Rafay’s EKS integration can come in handy. In this blog, we'll explore how Rafay’s Platform can address pain points and simplify the management process.

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

Note

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