mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
56 lines
2.9 KiB
Plaintext
56 lines
2.9 KiB
Plaintext
|
|
// Module included in the following assemblies:
|
|
//
|
|
// * assemblies/upgrades.adoc
|
|
|
|
[id="upgrade_{context}"]
|
|
= Understanding {product-title} cluster upgrades
|
|
|
|
|
|
When upgrades are made available for your {product-title} cluster, you can upgrade to the newest version through the OpenShift Cluster Manager (OCM) or the OCM CLI. You can set your upgrade policies on existing clusters or during cluster creation, and upgrades can be scheduled to occur automatically or manually.
|
|
|
|
Red Hat Site Reliability Engineers (SRE) will provide a curated list of available versions for your {product-title} clusters. For each cluster you will be able to review the full list of available releases, as well as the corresponding release notes. OCM will enable installation of clusters at the latest supported versions, and upgrades can be canceled at any time.
|
|
|
|
You can also set a grace period for how long `PodDisruptionBudget` protected workloads are respected during upgrades. After this grace period, any workloads protected by `PodDisruptionBudget` that have not been successfully drained from a node, will be forcibly deleted.
|
|
|
|
[NOTE]
|
|
====
|
|
All Kubernetes objects and PVs in each {product-title} cluster are backed up as part of the {product-title} service. Application and application data backups are not a part of the {product-title} service. Ensure you have a backup policy in place for your applications and application data prior to scheduling upgrades.
|
|
====
|
|
|
|
[id="upgrade-automatic_{context}"]
|
|
== Automatic upgrades
|
|
|
|
Upgrades can be scheduled to occur automatically on a day and time specified by the cluster owner or administrator. Upgrades occur on a weekly basis, unless an upgrade is unavailable for that week.
|
|
|
|
[NOTE]
|
|
====
|
|
Automatic upgrade policies are optional and if they are not set, the upgrade policies default to manual.
|
|
====
|
|
|
|
[id="upgrade-manual_upgrades_{context}"]
|
|
== Manual upgrades
|
|
|
|
If you opt for manual upgrades, you are responsible for updating your cluster. If your cluster version falls too far behind, it will transition to a limited support status. For more information on OpenShift life cycle policies, see xref:../osd_policy/osd-life-cycle.adoc#osd-life-cycle[{product-title} update life cycle].
|
|
|
|
[id="upgrade-notifications_{context}"]
|
|
== Upgrade notifications
|
|
|
|
From the OCM console you can view your cluster's history from the *Overview* tab. The Upgrade states can be viewed in the service log under the *Cluster history* heading.
|
|
|
|
Every change of state also triggers an email notification to the cluster owner and subscribed users. You will receive email notifications for the following events:
|
|
|
|
* An upgrade has been scheduled.
|
|
* An upgrade has started.
|
|
* An upgrade has completed.
|
|
* An upgrade has been canceled.
|
|
|
|
[NOTE]
|
|
====
|
|
For automatic upgrades, you will also receive email notifications before the upgrade occurs based on the following cadence:
|
|
|
|
* 2 week notice
|
|
* 1 week notice
|
|
* 1 day notice
|
|
====
|