Release v2.2.2

Release v2.2.2

Important notes

This release addresses a security vulnerability found in Rancher: the default admin account that is created when Rancher is first launched will be recreated on subsequent restarts of Rancher, even if the account was explicitly deleted by a Rancher administrator. This poses a security risk because the account is recreated with Rancher’s default username and password. A fix for versions v2.1.x and v2.0.x will be released in the near future, but until then this flaw can be easily mitigated in all versions of Rancher by disabling the default admin account rather than deleting it entirely. You can view the official CVE here CVE-2019-11202.
This release also addresses several stability and performance issues. As a result, the following versions are now latest and stable:|Type | Rancher Version | Docker Tag |Helm Repo| Helm Chart Version | |—|—|—|—|—| | Latest | v2.2.2 | rancher/rancher:latest | server-charts/latest |v2.2.2 | | Stable | v2.2.2 | rancher/rancher:stable | server-charts/stable | v2.2.2 |
In Rancher 2.0 and 2.1, the auto generated certificates for Rancher provisioned clusters have 1 year of expiry. It means if you created a Rancher provisioned cluster about 1 year ago, you need to rotate the certificates, otherwise the cluster will go into a bad state when the certificate expires. In Rancher 2.2.2, the rotation can be performed from Rancher UI, more details are here. We are working on providing a back-port solution for users on 2.0 and 2.1, which will help to rotate the certificates on existing clusters without the requirement to upgrade to 2.2.2.
Due to its stability issues, Project Monitoring feature is temporarily revoked from the release. We are going to address the issues, and add the feature back to the next planned maintenance release.Please review our version documentation for more details on versioning and tagging conventions.

Features and Enhancements

Added Kubernetes v1.14.1 as experimental version. [19432]

Major Bug Fixed Since v2.2.1

We’ve addressed over 30 bugs in this release. The following is a list of the major bugs fixed:

Added major performance improvements to Rancher API and UI. [19443], [19490]
Added checks to prevent enabling monitoring in clusters that don’t have enough CPU/RAM resources, and improved the feature UX around it. [19311], [19394]
Fixed an issue where monitoring was affecting overall performance of Rancher server. [19316]
Fixed an issue where an error was reported in the UI for monitoring, when in fact monitoring was running fine [19380]
Fixed an issue where when viewing a Global DNS entry that targets a multi-cluster application, if the user didn’t have an access to all of the projects that are a part of the mult-cluster application, they would see broken links to those projects. [#19369]
Fixed an issue where Azure AD login was broken for the case when Azure service account password contained “:” . [19346]
Fixed the situation where self signed certificate used for communication with a standalone Rancher server could expire. [19155]
Fixed an issue where node template legacy API was broken. [19314]
Fixed an issue where node templates couldn’t be added for AWS China regions. [19312]
Fixed an issue where publishing catalog template could fail with certificate error. [19313]
Improved Dashboard UI visibility by removing unnecessary outlines and dots. [19308]
Fixed an issue where etcd snapshots weren’t working for Rancher provisioned clusters having RHEL nodes with Selinux on [19421]
Fixed an issue where Rancher provisioned cluster state was fetched incorrectly in clusters with a prefix patch [19484]

Other notes

Server Chart Versioning Change

We’ve changed the Rancher Server chart versioning scheme from the “datestamp” style (2019.1.x) used in v2.1 to versions that match the Rancher Server release (2.1.x). With the release of 2.2.0, the previous “datestamp” style releases have been removed from the repo and replaced by charts versioned in step with the Rancher Server version.

In the process of creating security updates for the 2.0.x series, we discovered that the “datestamp” style of versioning we had adopted with the 2.1.x release would not allow us to easily create security updates to the 2.1.x series once we released 2.2.0.

For more details and history of our Rancher Server chart versioning, please see this issue #17663.

Additional Steps Required for Air Gap Installations and Upgrades

In this release, we’ve introduce a “system catalog” for managing microservices that Rancher deploys for certrain features such as Global DNS, Alerts, and Monitoring. These additional steps are documented as part of air gap installation instructions.

Docs Changes

With this release, the docs navigation has been updated for better usability. Please refer to the docs release notes for more details.

RKE Add-on Install is only Supported up to Rancher v2.0.8

Due to the HA improvements introduced in the v2.1.0 release, the Rancher helm chart is the only supported method for installing or upgrading Rancher. Please use the Rancher helm chart to install HA Rancher. For details, see the HA Install - Installation Outline.

If you are currently using the RKE add-on install method, see Migrating from a RKE add-on install for details on how to move to using a helm chart.

Known Major Issues

Users wishing to utilize the new backup and restore functionality must edit their clusters, explicitly enable the feature, and save the changes. The backup functionality exposed in v2.1 is now considered legacy, but it will continue to function until you explicitly edit and save your cluster. [#18754]
Manual backups are deleted based on retention count configuration settings and recurring snapshot creation time is impacted by taking a manual snapshot. [#18807]
If snapshotting is disabled, users cannot restore from existing backups or take manual backups. #18793
Cannot rotate CA certificate for RKE clusters. The CA certificate has a 10 year expiration, so it is not in danger of expiring in the near future. [19050]
Global DNS entries are not properly updated when a node that was hosting an associated ingress becomes unavailable. A records to the unavailable hosts will remain on the ingress and in the DNS entry. [#18932]
Global DNS can’t be launched by a regular user; only admin can create it and then add a user to global dns as a member [19596]
Deactivating or removing the creator of a cluster will prevent the monitoring feature from deploying successfully. In the case of the “local” cluster, this is the default admin account. [#18787]
The monitoring feature reserves resources such as CPU and memory. It will fail to deploy if the cluster does not have sufficient resources available for reservation. See our documentation for the recommended resource reservations you should make when enabling monitoring. [#19649]
Catalog app answers can get out of sync when switch between the UI and yaml forms[19060]

Versions

Images

rancher/rancher:v2.2.2
rancher/rancher-agent:v2.2.2

Tools

cli - v2.2.0
rke - v0.2.2

Kubernetes

1.11.9
1.12.7
1.13.5 (default)
1.14.1 (experimental)

Upgrades and Rollbacks

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

If you are currently using the RKE add-on install method, see Migrating from a RKE add-on install for details on how to move to using a helm chart.

Any upgrade from a version prior to v2.0.3, when scaling up workloads, new pods will be created [#14136] - In order to update scheduling rules for workloads [#13527], a new field was added to all workloads on update, which will cause any pods in workloads from previous versions to re-create.

Note: 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. In the case of rolling back using a Rancher single-node install, you must specify the exact version you want to change the Rancher version to, rather than using the default :latest tag.

Note: If you had the helm stable catalog enabled in v2.0.0, we’ve updated the catalog to start pointing directly to the Kubernetes helm repo instead of an internal repo. Please delete the custom catalog that is now showing up and re-enable the helm stable. [#13582]