Rancher Release - v2.4.0

Release v2.4.0

Important

  • Users using a single Docker container install - Etcd in the Docker container has been upgraded from 3.3 to 3.4, therefore you must take a backup before upgrading in order to be able to roll back to a v2.3.x release. You will not be able to rollback without this backup.

  • Users using node pools with RHEL/CentOS nodes [#18065]: The default storage driver for RHEL/CentOS nodes has been updated to overlay2. If your node template does not specify a storage driver, any new node will be provisioned using the new updated default (overlay) instead of the old default (devicemapper). If you need to keep using devicemapper as your storage driver option, edit your node template to explicitly set the storage driver as `devicemapper.

  • Users running Windows clusters [#25582] - Windows has launched a security patch as of Feb 11. Before upgrading, please update your nodes to include this security patch, otherwise your upgrade will fail until the patch is applied.

  • Rancher launched clusters require additional 500MB space - By default, Rancher launched clusters have enabled audit logging on the cluster.

  • Rancher launched Kubernetes clusters behavior of upgrades have changed [#23897] - Please refer to the zero downtime upgrades feature to read more about it.

Versions

The following versions are now latest and stable:

Type Rancher Version Docker Tag Helm Repo Helm Chart Version
Latest v2.4.0 rancher/rancher:latest server-charts/latest v2.4.0
Stable v2.3.6 rancher/rancher:stable server-charts/stable v2.3.6

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

Features and Enhancements

  • CIS scanning [#18600]: Ensuring continuous CIS compliance is now possible directly in Rancher. Rancher operators can perform CIS scans of RKE clusters ad-hoc or on regularly scheduled intervals. Operators can see the history of compliance scans and produce a report for auditors. Continuously scanning clusters on an interval, an operator can be notified when a configuration drift is detected. The scans are customizable through configuration so that tests can be skipped if a control does not apply to your installation.

  • Scale improvements [#23013]: Rancher control plane now manages up to 2,000 clusters or 100,000 nodes. Rancher moved to a shared global context cluster state, reducing the memory footprint and Kubernetes API connections needed to manage each cluster. Rancher controllers were optimized to reduce the overall number of calls to the Kubernetes API. Based on these improvements, new sizing guidelines have been provided for installing Rancher.

  • Zero downtime upgrades [#23038, #20465]: Updates to RKE clusters can now be made without impacting the availability of the Kubernetes API and user workloads. The upgrade process of the cluster control plane has been modified to update a single node at a time. The number of worker nodes that can be upgraded at a time is now user-configurable. For clusters that need maximum availability, a single node can be upgraded at a time. For those working with larger RKE clusters, the number can be scaled up so that upgrades can happen in a shorter timeframe.

  • Atomic Cluster Rollbacks [#22232]: Rancher now supports rolling back both the etcd database and the Kubernetes configuration in a single operation. This operation can be used mid-upgrade if there are problems/complications and the operator needs to revert to the last known state. During the rollback process, there are no availability guarantees.

  • Upgrade K3s clusters from Rancher [#25141]: Imported K3s clusters are now upgradeable from within Rancher. Rancher now detects that a K3s cluster has been imported and presents new options to the operator when editing the cluster. The option to select the Kubernetes version is now available, along with a read-only view of the configuration parameters of the server.

  • Helm 3 support to catalogs [#20596]: Rancher catalog now supports Helm 3 charts. An admin, cluster or project owner can add catalogs to use Helm 3 to deploy charts. Any existing catalogs will continue to use Helm 2 to deploy charts.

  • K3s is a supported Rancher HA distribution [#25495]: Rancher HA is now supports K3s as an underlying Kubernetes distribution. A Rancher admin can create a K3s cluster using managed MySQL service and stateless nodes to deploy Rancher management. The need to manage an etcd cluster is no longer necessary.

  • Authentication and RBAC enhancements:

    • Assign groups to global roles [#22707]: Global roles in Rancher now support group assignments from your auth provider. Assigning groups, means administrators do not need to modify assignments as team members come and go within your organization.
    • Customize global roles [#16216]: The default behavior can now be customized for all users by creating global roles.
    • Shibboleth as an auth provider [#19776]: Shibboleth is now available as an authentication provider.
    • Shibboleth and OpenLDAP [#14404]: OpenLDAP can be configured with Shibboleth to provide searching for users and groups that a user is not a member of. Note: Users in within a nested group will not be provided the same privileges as the group added. For example, group A includes group B. The members in group B will not get the same privileges as group A.
  • Monitoring Enhancements:

    • Remote read/write configs [#20624]: Ability to remote read/write. This allows additional integrations with remote storage solutions.
    • Configuration of livenessProbe settings [#23983]: - Ability to configure the livenessProve settings
  • OS Updates:

    • Added support for Oracle Linux 7.7 [#25192]
    • Suse Linux 12 SP5 [#23044]
  • Hosted K8S Providers Update:

    • EKS: Added 1.15, Removed 1.11 and 1.12
    • EKS: Ability to encrypt EBS volume for /dev/xvda1 [#22633, #21552]
  • Rancher Launched Kuberentes Clusters Update:

    • Ability to use nodelocal DNS [#25811]
    • New clusters will automatically have audit logging turned on

Experimental Features

  • OPA Gatekeeper [#23753]: Rancher now provides experimental support for the Open Policy Agent Gatekeeper operator. Rancher will deploy and manage the installation and setup a validating webhook for the cluster. Admins can interact with the custom resources through the next-gen UI to define policies in the cluster and apply them to various namespaces as needed.

  • Preview next-gen UI: The next generation Rancher UI is available in preview mode at the cluster view level. The new Rancher UI provides navigation based on native Kubernetes namespaces. Rancher projects are still available to the end-user for managing attributes across multiple namespaces. A YAML editor provides a way to edit all Kubernetes objects with field suggestions based on OpenAPI specs. Note: This is not supported in an air gap environment while it’s still experimental.

Feature Flags for Experimental Features

We have the ability to turn on and off specific experimental components inside Rancher. You can manage feature flags through our UI. Certain feature flags require a Rancher restart. Alternatively, you can refer to our docs on how to turn on the features when starting Rancher.

Feature Flag Feature Flag Name Default Value Available as of Rancher Restart Required?
Next Gen UI dashboard true v2.4.0 x
New Proxy proxy false v2.4.0
UI for unsupported storage drivers unsupported-storage-drivers false v2.3.0

Major Bugs Fixed Since v2.3.6

  • Fixed an issue where the Rancher CLI could not SSH into nodes in EC2 [#13556]
  • Fixed an issue where setting up node alerts for memory reservation would set up an alert for cpi reservation [#23308]
  • Fixed an issue where the local cluster wouldn’t show if the cert was expired [#23543]
  • Fixed an issue where the weave password would change between cluster updates which would cause networking issues [#23702]
  • Fixed an issue where sometimes rotating the etcd certificate would fail [#23827]
  • Fixed an issue where CRD managed pods were not showing up in the UI when grouped by namespace/workload view [#22106]
  • Fixed an issue when configuring a notifier email would return plaintext password [#24335]
  • Fixed an issue where recurring S3 snapshots are only deleted locally when a folder is configured [#24544]
  • Fixed an issue where the boot2docker.iso file would persist in vSphere datastore after deletion of node in Rancher [#24758]
  • Fixed an issue where helm would fail when invalid chart URLs were in a catalog [#24914]
  • Fixed an issue where logging containers would not work when SElinux was in enforcing mode [#25182]
  • Fixed an issue where PVC fails to attach during workload creation [#22614]
  • Fixed an issue where cluster provisioning fails with AWS cloud provider and IAM profile name [#22814]
  • Fixed an issue where support for S3 snapshots were not working when the IAM profile wasn’t accessible on the Rancher server nodes [#22900]
  • Fixed an issue where you can’t add node labels to imported k3s or RKE nodes [#23840]
  • Fixed an issue where the monitoring app and namespace were left after deleting the project [#23848]
  • Fixed an issue where chart versions couldn’t accept the + sign [#24863]
  • Fixed an issue where pod usage (CPU/memory) is doubled [#25539]

Other notes

Air Gap Installations and Upgrades

In v2.4.0, an air gap installation no longer requires mirroring the systems chart git repo. Please follow the directions on how to install Rancher to use the packaged systems chart.

Known Major Issues

  • When nodes are powered off in the cluster, the metrics server pod and coreDNS pod may not get evicted from the node and needs to be manually deleted until it’s re-scheduled to an active node [#26190, #26191]
  • Single node k3s clusters will keep showing Upgrading even after the cluster is already upgraded [#26286]
  • Logging doesn’t work on imported k3s clusters [#24157]

Versions

Images

  • rancher/rancher:v2.4.0
  • rancher/rancher-agent:v2.4.0

Tools

Kubernetes

Upgrades and Rollbacks

Rancher supports both upgrade and rollback. Please note the version you would like to upgrade or rollback to change the Rancher version.

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.

Recent changes to cert-manager require an upgrade if you have an HA 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.

Important: When rolling back, we are expecting you to rollback to the state at the time of your upgrade. Any changes post upgrade would not be reflected.