Apr

v3.3 - Self-Hosted¶

26 Apr, 2025

The section below provides a brief description of the new functionality and enhancements in this release.

Amazon EKS¶

Bottlerocket¶

This enhancement allows users to update PKI-related settings of Bottlerocket nodes during Day 2 operations. While updates to fields such as data and trusted have been validated, other valid Bottlerocket settings may also be configurable through this mechanism. For a list of valid settings, refer to the Bottlerocket settings index. However, support for additional fields is currently considered beta.

Note: The settings must be specified in YAML format when using rctl and in JSON format when using the UI. TOML is not supported.

Previously, modifying Bottlerocket settings for a managed node group was not supported. Users can now update configurations such as:

bottlerocket:
  settings:
    pki:
      my-trusted-bundle:
        data: LS0tLS1CRUxxxxxxxxxxxxxxxxxxxxxBase 64 Certificate Dataxxxxxxxx
        trusted: true

Since this property change requires creating a new launch template version internally, updating Bottlerocket settings will result in a rolling replacement of EC2 instances within the same node group. This ensures that the new Bottlerocket settings are applied as part of the bootstrapping process for EC2 machines.

Note

Support for updating Bottlerocket settings is available in interfaces such as RCTL, Terraform, API, and SystemSync. UI support will be added in the next release.

Day 2 Support for Updating Tags in Managed Node Groups¶

Previously, tag updates made during Day 2 operations were not reflected in the launch template of the managed node group. This is now being addressed.

With this enhancement, users can add new tags, and these updates will be correctly applied to the launch template as part of the managed node group configuration.

To apply Day 2 tag changes, a new launch template version will be created incorporating the updated tags. As a result, the nodes in the managed node group will be recycled, ensuring the new tags are effectively applied.

Kubernetes v1.32¶

New EKS clusters can now be provisioned based on Kubernetes v1.32. Existing clusters managed by the controller can be upgraded "in-place" to Kubernetes v1.32.

Version 1.32

Upgrade Available Notification

Cluster Successfully Upgraded

Permission Update¶

In Dec 2024, AWS introduced new APIs to programmatically query, retrieve and select available Kubernetes and Platform versions before creating or upgrading clusters. AWS recommends that these APIs be used by users and we have added support for this.

With this release, ensure that your IAM role-based credentials include the required permission eks:DescribeClusterVersions. Internally this permission is used to dynamically retrieve supported EKS versions and the latest available EKS version instead of relying on static configurations. By leveraging this dynamic approach, the platform ensures compatibility with all upcoming EKS releases.

This is required for new clusters as well as existing clusters to ensure proper upgrade functionality.

EKS Upgrade Enhancement¶

The version validation logic for EKS upgrades has been enhanced.

Previously, upgrades were blocked if the difference between the Control Plane (CP) version and the Node Group (NG) version was greater than 1 (n-1).

With this enhancement, the validation has been extended to allow a version difference of up to 3 (n-3).
If the Control Plane and Node Group versions differ by more than 3, the upgrade will be blocked to ensure compatibility and stability.

Upstream Kubernetes for Bare Metal and VMs¶

The features in this section are for Rafay's Kubernetes Distribution (aka Rafay MKS).

Flatcar¶

Support has been added for the Flatcar operating System. This allows customers to leverage Flatcar based nodes for Rafay MKS clusters.

Flatcar

Flatcar Based Cluster

Info

To learn more about this, refer to our blog series:
- Part 1: Introduction to Flatcar
- Part 2: Installing Flatcar Locally
- Part 3: Rafay Managed Upstream Kubernetes on Flatcar

Automated bzip2 Installation in Conjurer Run¶

Conjurer now includes a command to install bzip2 on nodes where required. If bzip2 is already present, installation is skipped, ensuring seamless execution without external dependencies.

Blueprints¶

Support for Draft Versions¶

Support has been added to mark versions as 'Draft' for Add-ons and Blueprints, providing the following benefits:

The platform team can modify Add-ons and Blueprints multiple times during the testing and validation phase without creating a new version each time. Once all necessary changes are complete, the version can be marked as 'Active'
Draft versions are project-scoped, meaning they are not shared with downstream projects. This ensures that only fully vetted Blueprints, explicitly marked as 'Active', are accessible to downstream projects and users.

Note

This feature will initially be supported with non-UI interfaces. Support with UI interface will be added in a subsequent release.

For more information about this feature, click here.

Sync Enhancements for "No Op" scenarios¶

This improvement ensures that only modified components or policies since the last blueprint sync are applied to the cluster, preventing unnecessary reinstallation. As a result, blueprint sync times are optimized, enhancing overall usability. It is recommended to enable blueprint drift prevention alongside this enhancement.

Note

'Force sync' option can be used to reapply all add-ons in the blueprint.

Configurable Add-on/Workload Retries¶

Blueprints and Workloads incorporate health readiness checks to determine when a deployment of YAML/Helm manifest is successful.

In some cases, the failure status takes longer than expected to appear, even when an issue with the deployment is evident. This delay occurs due to multiple readiness check retries.

