Rancher Release v2.6.3

Announcements
1

Release v2.6.3

It is important to review the Install/Upgrade Notes below before upgrading to any Rancher version.

Features and Enhancements

New Experimental Features

Kubernetes v1.22 is being introduced in Rancher v2.6.3 as an experimental feature. As such, Rancher doesn’t support provisioning 1.22 clusters or having Rancher run on 1.22 clusters at this time. Support will become available at a later time.

New in Harvester

  • Harvester v1.0.0 is GA and is only supported by Rancher v2.6.3.
  • Harvester v0.3.0 is not supported by Rancher v2.6.3. You must delete your Harvester v0.3.0 cluster from Rancher before upgrading Rancher.
  • Virtualization Management
    • Importing a Harvester cluster no longer needs the manual kubectl command. Refer here for details.
  • RKE1
    • Rancher provisioned RKE1 clusters now support installing Harvester Cloud Provider Chart and CSI Driver Chart. No more manual configuration is needed.
    • Additional UI enhancement has been added to the RKE1 Load Balancer page to support the Harvester Load Balancer configuration. No more manual annotation is needed.
    • Refer to the documentation for more details.
  • RKE2
    • Rancher provisioned RKE2 clusters will have Harvester Load Balancer and CSI driver installed automatically.
    • Additional UI enhancement has been added to the RKE2 Load Balancer page to support the Harvester Load Balancer configuration.
    • Refer to the documentation for more details.

UI Enhancements

  • Scaling up or down of a workload is now enabled in the Rancher UI. See #4328.
  • The scale and health status of a workload is now visible in workload view. See #4329.
  • Added ability to pause orchestration for workloads. See #4331.
  • Added dashboards for workload metrics into the Rancher UI. See #1879.
  • Support added to Azure node driver to use images from Apps & Marketplace. See #33518.
  • UI page load times improved. See #34721.

Security Enhancements

  • By default, only passwords with at least 12 characters are accepted per new password policy in Rancher. See #34851.
  • Starting with v1.22, RKE1 no longer rewrites SELinux labels on container volume mounts. Please see the security docs for information on how to install the rancher-selinux RPM to ensure SELinux policies are configured. See #2541 for reference.

Other New Features

  • Authorized Cluster Endpoint can now be enabled on downstream imported RKE2/K3s clusters. See the documentation and #35161 for details.
  • The Rancher Monitoring chart has been upgraded to match the upstream kube-prometheus-stack version 19.0.3. See #34577.

Major Bug Fixes

  • Fixed issue in which RKE1 and RKE2 Clusters were becoming stuck in Removing state. See #35180.
  • Rancher-related namespaces are now removed after cluster agents are removed on imported provider clusters. See #34990.
  • Fixed issue in which cluster failed to communicate with API server after etcd role node is removed. See #34488.
  • Downstream clusters behind a proxy are now supported when RKE2 cluster is upgraded. See #32633.
  • The API Server has been updated to fix slow consumers causing deadlocks. See #34906.
  • When in installed apps under Apps & Marketplace in a cluster, navigating to workloads after selecting namespace works. See #4428.

Install/Upgrade Notes

  • If you are installing Rancher for the first time, your environment must fulfill the installation requirements.
  • The namespace where the local Fleet agent runs has been changed to cattle-fleet-local-system. This change does not impact GitOps workflows.

