OSDICS3023: Updating clusters overview enhancement

Author: xenolinux

updating/index.adoc

@@ -6,15 +6,15 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can update a {product-title} cluster with a single operation by using the web console or the OpenShift CLI (oc) with {product-title} 4.
+You can update an {product-title} 4 cluster with a single operation by using the web console or the OpenShift CLI (`oc`).
 
 [id="updating-clusters-overview-understanding-container-platform-updates"]
 == Understanding OpenShift Container Platform updates
-xref:../updating/understanding-openshift-updates.adoc#understanding-openshift-updates[About the OpenShift Update Service]: For clusters with internet accessibility, Red{nbsp}Hat provides over-the-air updates through an {product-title} update service as a hosted service located behind public APIs.
+xref:../updating/understanding-openshift-updates.adoc#understanding-openshift-updates[About the OpenShift Update Service]: For clusters with internet access, Red Hat provides over-the-air updates by using an {product-title} update service as a hosted service located behind public APIs.
 
 [id="updating-clusters-overview-upgrade-channels-and-releases"]
 == Understanding upgrade channels and releases
-xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[Upgrade channels and releases]: Upgrade channels allow you to choose an upgrade strategy. Upgrade channels are connected to a minor version of {product-title}. 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 {product-title} always installs that version. For more information, see the following:
+xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[Upgrade channels and releases]: With upgrade channels, you can choose an upgrade strategy. Upgrade channels are specific to a minor version of {product-title}. Upgrade channels only control 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 {product-title} always installs that minor version. For more information, see the following:
 
 * xref:../updating/understanding-upgrade-channels-release.adoc#upgrade-version-paths_understanding-upgrade-channels-releases[Upgrading version paths]
 * xref:../updating/understanding-upgrade-channels-release.adoc#fast-stable-channel-strategies_understanding-upgrade-channels-releases[Understanding fast and stable channel use and strategies]
@@ -24,13 +24,13 @@ xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgra
 
 [id="updating-clusters-overview-prepare-eus-to-eus-update"]
 == Preparing to perform an EUS-to-EUS update
-xref:../updating/preparing-eus-eus-upgrade.adoc#preparing-eus-eus-upgrade[Preparing to perform an EUS-to-EUS update]: Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized. You must update from {product-title} 4.9 to 4.10, and then to 4.11. You cannot update from {product-title} 4.8 to 4.10 directly. However, if you want to update between two Extended Update Support (EUS) versions, you can do so by incurring only a single reboot of non-master hosts. For more information, see the following item:
+xref:../updating/preparing-eus-eus-upgrade.adoc#preparing-eus-eus-upgrade[Preparing to perform an EUS-to-EUS update]: Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized. You must update from {product-title} 4.9 to 4.10, and then to 4.11. You cannot update from {product-title} 4.8 to 4.10 directly. However, if you want to update between two Extended Update Support (EUS) versions, you can do so by incurring only a single reboot of non-master hosts. For more information, see the following:
 
 * xref:../updating/preparing-eus-eus-upgrade.adoc#updating-eus-to-eus-upgrade_eus-to-eus-upgrade[Updating EUS-to-EUS]
 
 [id="updating-clusters-overview-update-cluster-using-web-console"]
 == Updating a cluster using the web console
-xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[Updating a cluster within a minor version using the web console]: You can update an {product-title} cluster by using the web console. You can the update a cluster between minor versions. For more information, see the following items:
+xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-minor[Updating a cluster using the web console]: You can update an {product-title} 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.
 
 * xref:../updating/updating-cluster-within-minor.adoc#update-using-custom-machine-config-pools-canary_updating-cluster-within-minor[Performing a canary rollout update]
 * xref:../updating/updating-cluster-within-minor.adoc#machine-health-checks-pausing_updating-cluster-within-minor[Pausing a MachineHealthCheck resource]
@@ -39,8 +39,8 @@ xref:../updating/updating-cluster-within-minor.adoc#updating-cluster-within-mino
 * xref:../updating/updating-cluster-within-minor.adoc#update-changing-update-server-web_updating-cluster-within-minor[Changing the update server by using the web console]
 
 [id="updating-clusters-overview-update-cluster-using-cli"]
-== Updating a cluster within a minor version using the command-line interface (CLI)
-xref:../updating/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster within a minor version using the CLI]: You can update an {product-title} cluster by using the `oc`. You can the update a cluster between minor versions. For more information, see the following actions:
+== Updating a cluster using the CLI
+xref:../updating/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI]: You can update an {product-title} 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.
 
 * xref:../updating/updating-cluster-cli.adoc#machine-health-checks-pausing_updating-cluster-cli[Pausing a MachineHealthCheck resource]
 * xref:../updating/updating-cluster-cli.adoc#update-single-node-openshift_updating-cluster-cli[About updating {product-title} on a single-node cluster]
