mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
fixing pr link errors fixing pr link error fixing pr hcp link error fixing pr rosa link fing dup in add recources in assembly hcp upgrading applying review comments applying review comment applying review comm fix table fix tables fix tabl fix tab fix ta
31 lines
2.7 KiB
Plaintext
31 lines
2.7 KiB
Plaintext
:_mod-docs-content-type: CONCEPT
|
|
[id="rosa-upgrade-options_{context}"]
|
|
= Upgrade options for {product-title} clusters
|
|
|
|
In OpenShift, upgrading means provisioning a new component with updated software and using it to replace an existing component that has outdated software.
|
|
|
|
You can control the impact of upgrades to your workload by controlling which parts of the cluster are upgraded, for example:
|
|
|
|
Upgrade only the hosted control plane:: This initiates upgrade of the hosted control plane. It does not impact your worker nodes.
|
|
|
|
Upgrade nodes in a machine pool:: {product-title} machine pool upgrades are designed to fully replace each node in a machine pool during the upgrade process. This provides additional security and stability benefits over performing an in-place upgrade. Upgrading the nodes in a machine pool initiates a rolling replacement of nodes in the specified machine pool, and temporarily impacts the worker nodes on that machine pool. You can also upgrade multiple machine pools concurrently.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
You cannot upgrade the hosted control plane at the same time as any machine pool upgrade. You will need to upgrade the hosted control plane first, and then upgrade machine pools.
|
|
====
|
|
|
|
[IMPORTANT]
|
|
====
|
|
To maintain compatibility between nodes in the cluster, nodes in machine pools cannot use a newer version than the hosted control plane. This means that the hosted control plane should always be upgraded to a given version before any machine pools are upgraded to the same version.
|
|
====
|
|
|
|
You can further control the time required for a machine pool upgrade, and the impact of an upgrade to your workload, by editing the `--max-surge` and `--max-unavailable` values for each machine pool. These options control the number of nodes that can be upgraded simultaneously on a machine pool, and whether an upgrade provisions excess nodes or makes some existing nodes unavailable or both, for example:
|
|
|
|
* **To prioritize high workload availability**, you can provision excess nodes instead of making existing nodes unavailable by setting a higher value for `--max-surge` and setting `--max-unavailable` to `0`.
|
|
* **To prioritize lower infrastructure costs**, you can make some existing nodes unavailable and avoid provisioning excess nodes by setting a higher value for `--max-unavailable` and setting `--max-surge` to `0`.
|
|
* **To prioritize upgrade speed by upgrading multiple nodes simultaneously**, you can provision excess nodes and allow some existing nodes to be made unavailable by configuring moderate values for both `--max-surge` and `--max-unavailable`.
|
|
|
|
For more information about these parameters and their usage, see the _ROSA CLI reference_ for `rosa edit machinepool`.
|
|
|
|
//Additional resources included in assembly. |