Upgrade Requirements

  • Creating backups: We strongly recommend creating a backup before upgrading Rancher. To roll back Rancher after an upgrade, you must back up and restore Rancher to the previous Rancher version. Because Rancher will be restored to its state when a backup was created, any changes post upgrade will not be included after the restore. For more information, see the documentation on backing up Rancher.
  • Helm version: Rancher install or upgrade must occur with Helm 3.2.x+ due to the changes with the latest cert-manager release. See #29213.
  • Kubernetes version:
    • The local Kubernetes cluster for the Rancher server should be upgraded to Kubernetes 1.17+ before installing Rancher 2.5+.
    • When using Kubernetes v1.21 with Windows Server 20H2 Standard Core, the patch “2019-08 Servicing Stack Update for Windows Server” must be installed on the node. See #72.
  • CNI requirements:
    • For Kubernetes v1.19 and newer, we recommend disabling firewalld as it has been found to be incompatible with various CNI plugins. See #28840.
    • If upgrading or installing to a Linux distribution which uses nf_tables as the backend packet filter, such as SLES 15, RHEL 8, Ubuntu 20.10, Debian 10, or newer, users should upgrade to RKE1 v1.19.2 or later to get Flannel version v0.13.0 that supports nf_tables. See Flannel #1317.
    • For users upgrading from >=v2.4.4 to v2.5.x with clusters where ACI CNI is enabled, note that upgrading Rancher will result in automatic cluster reconciliation. This is applicable for Kubernetes versions v1.17.16-rancher1-1, v1.17.17-rancher1-1, v1.17.17-rancher2-1, v1.18.14-rancher1-1, v1.18.15-rancher1-1, v1.18.16-rancher1-1, and v1.18.17-rancher1-1. Please refer to the workaround BEFORE upgrading to v2.5.x. See #32002.
  • Requirements for air gapped environments:
    • For installing or upgrading Rancher in an air gapped environment, please add the flag --no-hooks to the helm template command to skip rendering files for Helm’s hooks. See #3226.
    • If using a proxy in front of an air gapped Rancher, you must pass additional parameters to NO_PROXY. See the documentation and #2725.
  • Cert-manager version requirements: Recent changes to cert-manager require an upgrade if you have a high-availability install of Rancher using self-signed certificates. If you are using cert-manager older than v0.9.1, please see the documentation on how to upgrade cert-manager. See documentation.
  • Requirements for Docker installs:
    • When starting the Rancher Docker container, the privileged flag must be used. See the documentation.
    • When installing in an air gapped environment, you must supply a custom registries.yaml file to the docker run command as shown in the K3s documentation. If the registry has certs, then you will need to also supply those. See #28969.
    • When upgrading a Docker installation, a panic may occur in the container, which causes it to restart. After restarting, the container comes up and is working as expected. See #33685.

