Release v2.15.2

The webhook now rejects attempts from outside of Rancher to edit these managed resources, to promote an unmanaged resource to managed, or to demote a managed resource to unmanaged, while still allowing Rancher itself full access. See #56773.

Rancher v2.15 removes support for Kubernetes v1.33. See #55306.

The option to disable the feature flag ui-sql-cache / Vai / Server-Side Pagination (SSP) in the Rancher UI has been removed in preparation for Rancher v2.16, where the feature will always be enabled. See #16822.

Removal: Support for Ember-based UI plugins for cluster and node drivers (deprecated since Rancher v2.11.0) is removed in Rancher v2.15.0. Migrate your plugins to the UI Extensions Framework. For details, see #14005.

By default, the Standard User and Create Clusters global permissions now allow creating and then updating CAPI infrastructure objects in the fleet-default namespace. Note that manually created infrastructure provider identity objects, such as AWSClusterStaticIdentity or VSphereClusterIdentity, that target the fleet-default namespace can be used through CAPI infrastructure objects such as AWSCluster or VsphereCluster. See #53777.

When using native CAPI infrastructure providers with v2prov, Rancher will now generate the bootstrap cloud-config in the Jinja format. User-data for regular node drivers with v2prov is unaffected. See #53777.

Deprecation: Fleet will be removing support for GitRepoRestriction in a future release, making the use of the Policy resource for configuring multi-tenant environments the only option. See #55652.

Deprecation: Fleet support for unauthenticated webhook calls will be removed in a future release, making the setup of a webhook secret the only option. See #55633. == Long-standing Known Issues

Creating or editing v2prov clusters with native CAPI infrastructure providers from the UI can under some failure conditions leave unused infrastructure resources in the management cluster that must be cleaned up manually. See #55705.

When you attempt to register a new etcd/controlplane node in a CAPR-managed cluster after a failed etcd snapshot restoration, the node can become stuck in a perpetual paused state, displaying the error message [ERROR] 000 received while downloading Rancher connection information. Sleeping for 5 seconds and trying again. As a workaround, you can unpause the cluster by running kubectl edit clusters.cluster clustername -n fleet-default and set spec.unpaused to false. See #43735.

Due to the backoff logic in various components, downstream provisioned K3s and RKE2 clusters may take longer to re-achieve Active status after a migration. If you see that a downstream cluster is still updating or in an error state immediately after a migration, please let it attempt to resolve itself. This might take up to an hour to complete. See #34518 and #42834.

Provisioning RKE2/K3s clusters with added (not built-in) custom node drivers causes provisioning to fail. As a workaround, fix the added node drivers after activating. See #37074.

Provisioning RKE2/K3s clusters with added (not built-in) custom node drivers causes provisioning to fail. As a workaround, fix the added node drivers after activating. See #37074.

Clusters remain in an Updating state even when they contain nodes in an Error state. See #39164.

After deleting a Namespace or Project in the Rancher UI, the Namespace or Project remains visible. As a workaround, refresh the page. See #12220.

Although system mode node pools must have at least one node, the Rancher UI allows a minimum node count of zero. Inputting a zero minimum node count through the UI can cause cluster creation to fail due to an invalid parameter error. To prevent this error from occurring, enter a minimum node count at least equal to the node count. See #11922.

When creating a cluster in the Rancher UI it does not allow the use of an underscore _ in the Cluster Name field. See #9416.

Deployment securityContext section is missing when a new workload is created. This prevents pods from starting when Pod Security Policy Support is enabled. See #4815.

EKS clusters on Kubernetes v1.21 or below on Rancher v2.7 cannot be upgraded. See #39392.

There are some known issues with the OpenID Connect provider support:

A webhook is installed in all downstream clusters. There are several issues that users may encounter with this functionality:

When upgrading to Rancher v2.13.1 or higher while using Harvester v1.6.1, users may encounter an issue with their Load Balancers in downstream clusters using the Harvester Cloud Provider, and must perform the following workaround to instruct Calico to not use any of the IP/interface managed by kube-vip. See #9767.

If you’re using Rancher v2.7.2 with Harvester v1.1.1 clusters, you won’t be able to select the Harvester cloud provider when deploying or updating guest clusters. The Harvester release notes contain instructions on how to resolve this. See #3750.

When performing a rollback from Rancher v2.13.0 to v2.12.3 using the backup and restore operator (BRO), the restore does not complete successfully. See #844. To work around this issue, you must scale down your Rancher deployment and uninstall the Webhook chart before performing the restore. For details, refer to this Knowledge Base article.

Due to the backoff logic in various components, downstream provisioned K3s and RKE2 clusters may take longer to re-achieve Active status after a migration. If you see that a downstream cluster is still updating or in an error state immediately after a migration, please let it attempt to resolve itself. This might take up to an hour to complete. See #34518 and #42834.