Merge pull request #44010 from xenolinux/49-3023

OSDOCS-3023:  Overview page for the book 'updating clusters'

Author: gaurav-nelson

_topic_maps/_topic_map.yml

@@ -492,6 +492,8 @@ Name: Updating clusters
 Dir: updating
 Distros: openshift-origin,openshift-enterprise
 Topics:
+- Name: Updating clusters overview
+  File: index  
 - Name: Understanding OpenShift updates
   File: understanding-openshift-updates
 - Name: Understanding upgrade channels

updating/index.adoc

@@ -0,0 +1,94 @@
+:_content-type: ASSEMBLY
+[id="updating-clusters-overview"]
+= Updating clusters overview
+include::_attributes/common-attributes.adoc[]
+:context: updating-clusters-overview
+
+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.
+
+[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.
+
+["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#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]
+* xref:../updating/understanding-upgrade-channels-release.adoc#restricted-network-clusters_understanding-upgrade-channels-releases[Understanding restricted network clusters]
+* xref:../updating/understanding-upgrade-channels-release.adoc#switching-between-channels_understanding-upgrade-channels-releases[Switching between channels]
+* xref:../updating/understanding-upgrade-channels-release.adoc#conditional-updates-overview_understanding-upgrade-channels-releases[Understanding conditional updates]
+
+["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.8 to 4.9, and then to 4.10. 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#updating-eus-to-eus-upgrade_eus-to-eus-upgrade[Updating EUS-to-EUS]
+
+["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#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]
+* xref:../updating/updating-cluster-within-minor.adoc#update-single-node-openshift_updating-cluster-within-minor[About updating single node OpenShift Container Platform]
+* xref:../updating/updating-cluster-within-minor.adoc#update-upgrading-web_updating-cluster-within-minor[Updating a cluster by using the web console]
+* 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]
+
+["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:
+
+* 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 single node OpenShift Container Platform]
+* xref:../updating/updating-cluster-cli.adoc#update-upgrading-cli_updating-cluster-cli[Updating a cluster by using the CLI]
+* xref:../updating/updating-cluster-cli.adoc#update-changing-update-server-cli_updating-cluster-cli[Changing the update server by using the CLI]
+
+["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-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]
+* xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-update_update-using-custom-machine-config-pools[Performing the cluster update]
+* xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-unpause_update-using-custom-machine-config-pools[Unpausing the machine configuration pools]
+* xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools-mcp-remove_update-using-custom-machine-config-pools[Moving a node to the original machine configuration pool]
+
+["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#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]
+
+["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-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]
+* xref:../updating/updating-restricted-network-cluster.adoc#update-mirror-repository_updating-restricted-network-cluster[Mirroring the {product-title} image repository]
+* xref:../updating/updating-restricted-network-cluster.adoc#update-restricted_updating-restricted-network-cluster[Updating the restricted network cluster]
+* xref:../updating/updating-restricted-network-cluster.adoc#images-configuration-registry-mirror_updating-restricted-network-cluster[Configuring image registry repository mirroring]
+* xref:../updating/updating-restricted-network-cluster.adoc#generating-icsp-object-scoped-to-a-registry_updating-restricted-network-cluster[Widening the scope of the mirror image catalog to reduce the frequency of cluster node reboots]
+* xref:../updating/updating-restricted-network-cluster.adoc#update-service-install[Installing the OpenShift Update Service Operator]
+* xref:../updating/updating-restricted-network-cluster.adoc#update-service-create-service[Creating an OpenShift Update Service application]
+* xref:../updating/updating-restricted-network-cluster.adoc#update-service-delete-service[Deleting an OpenShift Update Service application]
+* xref:../updating/updating-restricted-network-cluster.adoc#update-service-uninstall[Uninstalling the OpenShift Update Service Operator]
+
+["updating-clusters-overview-vsphere-updating-hardware"]
+== Updating hardware on nodes running on 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-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]
+
+[IMPORTANT]
+====
+Using hardware version 13 for your cluster nodes running on vSphere is now deprecated. This version is still fully supported, but support will be removed in a future version of {product-title}. Hardware version 15 is now the default for vSphere virtual machines in {product-title}.
+====