Updating clusters overview

Understanding the OpenShift Update Service: For clusters with internet accessibility, Red Hat provides over-the-air updates through an OKD update service as a hosted service located behind public APIs. For more information, see the following:

Installing and configuring the OpenShift Update Service: Clusters with internet accessibility can access public APIs; clusters in a restricted network are unable to access public APIs for update information. To provide a similar upgrade experience in a restricted network, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment. For more information, see the following:

Upgrade channels and releases: Upgrade channels allow you to choose an upgrade strategy. Upgrade channels are specific to a minor version of OKD. Upgrade channels control only release selection and do not impact the version of the cluster that you install. The openshift-install binary file for a specific version of the OKD always installs that minor version. For more information, see the following:

Updating a cluster using the web console: You can update an OKD cluster by using the web console. The following steps update a cluster within a minor version. You can use the same instructions for updating a cluster between minor versions.

Updating a cluster using the CLI: You can update an OKD cluster within a minor version by using the OpenShift CLI (oc). The following steps update a cluster within a minor version. You can use the same instructions for updating a cluster between minor versions.

Performing a canary rollout update: By controlling rollout of an update to the worker nodes, you can ensure that mission-critical applications stay available during the whole update, even if the update process causes your applications to fail. Depending on your organizational needs, you might want to update a small subset of worker nodes, evaluate cluster and workload health over a period of time, and then update the remaining nodes. This is referred to as a canary update. Alternatively, you might also want to fit worker node updates, which often requires a host reboot, into smaller defined maintenance windows when it is not possible to take a large maintenance window to update the entire cluster at one time. You can perform the following procedures:

Updating a cluster that includes Fedora compute machines: If your cluster contains Fedora machines, you must perform additional steps to update those machines. You can perform the following procedures:

Updating a restricted network cluster: If your mirror host cannot access both the internet and the cluster, you can mirror the images to a file system that is disconnected from that environment and then bring that host or removable media across that gap. If the local container registry and the cluster are connected to the mirror host of a registry, you can directly push the release images to the local registry.