Updating clusters, worker nodes, and cluster components
Keep your cluster secure and supported by updating the master, worker nodes, and cluster components in the correct order. Updating out of sequence can cause version skew failures or unexpected downtime.
For information about which updates IBM applies and which updates you apply, see Your responsibilities with using Red Hat OpenShift on IBM Cloud.
Update checklist
Complete updates in the following order. Each step links to the topic that contains the procedure.
Not sure which infrastructure type you have? In the IBM Cloud console, click your cluster and check the Infrastructure field on the Overview tab. It shows Classic, VPC, or Satellite.
- Check your cluster version, worker node version, and worker node operating system.
- Prepare to update your cluster. Review version changes, back up, and check add-ons, plug-ins, and permissions.
- Update the cluster master.
- Update your worker nodes. The topic to use depends on your infrastructure type.
- Update cluster components and managed add-ons, such as Fluentd and Ingress ALBs if you manage them manually.
Some versions require add-on updates at a different point in the sequence. Always check the version information page for your target version for Update before master and Update after master actions.
To update Satellite worker nodes, follow the steps in Updating hosts that are assigned as worker nodes.
Other update tasks
You can also complete the following update-related tasks.
To change the flavor (machine type) of the worker nodes in a worker pool, see Updating flavors (machine types). To learn which worker nodes are removed first when a worker pool shrinks, see How worker pools are scaled down.
To change the operating system of the worker nodes in a worker pool, see Migrating VPC worker nodes to RHCOS or Migrating to Red Hat Enterprise Linux 9.
Troubleshooting update problems
If an update does not complete or a cluster or worker node enters an unexpected state, start with the following topics.
To check the health of the master, see Reviewing master health. If a webhook blocks the update, see Troubleshooting webhook errors. If replacing a worker node does not create a new worker node, see Why doesn't replacing a worker node create a worker node?. If duplicate nodes appear after an update, see After a worker node updates or reloads, why do duplicate nodes and pods appear?.
To check the status of a master update that is in progress, see Viewing cluster upgrade status. If the OpenShift console shows that the cluster version is not up to date, see Why does OpenShift show the cluster version is not up to date?.
For the states that your cluster and worker nodes can show, see Cluster states and statuses and Worker node states.
Next steps
After you update, rotate your CA certificates if you haven't recently, and review the worker node states to confirm that your worker nodes are healthy.