With this enhancement, users can now configure the number of readiness check retries, offering greater flexibility to fine-tune the process based on the type of manifest being deployed. This setting can be adjusted through Add-on/Workload overrides.

Retry

Info

By default, the number of readiness retries is set to 5.

For more information about this feature, click here for add-ons and workloads

Namespace¶

Character Limit¶

This release includes an enhancement to increase the namespace name character limit from 45 to 63, aligning with Kubernetes standards.

Older Behavior

Previously, namespace names were limited to 45 characters and here’s an example of the error message that would have been returned when exceeding the 45-character limit

Namespace Name Length Error

Updated Behavior

With this release, the namespace name limit has been increased to 63 characters, aligning with Kubernetes standards and allowing more flexibility in naming.

Namespace Creation Success

Multi-tenancy¶

Project Resource Quota¶

The Project Resource Quota feature has been enhanced to support per-cluster overrides. Users can now define resource quotas for individual clusters within a project, rather than applying a single quota uniformly across all clusters as was previously required.

Resource Quota

Integrations¶

OCI Helm Repository¶

Support is being added for OCI Helm repositories, enabling users to deploy Helm charts directly from OCI-compliant container registries. This enhancement allows seamless integration with OCI-based repositories. With this capability, users can also create a custom catalog and leverage OCI-based repositories for efficient Helm chart management and distribution.

OCI Support for Repository

For more information about this feature, click here.

Secrets Management¶

Search by name has been added to the Secrets Provider Classes page to make it easier to find specific entries.

Secrets Provider Search

For more information about this feature, click here.

Workloads & GitOps Pipelines¶

UI improvements¶

Several backend enhancements have been implemented to improve the loading speed of the workload listing page, including faster retrieval of deployment status.

Error Handling and Reporting¶

Several improvements are being implemented to simplify troubleshooting for Workload failures. These enhancements include co-relating Kubernetes events to surface more meaningful error messages from the cluster, making it easier to identify the root cause of deployment failures.

Workload Debug

For more information about this feature, click here.

Deploy Workload Stage¶

When creating a Deploy Workload stage within a GitOps pipeline, workloads are now listed in alphabetical order in the dropdown. Additionally, type-ahead search with auto-suggestions is supported as characters are entered.

Filtering¶

Now, when navigating into a workload or pipeline, making changes, and returning, your previously applied filters are retained—eliminating the need to reapply them.

Environment Manager¶

Skip Condition Support¶

Skip Condition Support for tasks and hooks is being introduced, allowing users to configure notifications and approvals to run only during deploy actions, avoiding execution during destroy operations.

Draft version support¶

Building on the previous release, which introduced draft version support in the UI, this enhancement extends support to non-UI interfaces, including CLI, System Sync, API, and TF provider interfaces.

Function driver¶

Previously, function driver configuration was supported only through non-UI interfaces. This release adds the ability to configure the function driver via the UI interface.

GitOps System Sync¶

With this release, if ALL resources are selected with System Sync, subsequent syncs will be directed to a newly created "workflow handler" folder. Any modifications made in the "driver" folder will no longer be processed.

Sensitive Variables¶

Template/config context pages will now indicate that the variable has a configured value and display it as masked, rather than leaving it blank.

Environment Templates¶

A search box has been added to the resource template selection step, making it easier to find the desired template when creating an environment—especially when many resource templates are available.

Search Resource Template

For more information about this feature, click here

UX improvements¶

Project scoped URLs¶

Added support for project-scoped URLs, allowing users to navigate directly to a specific project. This is especially useful for collaboration/sharing links with team members.

Projects¶

Delete Project API in v3¶

Support is being added for project deletion using the v3 API.

For more information about this feature, click here

Helm App Catalog¶

The Helm App Catalog has been updated to add support for the following repositories.

Category	Description
AI/ML	Apache Yunikorn
AI/ML	Kueue
Kubernetes Lifecycle Management	Karpenter
AI/ML	JobSet
AI/ML	KAI Scheduler by NVIDIA
AI/ML	NVIDIA K8s NIM Operator

For more information about this feature, click here

Bug Fixes¶

Bug ID	Description
RC-40716	Resolved an issue where AKS clusters created prior to the 3.2 release without the create_account field under workload-identities would fail validation during blueprint updates via Terraform
RC-40503	Fixed an issue where EKS add-on configuration values were unintentionally overwritten during cluster upgrades
RC-39697	Fixed an issue where opting out of schedules in an environment would reset parameters to their default values
RC-39669	Resolved an issue where users with both "Infrastructure Read-Only" and "Namespace Admin" roles were granted unintended access to view registries
RC-40491	Resolved an issue where non-UI interfaces would return an error if a node label started with topology.kubernetes.io/
RC-41174	Pod dashboard not working for namespace read-only role
RC-39446	Added an affinity rule to prevent scheduling DaemonSets on EKS Fargate node
RC-39642	Fixed an issue where RCTL could not be used to update Cluster Blueprints in upstream Kubernetes
RC-39336	Resolved a mismatch in namespace name character limits between Rafay and Kubernetes*
RC-39817	Enhanced Conjurer to automatically install missing Ubuntu packages on the node if they are not already present