Rancher Behavior Changes

  • Legacy features are gated behind a feature flag. Users upgrading from Rancher <=v2.5.x will automatically have the --legacy feature flag enabled. New installations that require legacy features need to enable the flag on install or through the UI.
  • Users must manually remove legacy services. When workloads created using the legacy UI are deleted, the corresponding services are not automatically deleted. Users will need to manually remove these services. A message will be displayed notifying the user to manually delete the associated services when such a workload is deleted. See #34639.
  • Charts from library and helm3-library catalogs can no longer be launched. Users will no longer be able to launch charts from the library and helm3-library catalogs, which are available through the legacy apps and multi-cluster-apps pages. Any existing legacy app that was deployed from a previous Rancher version will continue to be able to edit its currently deployed chart. Note that the Longhorn app will still be available from the library for new installs but will be removed in the next Rancher version. All users are recommended to deploy Longhorn from the Apps & Marketplace section of the Rancher UI instead of through the Legacy Apps pages.
  • The local cluster can no longer be turned off. In older Rancher versions, the local cluster could be hidden to restrict admin access to the Rancher server’s local Kubernetes cluster, but that feature has been deprecated. The local Kubernetes cluster can no longer be hidden and all admins will have access to the local cluster. If you would like to restrict permissions to the local cluster, there is a new restricted-admin role that must be used. The access to local cluster can now be disabled by setting hide_local_cluster to true from the v3/settings API. See the documentation and #29325. For more information on upgrading from Rancher with a hidden local cluster, see the documentation.
  • Users must log in again. After upgrading to v2.6+, users will be automatically logged out of the old Rancher UI and must log in again to access Rancher and the new UI. See #34004.
  • Fleet is now always enabled. For users upgrading from v2.5.x to v2.6.x, note that Fleet will be enabled by default as it is required for operation in v2.6+. This will occur even if Fleet was disabled in v2.5.x. During the upgrade process, users will observe restarts of the rancher pods, which is expected. See #31044 and #32688.
  • The Fleet agent in the local cluster now lives in cattle-fleet-local-system. Starting with Rancher v2.6.1, Fleet allows for two agents in the local cluster for scenarios where “Fleet is managing Fleet”. The true local agent runs in the new cattle-fleet-local-system namespace. The agent downstream from another Fleet management cluster runs in cattle-fleet-system, similar to the agent pure downstream clusters. See #34716 and #531.
  • Editing and saving clusters can result in cluster reconciliation. For users upgrading from <=v2.4.8 (<= RKE v1.1.6) to v2.4.12+ (RKE v1.1.13+)/v2.5.0+ (RKE v1.2.0+) , please note that Edit and save cluster (even with no changes or a trivial change like cluster name) will result in cluster reconciliation and upgrading kube-proxy on all nodes because of a change in kube-proxy binds. This only happens on the first edit and later edits shouldn’t affect the cluster. See #32216.
  • The EKS cluster refresh interval setting changed. There is currently a setting allowing users to configure the length of refresh time in cron format: eks-refresh-cron. That setting is now deprecated and has been migrated to a standard seconds format in a new setting: eks-refresh. If previously set, the migration will happen automatically. See #31789.
  • System components will restart. Please be aware that upon an upgrade to v2.3.0+, any edits to a Rancher launched Kubernetes cluster will cause all system components to restart due to added tolerations to Kubernetes system components. Plan accordingly.
  • New GKE and AKS clusters will use Rancher’s new lifecycle management features. Existing GKE and AKS clusters and imported clusters will continue to operate as-is. Only new creations and registered clusters will use the new full lifecycle management.
  • New steps for rolling back Rancher. The process to roll back Rancher has been updated for versions v2.5.0 and above. New steps require scaling Rancher down to 0 replica before restoring the backup. Please refer to the documentation for the new instructions.
  • RBAC differences around Manage Nodes for RKE2 clusters. Due to the change of the provisioning framework, the Manage Nodes role will no longer be able to scale up/down machine pools. The user would need the ability to edit the cluster to manage the machine pools #34474.
  • New procedure to set up Azure cloud provider for RKE2. For RKE2, the process to set up an Azure cloud provider is different than for RKE1 clusters. Users should refer to the documentation for the new instructions. See #34367 for original issue.
  • Machines vs Kube Nodes. In previous versions, Rancher only displayed Nodes, but with v2.6, there are the concepts of machines and kube nodes. Kube nodes are the Kubernetes node objects and are only accessible if the Kubernetes API server is running and the cluster is active. Machines are the cluster’s machine object which defines what the cluster should be running.
  • Rancher’s External IP Webhook chart no longer supported in v1.22. In v1.22, upstream Kubernetes has enabled the admission controller to reject usage of external IPs. As such, the rancher-external-ip-webhook chart that was created as a workaround is no longer needed, and support for it is now capped to Kubernetes v1.21 and below. See #33893.
  • Requirements for Docker installs.
    • When starting the Rancher Docker container, the privileged flag must be used. See the documentation.
    • When installing in an air gapped environment, you must supply a custom registries.yaml file to the docker run command as shown in the K3s documentation. If the registry has certs, then you will need to also supply those. See #28969.
  • Increased memory limit for Legacy Monitoring. The default value of the Prometheus memory limit in the legacy Rancher UI is now 2000Mi to prevent the pod from restarting due to a OOMKill. See #34850.
  • Increased memory limit for Monitoring. The default value of the Prometheus memory limit in the new Rancher UI is now 3000Mi to prevent the pod from restarting due to a OOMKill. See #34850.

Versions

Please refer to the README for latest and stable versions.

Please review our version documentation for more details on versioning and tagging conventions.

Images

  • rancher/rancher:v2.6.3

Tools

Rancher Helm Chart Versions

Starting in 2.6.0, many of the Rancher Helm charts available in the Apps & Marketplace will start with a major version of 100. This was done to avoid simultaneous upstream changes and Rancher changes from causing conflicting version increments. This also brings us into compliance with semver, which is a requirement for newer versions of Helm. You can now see the upstream version of a chart in the build metadata, for example: 100.0.0+up2.1.0. See #32294.

Other Notes

Feature Flags

Feature flags introduced in 2.6.0 and the Harvester feature flag introduced in 2.6.1 are listed below for reference:

