# Rancher Release v2.2.3 **URL:** \ **Category:** Announcements\ **Created:** [May 14, 2019, 4:19am UTC](https://forums.suse.com/t/rancher-release-v2-2-3/14255 "2019-05-14T04:19:13Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![alena](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/alena/32/50_2.png) [@alena](https://forums.suse.com/u/alena)\ **Post date:** [May 14, 2019, 4:19am UTC](https://forums.suse.com/t/rancher-release-v2-2-3/14255/1 "2019-05-14T04:19:13Z")
# Release v2.2.3 ## Important notes This release fixes a critical issue affecting clusters with Monitoring feature turned on. The bug manifests in an infinite redeploy of a monitoring component which results in a cluster becoming unresponsive [[20111](https://github.com/rancher/rancher/issues/20111)]. As this bug will eventually affect anyone who has turned on monitoring, we have shipped this patch release to allow the impacted users to immediately update. With this release, the following versions are now latest and stable: | Type | Rancher Version | Docker Tag | Helm Repo | Helm Chart Version | | --- | --- | --- | --- | --- | | Latest | v2.2.3 | `rancher/rancher:latest` | server-charts/latest | v2.2.3 | | Stable | v2.2.3 | `rancher/rancher:stable` | server-charts/stable | v2.2.3 | Please review our [version documentation](https://rancher.com/docs/rancher/v2.x/en/installation/server-tags/) for more details on versioning and tagging conventions. ## Features and Enhancements None ## Major Bug Fixed Since v2.2.2 - Fixed an issue when cluster monitoring was constantly redeploying and filling up etcd of a user cluster with config maps resources, eventually making cluster’s API unresponsive [[20111](https://github.com/rancher/rancher/issues/20111)] ## Other notes ### Certificate expiry on Rancher provisioned clusters 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.x, the rotation can be performed from Rancher UI, more details are [here](https://rancher.com/docs/rancher/v2.x/en/cluster-admin/certificate-rotation/). ### 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](https://rancher.com/docs/rancher/v2.x/en/installation/air-gap-high-availability/). ### Known Major Issues - Project monitoring is temporarily disabled [[19771](https://github.com/rancher/rancher/issues/19771)] - Cluster monitoring gets redeployed multiple times if system-default-registry setting is configured. The workaround is posted as a comment to the issue [[20202](https://github.com/rancher/rancher/issues/20202)] - Manual backups are deleted based on retention count configuration settings and recurring snapshot creation time is impacted by taking a manual snapshot. [[#18807](https://github.com/rancher/rancher/issues/18807)] - If snapshotting is disabled, users cannot restore from existing backups or take manual backups. [#18793](https://github.com/rancher/rancher/issues/18793) - 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](https://github.com/rancher/rancher/issues/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](https://github.com/rancher/rancher/issues/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](https://github.com/rancher/rancher/issues/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](https://rancher.com/docs/rancher/v2.x/en/cluster-admin/tools/monitoring/#resource-consumption) for the recommended resource reservations you should make when enabling monitoring. [[#19649](https://github.com/rancher/rancher/issues/19649)] - Catalog app answers can get out of sync when switch between the UI and yaml forms[[19060](https://github.com/rancher/rancher/issues/19060)] ## Versions ### Images - rancher/rancher:v2.2.3 - rancher/rancher-agent:v2.2.3 ### Tools - cli - [v2.2.0](https://github.com/rancher/cli/releases/tag/v2.2.0) - rke - [v0.2.2](https://github.com/rancher/rke/releases/tag/v0.2.2) ### Kubernetes - [1.11.9](https://github.com/rancher/hyperkube/releases/tag/v1.11.9-rancher1) - [1.12.7](https://github.com/rancher/hyperkube/releases/tag/v1.12.7-rancher1) - [1.13.5](https://github.com/rancher/hyperkube/releases/tag/v1.13.5-rancher1) (default) - [1.14.1](https://github.com/rancher/hyperkube/releases/tag/v1.14.1-rancher1) (experimental) ## Upgrades and Rollbacks Rancher supports both upgrade and rollback starting with v2.0.2. Please note the version you would like to [upgrade](https://rancher.com/docs/rancher/v2.x/en/upgrades/) or [rollback](https://rancher.com/docs/rancher/v2.x/en/backups/rollbacks/) to change the Rancher version. 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](https://rancher.com/docs/rancher/v2.x/en/installation/ha/#installation-outline). If you are currently using the RKE add-on install method, see [Migrating from a RKE add-on install](https://rancher.com/docs/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) 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](https://github.com/rancher/rancher/issues/14136)]** - In order to update scheduling rules for workloads [[#13527](https://github.com/rancher/rancher/issues/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](https://rancher.com/docs/rancher/v2.x/en/installation/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](https://github.com/rancher/rancher/issues/13582)] ---
**Author:** ![alena](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/alena/32/50_2.png) [@alena](https://forums.suse.com/u/alena)\ **Post date:** [May 14, 2019, 4:19am UTC](https://forums.suse.com/t/rancher-release-v2-2-3/14255/2 "2019-05-14T04:19:16Z")