Chapter 2. Updating clusters overview
You can update an OpenShift Container Platform 4 cluster with a single operation by using the web console or the OpenShift CLI (oc).
2.1. Understanding the OpenShift Update Service
Understanding the OpenShift Update Service: For clusters with internet accessibility, Red Hat provides over-the-air updates through an OpenShift Container Platform update service as a hosted service located behind public APIs. For more information, see the following:
2.2. Installing and configuring the OpenShift Update Service
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:
2.3. Understanding upgrade channels and releases
Upgrade channels and releases: Upgrade channels allow you to choose an upgrade strategy. Upgrade channels are specific to a minor version of OpenShift Container Platform. 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 OpenShift Container Platform always installs that minor version. For more information, see the following:
2.4. Updating a cluster using the web console
Updating a cluster using the web console: You can update an OpenShift Container Platform 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.
2.5. Updating a cluster using the CLI
Updating a cluster using the CLI: You can update an OpenShift Container Platform 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.
2.6. Performing a canary rollout update
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:
2.7. Updating a cluster that includes RHEL compute machines
Updating a cluster that includes RHEL compute machines: If your cluster contains Red Hat Enterprise Linux (RHEL) machines, you must perform additional steps to update those machines. You can perform the following procedures:
2.8. Updating a restricted network cluster
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.
- Preparing your mirror host
- Configuring credentials that allow images to be mirrored
- Mirroring the OpenShift Container Platform image repository
- Creating the image signature config map
- Updating the restricted network cluster
- Configuring image registry repository mirroring
- Widening the scope of the mirror image catalog to reduce the frequency of cluster node reboots