Feature Flag Default Value Description
harvester true Used to manage access to the Harvester list page where users can navigate directly to Harvester host clusters and have the ability to import them.
fleet true The previous fleet feature flag is now required to be enabled as the fleet capabilities are leveraged within the new provisioning framework. If you had this feature flag disabled in earlier versions, upon upgrading to Rancher, the flag will automatically be enabled.
gitops true If you want to hide the “Continuous Delivery” feature from your users, then please use the newly introduced gitops feature flag, which hides the ability to leverage Continuous Delivery.
rke2 true We have introduced the ability to provision RKE2 clusters as tech preview. By default, this feature flag is enabled, which allows users to attempt to provision these type of clusters.
legacy false for new installs, true for upgrades There are a set of features from previous versions that are slowly being phased out of Rancher for newer iterations of the feature. This is a mix of deprecated features as well as features that will eventually be moved to newer variations in Rancher. By default, this feature flag is disabled for new installations. If you are upgrading from a previous version, this feature flag would be enabled.
token-hashing false for new installs, true for upgrades Used to enable new token-hashing feature. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically using the SHA256 algorithm. Once a token is hashed it cannot be undone. Once this feature flag is enabled it cannot be disabled.

Experimental Features

RancherD was introduced in 2.5 as an easy-to-use installation binary. With the introduction of RKE2 provisioning, this project is being re-written and will be available at a later time. See #33423.

Legacy Features

Legacy features are features hidden behind the legacy feature flag, which are various features/functionality of Rancher that was available in previous releases. These are features that Rancher doesn’t intend for new users to consume, but if you have been using past versions of Rancher, you’ll still want to use this functionality.

When you first start 2.6, there is a card in the Home page that outlines the location of where these features are now located.

The deprecated features from v2.5 are now behind the legacy feature flag. Please review our deprecation policy for questions.

The following legacy features are no longer supported on Kubernetes v1.21+ clusters:

  • Logging
  • CIS Scans
  • Istio 1.5
  • Pipelines

The following legacy feature is no longer supported past Kubernetes v1.21+ clusters:

  • Monitoring V1

