# Jan ## v3.1-SaaS **30 Jan, 2025** The section below provides a brief description of the new functionality and enhancements in this release. Important The release version has been updated to v3.x, introducing support for the GPU PaaS offering to enable GPU Cloud providers and enterprise customers to deliver self-service GPU capabilities to their end users. Additionally, the platform now includes a catalog of pre-built system templates. --- ### Upstream Kubernetes for Bare Metal and VMs The features in this section are for Rafay's Kubernetes Distribution (aka Rafay MKS). #### Kubernetes v1.32 New Rafay MKS clusters based on upstream Kubernetes can now be provisioned based on Kubernetes v1.32. Existing clusters managed by the controller can be upgraded "in-place" to Kubernetes v1.32. **New Cluster** **In-Place Upgrade** #### CNCF Conformance Upstream Kubernetes clusters based on Kubernetes v1.32 (and prior Kubernetes versions) will be fully [CNCF conformant](https://github.com/cncf/k8s-conformance/pull/3548). > To learn more about this, please read our recent blog: [Kubernetes v1.32](https://docs.rafay.co/blog/2025/01/07/kubernetes-v132-for-rafay-mks/) Important For **RHEL ⅞-based cluster nodes**, ensure machines using **cgroup v1** have a **kernel version ≥ 4.19**. This requirement applies **only when creating new clusters** with **RHEL nodes** on **Kubernetes v1.32**. #### Node Page UI Enhancements In this release, we have added several enhancements to the **MKS Node Page** for improved cluster visibility and management: - **Node Summary Count:** Displays the total count of **healthy** and **unhealthy** nodes, providing a quick overview of the cluster's health - **Enhanced Filter Options:** All state filters have been consolidated into a single filter dropdown, with an additional filter for **Scheduled Disabled** nodes to easily identify nodes in this state - The label **`Status`** on the node card has been updated to **`Provision Status`** to better reflect the node's provisioning state - The health indicator has been updated to **`Node Health`** to clearly represent the overall health of the node These improvements offer a more intuitive and efficient way to monitor and manage node states within the cluster. --- #### Backup & Restore In this release, we are adding a new version of the data agent, `v1.15.1`. This version includes support for configuring **SSE (Server-Side Encryption)** for backups, enhancing security for your backup data and Configuration to **EnableCSI** which enables data agent to use the CSI snapshot feature for handling PVs during backups and restores. - **SSE Encryption Support** Users can now configure Server-Side Encryption for their backups, ensuring enhanced data protection. **Agent Configuration** **Locations Configuration** > To learn more about this, please read our recent [blog](https://docs.rafay.co/blog/2025/01/30/encrypt-your-kubernetes-backups-using-server-side-encryption/) Important Note - **Compatibility with Old Backups**: Old backups will **not** work with the new data agent (`v1.15.1`). - **Upgrade Support**: The upgrade of older data agents to the new data agent version (`v1.15.1`) will be supported in the **future release**. --- #### CNI Default System Blueprints In this release, we have added **default blueprints** for popular CNI providers, including **Calico, Cilium, Kube-OVN, and Kube-OVN Chaining mode CNI** for Upstream Kubernetes for Bare Metal and VMs. These predefined blueprints allow users to quickly provision an upstream **MKS cluster** with a selected CNI. However, these default blueprints **do not support customization**, as they are intended for direct and simplified usage. Users can deploy MKS clusters using the following system default CNI blueprints: - `default-upstream-calico` - `default-upstream-cilium` - `default-upstream-kubeovn` - `default-upstream-kubeovn-chaining` These System default blueprints cannot be customized. For users requiring **custom configurations**, we recommend creating their own addons with tailored settings and using a **custom blueprint** instead as discussed [here](https://docs.rafay.co/clusters/upstream/cni_provider/#cni-providers-for-kubernetes) --- ### Amazon EKS #### Configurable Option to Disable EBS CSI Driver Add-on In certain environments, the infrastructure team is restricted from installing storage drivers on EKS clusters during provisioning. Previously, the **EBS CSI Driver Add-on** was installed by default during EKS cluster setup, while a separate storage team handled storage installation. With this release, a new configuration option allows the infrastructure team to **disable the EBS CSI Driver Add-on** during cluster provisioning. This enhancement provides flexibility by allowing the storage team to manage the installation during **Day 2 operations** after the cluster has been set up. This configuration can be applied through all supported interfaces, including the UI, RCTL, SystemSync and Terraform. **Example `rctl` Configuration:** ``` addonsConfig: disableEBSCSIDriver: true ``` #### Tags and Migration Support for EKS Access Entries In a previous release, we introduced support for **EKS Access Entries**, but without tagging and migration capabilities. With this release, we have added: - **Tagging support** for EKS Access Entries - **Migration support** to seamlessly migrate existing IAM identity mappings from **ConfigMap** to **Access Entries** --- ### Google GKE #### Private Endpoint Subnetwork Support In this release, we have added support for **Private Endpoint Subnetwork** configuration. This feature allows users to provision the control plane's internal endpoint with an IP address from a user-defined subnet range. By specifying an existing subnet, the control plane will be deployed within that network. This configuration is available across all supported interfaces: RCTL, SystemSync, Terraform, and the UI. **Cluster Configuration Snippet** ``` privateCluster: disableSNAT: true enableAccessControlPlaneExternalIP: true enableAccessControlPlaneGlobal: true enablePrivateNodes: true privateEndpointSubnetworkName: demo-subnet ``` --- ### Azure AKS #### Workload Identity UI Support In the **2.10** release, we added **Workload Identity** support through various interfaces such as **RCTL**, **Terraform**, and **SystemSync**, but it was not available through the UI. With this release, we have added full **UI support** for configuring **Workload Identity**. This enhancement allows users to seamlessly set up and manage Workload Identity directly from the **User Interface**, providing a more intuitive and user-friendly experience. --- ### Namespace #### Label Associations This release adds the capability to configure namespace labels at a project level. This feature is particularly useful for scenarios such as chargeback implementation where costs are tracked/allocated based on specific namespace labels. Currently, configuration of namespace labels is supported through non-UI interfaces (RCTl, API, and Terraform). Visibility into the associations between namespaces and their respective labels is available through the platform's UI, ensuring transparency and ease of management for administrators. > To learn more about this, please refer [here](https://docs.rafay.co/cli/ns_cli_tenancy/#namespace-label-configuration-specification) --- ### Environment Manager #### Agent Overrides UI support has been introduced to enable agent override configuration at the environment template level. The available options include: - **Allowed:** End users can specify an agent during environment deployment - **Not Allowed:** End users have to use a pre-configured agent during environment deployment - **Restricted:** End users can choose from a predefined, restricted set of agents configured by the platform administrator Additionally, it is now possible to configure whether agent selection is mandatory or optional for end users. #### Workflow Handlers With this release, “Drivers” has been renamed to “Workflow Handlers” to make it clearer and more intuitive for end users. This resource rename has also been updated in the execute/include configuration of the GitOps pipeline as well. **GitOps System Sync Changes** 1. If resource selection in the system sync pipeline is ALL Spec files will continue syncing to the **"drivers"** folder with the kind **"driver"** (no impact). 2. If resource selection is ALL excluding "driver" Spec files, including existing ones, will now be synced to a newly created **"workflow handler"** folder with the kind **"workflow handler"**. Any changes made in the "driver" folder will not be processed. **Sample Manifest for WorkflowHandler** ``` apiVersion: eaas.envmgmt.io/v1 kind: WorkflowHandler metadata: name: wf-1 project: demoproject spec: config: container: image: registry.dev.rafay-edge.net/rafay/opentofu-driver:main-54 type: container status: {} ``` #### Project overrides There are several use cases where **project-based overrides** are essential. This capability eliminates the need for the platform team to create multiple environment templates (one per team or project), which could otherwise complicate management and degrade the end-user experience. This feature introduces a **generic label-based approach**, enabling variables to be dynamically substituted at the project level. ### Example Use Cases: 1. ServiceNow (SNOW) approval A Platform Admin creates an environment template with an approval step and shares it across multiple projects. However, the approver can vary for each project. 2. vCluster A Platform Admin develops a vCluster template shared across multiple projects. The host cluster selection, however, needs to differ by project. 3. Target AWS Account ID When the target AWS Account ID varies for each project, this feature allows labels to dynamically configure the account ID. This removes the need for end users to manually log in to the AWS console and retrieve the correct account ID to assign to the input variable in the environment. **Note:** Configuration of project-based overrides is currently only supported through **non-UI interfaces**. **Visibility** into project override label configurations is provided through the platform’s UI. This feature streamlines template management, increases flexibility, and enhances the overall user experience. #### Input Variables With this release, Platform Admins now have the ability to customize the environment launch experience for users by **organizing and grouping input variables**. This functionality is achieved through the use of: - **Weights:** Enables ordering of input variables, allowing administrators to control the sequence in which variables appear - **Section Descriptions:** Provides a way to group related input variables into logical sections, complete with descriptive headers - **Tooltips:** Allows administrators to add helpful hints or explanations to individual input variables > To learn more about this, please refer [here](https://docs.rafay.co/env_manager/templates/environment_templates/#input-variables) --- ### Bug Fixes | Bug ID | Description | | --- | --- | | RC-39013 | Git Triggered Workload Publish Failed with Vague Error Due to Misconfigured Secret Provider Class YAML Path | --- ## v1.1.40 - Terraform Provider **20 Jan, 2025** An updated version of the [Terraform provider](https://registry.terraform.io/providers/RafaySystems/rafay/latest) is now available. ## Enhancements This release includes the following enhancement: - `rafay_cluster_sharing_single` : A new resource that allows you to share a cluster with a single project. It ensures the share is restricted to one project, while preserving existing shares for other projects.