Declarative configuration for Cluster Overrides

Cluster overrides

By default, K8s objects require certain values be set inside their specs that match the cluster's configuration. If this were to done within the add-on (or workload) manifest, it would require that many duplicate add-ons (or workloads) would need to be created for a fleet of clusters. To mitigate this, the platform supports cluster overrides. These allow the customer to use a single add-on (or workload) org wide and dynamically inject values into a manifest as it is being deployed to the cluster.

Examples include:

  • Use of a different license key for a security tool based on the business unit

  • Configuration of different resource requests for a monitoring tool based on environment type (test or prod)

  • Dynamic configuration of cluster name during deployment of a load balancer (e.g. AWS Load Balancer)

Bare Metal Replication And Virtualization Environment (BRAVE)

BRAVE (Bare Metal Replication And Virtualization Environment) offers a virtual, cost-efficient, convenient, automated and on-demand tool for executing use cases requiring bare metal infrastructure.

Cost and complexity of bare metal deployments can be prohibitive for a number of non production use cases such as :

  • Creating on-demand labs for conducting quick proof of concepts, demonstrations or experiments
  • Creating testbed environments for development, debugging and automated testing
  • Performing comprehensive architectural and security assessments through construction of proof of concept deployments.

In-place Upgrades to Amazon EKS v1.28 Clusters using Rafay

In our recent release, we added support for in-place upgrades of EKS clusters based on Kubernetes v1.28.

Our 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. As a result, we generally introduce support for new cluster provisioning for the new Kubernetes version first and then follow up with support for zero touch in-place upgrades.

Note

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

Infrastructure Templates for Generative AI on AWS

We constantly hear from our customers about wanting their developers to experiment with Generative AI. No organization wants to be left behind and they are all trying to find ways to empower their developers and application teams to be able to experiment with use cases powered especially by Generative AI.

According to recent Gartner research, >80% of enterprises will have used Generative AI APIs or Deployed Generative AI-Enabled Applications by 2026.

We have been listening to our customers and are happy to announce Rafay's Templates for AI & Generative AI. Platform teams can now provide their developers with a self service experience for Gen AI infrastructure enabling developers to experiment with new and innovative Generative AI use cases.

Gen AI Logo

Rightsizing exercises with Cost Explorer

As organizations increase their K8s footprint and onboard more applications, it becomes extremely critical to have an unified (cross account, cross cloud) view of resource utilization metrics across clusters. Without this, organizations will be running blind to their K8s cost structure and it will be impossible to operate their infrastructure in a cost effective manner.

A recent release introduced a new integrated capability within the platform referred to as "Cost Explorer". This capability provides organizations with necessary information to effectively undertake "cluster rightsizing" and "application rightsizing" exercises.

Upstream Kubernetes on RHEL 9 using Rafay

Our recent release update adds support for a number of new features and enhancements. This blog is focused on support for Upstream Kubernetes on nodes based on Red Hat Enterprise Linux (RHEL) v9.2 and Red Hat Enterprise Linux (RHEL) v9.1. Both new cluster provisioning and in-place upgrades of Kubernetes clusters are supported for lifecycle management.

RHEL 9.2

Upstream Kubernetes v1.27 and v1.28 on VMware vSphere

Our recent release update to our Preview environment adds support for a number of new features and enhancements. We will write about these in separate blogs. This blog is focused on support for lifecycle management of upstream Kubernetes v1.27 and v1.28 on VMware vSphere

Both new cluster provisioning and in-place upgrades of existing 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 Management Platform has been validated on this Kubernetes version. This will be promoted from Preview to Production in a few days and will be made available to all customers.

Kubernetes Release

IPv6 Only Amazon EKS Clusters using Rafay

As the demand for IP addresses continues to grow, the Internet is rapidly running out of available IPv4 addresses. This has led to the adoption of IPv6, which provides a much larger pool of IP addresses. By using IPv6, organizations can ensure that they have enough IP addresses for their containerized applications, without running into address exhaustion issues.

Our most recent release to our Preview environment adds support for the creation of IPv6 Only Amazon EKS Clusters. This update streamlines the process of establishing Amazon EKS clusters with IPv6 only configuration, making it easier for you to harness the advantages of IPv6 networking without dealing with complexities.

Implementing Chargeback/Showback for multi-tenant clusters

As organizations embrace multi-tenancy i.e. share clusters among applications/teams to reduce cluster sprawl and spend, it is imperative that granular resource utilization metrics are collected and aggregated from their clusters. Tracking and reporting costs on a per application/team basis (referred to as chargeback/showback) is essential for a number of reasons including:

  • Billing internal teams/applications (their cost center IDs) based on their consumption
  • Gaining visibility into the cost structure to determine inefficiencies and drive cost optimization exercises
  • Forecasting future spend

Rafay's integrated Cost Management solution makes it extremely simple for customers to standardize collection of metrics in a consistent manner across clusters (cloud, on-premise) and implement chargeback/showback models.