Known Major Issues

  • Kubernetes Cluster Distributions:
    • RKE:
      • Rotating encryption keys with a custom encryption provider is not supported. See #30539.
      • Actions that can’t be performed by a cluster member, Download KubeConfig and Take Snapshot, are being shown as available on RKE1 clusters in a Rancher setup. See #35828.
    • RKE2 - Tech Preview: There are several known issues as this feature is in tech preview, but here are some major issues to consider before using RKE2.
      • Amazon ECR Private Registries are not functional. See #33920.
      • Windows clusters do not yet support Rancher Apps & Marketplace. See #34405.
      • Windows clusters do not yet support upgrading RKE2 versions. See Windows #76.
      • Rancher v2.6.3 cannot deploy RKE2 Windows clusters with versions 1.21.6+rke2r1 and below due to system agent updates. Note that RKE2 clusters with v1.21.7rc2 and higher are compatible with Rancher v2.6.3. See #122.
      • When provisioning using a RKE2 cluster template, the rootSize for AWS EC2 provisioners does not currently take an integer when it should, and an error is thrown. To work around this issue, wrap the EC2 rootSize in quotes. See #3689.
      • RKE2 clusters are not able to be provisioned using the AWS cloud provider in Kubernetes v1.22. Note that RKE2 clusters in v1.21 function as expected. See #35618.
      • Standard users will not be able to create a cluster after clicking the Edit as YAML button. They will receive an error even if attempting to then Edit as a Form. To work around this issue, start over and create the cluster without clicking the Edit as YAML button. See #35868.
    • AKS:
      • When editing or upgrading the AKS cluster, do not make changes from the Azure console or CLI at the same time. These actions must be done separately. See #33561.
      • Windows node pools are not currently supported. See #32586.
      • Azure Container Registry-based Helm charts cannot be added in Cluster Explorer, but do work in the Apps feature of Cluster Manager. Note that when using a Helm chart repository, the disableSameOriginCheck setting controls when credentials are attached to requests. See documentation and #34584 for more information.
    • GKE:
      • Basic authentication must be explicitly disabled in GCP before upgrading a GKE cluster to 1.19+ in Rancher. See #32312.
    • AWS:
      • In an HA Rancher server on Kubernetes v1.20, ingresses on AWS EC2 node driver clusters do not go through and result in a failed calling webhook error. Please refer to the workaround and #35754.
  • Infrastructures:
    • vSphere:
      • The vSphere CSI Driver does not support Kubernetes v1.22 due to unsupported v1beta1 CRD APIs. Support will be added in a later release, but in the meantime users with the CSIMigrationvSphere feature enabled should not
        upgrade to Kubernetes v1.22. See #33848.
      • PersistentVolumes are unable to mount to custom vSphere hardened clusters using CSI charts. See #35173.
  • Harvester:
    • Upgrades from Harvester v0.3.0 are not supported.
    • Deploying Fleet to Harvester clusters is not yet supported. Clusters, whether Harvester or non-Harvester, imported using the Virtualization Management page will result in the cluster not being listed on the Continuous Delivery page. See #35049.
  • Cluster Tools:
    • Fleet:
      • Multiple fleet-agent pods may be created and deleted during initial downstream agent deployment; rather than just one. This resolves itself quickly, but is unintentional behavior. See #33293.
    • Hardened clusters: Not all cluster tools can currently be installed on a hardened cluster.
    • Rancher Backup:
      • When migrating to a cluster with the Rancher Backup feature, the server-url cannot be changed to a different location. It must continue to use the same URL.
      • When running a newer version of the rancher-backup app to restore a backup made with an older version of the app, the resourceSet named rancher-resource-set will be restored to an older version that might be different from the one defined in the current running rancher-backup app. The workaround is to edit the rancher-backup app to trigger a reconciliation. See #34495.
      • Because Kubernetes v1.22 drops the apiVersion apiextensions.k8s.io/v1beta1, trying to restore an existing backup file into a v1.22 cluster will fail because the backup file contains CRDs with the apiVersion v1beta1. There are two options to work around this issue: update the default resourceSet to collect the CRDs with the apiVersion v1, or update the default resourceSet and the client to use the new APIs internally. See documentation and #34154.
    • Monitoring:
      • Deploying Monitoring on a Windows cluster with win_prefix_path set requires users to deploy Rancher Wins Upgrader to restart wins on the hosts to start collecting metrics in Prometheus. See #32535.
      • Monitoring fails to upgrade when CRD is in a failed state. To work around this issue, use Helm to install the rancher-monitoring chart into the cluster directly, rather than using the Rancher UI. In order to set nodeSelector or tolerations to the rancher-monitoring-crd chart, you need to install the rancher-monitoring-crd and rancher-monitoring chart by using the Helm command via command line. Rancher UI will add support soon. See #35744.
      • When deploying a cluster on v1.22, the pod rancher-monitoring-admission-patch fails and times out, which causes the Monitoring install to fail. To deploy the rancher-monitoring chart successfully in RKE1/RKE2 1.22.x, please see workaround. See also #35571.
    • Logging:
      • Windows nodeAgents are not deleted when performing helm upgrade after disabling Windows logging on a Windows cluster. See #32325.
    • Istio versions:
      • Istio 1.5 is not supported in air gapped environments. Please note that the Istio project has ended support for Istio 1.5.
      • Istio 1.9 support ended on October 8th, 2021.
      • The Kiali dashboard bundled with 100.0.0+up1.10.2 errors on a page refresh. Instead of refreshing the page when needed, simply access Kiali using the dashboard link again. Everything else works in Kiali as expected, including the graph auto-fresh. See #33739.
      • In Istio v1.10.4, Kubernetes IP service is set to default IP, which does not work for all environments. To work around this issue, install Istio version 100.1.0+up1.11.4 in the downstream cluster, and installation will complete successfully. Note that the new install will not include the Kiali CRD. See #35339.
      • Istio 100.1.0+up1.11.4 no longer installs the Kiali CRD because it was removed from the upstream Helm chart starting in Kiali version 1.36. If you have upgraded from a previous version of rancher-istio installed to 100.1.0+up1.11.4, you will need to manually delete the rancher-kiali-server-crd found on the installed apps page, since it is no longer in use after the upgrade completes. See #35686 for more information.
      • A failed calling webhook "validation.istio.io" error will occur in air-gapped environments if the istiod-istio-system ValidatingWebhookConfiguration exists, and you attempt a fresh install of Istio 1.11.x and higher. To work around this issue, run the command kubectl delete validatingwebhookconfiguration istiod-istio-system and attempt your install again. See #35742.
      • Deprecated resources are not automatically removed and will cause errors during upgrades. Manual steps must be taken to migrate and/or cleanup resources before an upgrade is performed. See #34699.
    • Legacy Monitoring:
      • The Grafana instance inside Cluster Manager’s Monitoring is not compatible with Kubernetes v1.21. To work around this issue, disable the BoundServiceAccountTokenVolume feature in Kubernetes v1.21 and above. Note that this workaround will be deprecated in Kubernetes v1.22. See #33465.
      • In air gapped setups, the generated rancher-images.txt that is used to mirror images on private registries does not contain the images required to run Legacy Monitoring which is compatible with Kubernetes v1.15 clusters. If you are running Kubernetes v1.15 clusters in an air gapped environment, and you want to either install Legacy Monitoring or upgrade Legacy Monitoring to the latest that is offered by Rancher for Kubernetes v1.15 clusters, you will need to take one of the following actions:
        • Upgrade the Kubernetes version so that you can use v0.2.x of the Monitoring application Helm chart
        • Manually import the necessary images into your private registry for the Monitoring application to use
      • When deploying any downstream cluster, Rancher logs errors that seem to be related to Monitoring even when Monitoring is not installed onto either cluster; specifically, Rancher logs that it failed on subscribe to the Prometheus CRs in the cluster because it is unable to get the resource prometheus.meta.k8s.io. These logs appear in a similar fashion for other Prometheus CRs (namely Alertmanager, ServiceMonitors, and PrometheusRules), but do not seem to cause any other major impact in functionality. See #32978.
      • Legacy Monitoring does not support Kubernetes v1.22 due to the feature-gates flag no longer being supported. See #35574.
      • After performing an upgrade to Rancher v2.6.3 from v2.6.2, the Legacy Monitoring custom metric endpoint stops working. To work around this issue, delete the service that is being targeted by the servicemonitor and allow it to be recreated; this will reload the pods that need to be targeted on a service sync. See #35790.
  • Docker installs:
    • UI issues may occur due to a longer startup time. User will receive an error message when launching Docker for the first time #28800, and user is directed to username/password screen when accessing the UI after a Docker install of Rancher #28798.
    • On a Docker install upgrade and rollback, Rancher logs will repeatedly display the messages “Updating workload ingress-nginx/nginx-ingress-controller” and “Updating service frontend with public endpoints”. Ingresses and clusters are functional and active, and logs resolve eventually. See #35798.
  • Login to Rancher using ActiveDirectory with TLS: See #34325.
    • Upon an upgrade to v2.6.0, authenticating via Rancher against an ActiveDirectory server using TLS can fail if the certificates on the AD server do not support SAN attributes. This is a check enabled by default in Golang v1.15.
    • The error received is “Error creating ssl connection: LDAP Result Code 200 “Network Error”: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0”
    • To resolve this, the certificates on the AD server should be updated or replaced with new ones that support the SAN attribute. Alternatively this error can be ignored by setting “GODEBUG=x509ignoreCN=0” as an environment variable to Rancher server container.
  • Rancher UI:
    • After clicking on the header of an expanded navigation group, the navigation group remains unchanged. See #4368.
  • Legacy UI:
    • When using the Rancher v2.6 UI to add a new port of type ClusterIP to an existing Deployment created using the legacy UI, the new port will not be created upon saving. To work around this issue, repeat the procedure to add the port again. Users will notice the Service Type field will display as Do not create a service. Change this to ClusterIP and upon saving, the new port will be created successfully during this subsequent attempt. See #4280.
2

Warning: If single-node Docker installation with persistent data is used, upgrading to Rancher 2.6.3 wipes all data. Refer here to work around this issue. Be aware that the single-node Docker installation is not supported for production.