@@ -49,7 +49,7 @@ xref:../updating/updating-cluster-cli.adoc#updating-cluster-cli[Updating a clust
 
 [id="updating-clusters-overview-perform-canary-rollout-update"]
 == Performing a canary rollout update
-xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools[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 actions:
+xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools[Performing a canary rollout update]: By controlling the 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:
 
 * xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-mcp_update-using-custom-machine-config-pools[Creating machine configuration pools to perform a canary rollout update]
 * xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-pause_update-using-custom-machine-config-pools[Pausing the machine configuration pools]
@@ -59,15 +59,15 @@ xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-cust
 
 [id="updating-clusters-overview-update-cluster-with-rhel-compute-machines"]
 == Updating a cluster that includes {op-system-base} compute machines
-xref:../updating/updating-cluster-rhel-compute.adoc#updating-cluster-rhel-compute[Updating a cluster that includes {op-system-base} compute machines]:  You can update an {product-title} cluster. If your cluster contains {op-system-base-full} machines, you must update those machines. You can perform the following actions:
+xref:../updating/updating-cluster-rhel-compute.adoc#updating-cluster-rhel-compute[Updating a cluster that includes {op-system-base} compute machines]: If your cluster contains {op-system-base-full} machines, you must perform additional steps to update those machines. You can perform the following procedures:
 
 * xref:../updating/updating-cluster-rhel-compute.adoc#update-upgrading-web_updating-cluster-rhel-compute[Updating a cluster by using the web console]
 * xref:../updating/updating-cluster-rhel-compute.adoc#updating-cluster-rhel-compute-hooks[Optional: Adding hooks to perform Ansible tasks on {op-system-base} machines]
 * xref:../updating/updating-cluster-rhel-compute.adoc#rhel-compute-updating-minor_updating-cluster-rhel-compute[Updating {op-system-base} compute machines in your cluster]
 
 [id="updating-clusters-overview-update-restricted-network-cluster"]
 == Updating a restricted network cluster
-xref:../updating/updating-restricted-network-cluster.adoc#updating-restricted-network-cluster[Updating a restricted network cluster]: A restricted network environment is one in which your cluster nodes cannot access the internet. You can update a restricted network {product-title} cluster by using the `oc`. You can also update a restricted network {product-title} cluster by using the OpenShift Update Service. For more information, see the following items:
+xref:../updating/updating-restricted-network-cluster.adoc#updating-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. You can 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.
 
 * xref:../updating/updating-restricted-network-cluster.adoc#updating-restricted-network-mirror-host[Preparing your mirror host]
 * xref:../updating/updating-restricted-network-cluster.adoc#installation-adding-registry-pull-secret_updating-restricted-network-cluster[Configuring credentials that allow images to be mirrored]
@@ -81,9 +81,9 @@ xref:../updating/updating-restricted-network-cluster.adoc#updating-restricted-ne
 * xref:../updating/updating-restricted-network-cluster.adoc#update-service-uninstall[Uninstalling the OpenShift Update Service Operator]
 
 [id="updating-clusters-overview-vsphere-updating-hardware"]
-== Updating hardware on nodes running on vSphere
+== Updating hardware on nodes running in vSphere
 
-xref:../updating/updating-hardware-on-nodes-running-on-vsphere.adoc#updating-hardware-on-nodes-running-on-vsphere[Updating hardware on vSphere]: You must ensure that your nodes running in vSphere are running on the hardware version supported by OpenShift Container Platform. Currently, hardware version 13 or later is supported for vSphere virtual machines in a cluster. For more information, see the following information:
+xref:../updating/updating-hardware-on-nodes-running-on-vsphere.adoc#updating-hardware-on-nodes-running-on-vsphere[Updating hardware on vSphere]: You must ensure that your nodes running in vSphere are running on the hardware version supported by OpenShift Container Platform. Currently, hardware version 13 or later is supported for vSphere virtual machines in a cluster. For more information, see the following:
 
 * xref:../updating/updating-hardware-on-nodes-running-on-vsphere.adoc#updating-virtual-hardware-on-vsphere_updating-hardware-on-nodes-running-in-vsphere[Updating virtual hardware on vSphere]
 * xref:../updating/updating-hardware-on-nodes-running-on-vsphere.adoc#scheduling-virtual-hardware-update-on-vsphere_updating-hardware-on-nodes-running-in-vsphere[Scheduling an update for virtual hardware on vSphere]