Install
Install
Abstract
Chapter 1. Installing
Learn how to install and uninstall Red Hat Advanced Cluster Management for Kubernetes. Before you install Red Hat Advanced Cluster Management for Kubernetes, review the required hardware and system configuration for each product.
You can install the Red Hat Advanced Cluster Management for Kubernetes online on Linux with a supported version of Red Hat OpenShift Container Platform.
High-level installation flow:
- You must have a supported version of OpenShift Container Platform installed and configured.
- Install the Operator for Red Hat Advanced Cluster Management for Kubernetes from the catalog.
After you install and deploy the Red Hat Advanced Cluster Management for Kubernetes, view the documentation on how to use the features.
Installing Red Hat Advanced Cluster Management for Kubernetes sets up a multi-node cluster production environment. You can install Red Hat Advanced Cluster Management for Kubernetes in either standard or high availability configurations.
1.1. Requirements and recommendations
Before you install Red Hat Advanced Cluster Management for Kubernetes, review the system configuration requirements and settings.
1.1.1. Supported operating systems and platforms
See the following table for supported operating systems:
| Platform | Operating system | OpenShift Container Platform version |
|---|---|---|
| Linux x86_64 | Red Hat Enterprise Linux 7.6, or later | Refer to the Red Hat Advanced Cluster Management 2.0 Support matrix for the most current list of supported OpenShift Container Platform platforms. |
1.1.2. Supported browsers
You can access the Red Hat Advanced Cluster Management for Kubernetes console from Mozilla Firefox, Google Chrome, Microsoft™ Edge, and Safari. See the following versions that are tested and supported:
| Platform | Supported browsers |
|---|---|
| Microsoft Windows | Microsoft Edge - latest, Mozilla Firefox - 74.0 or later, Google Chrome - Version 80.0 and later |
| Linux | Mozilla Firefox - 74.0 and later, Google Chrome - Version 80.0 and later |
| macOS | Mozilla Firefox - 74.0 and later, Google Chrome - Version 80.0 and later, Safari - 13.0.5 and later |
See the Red Hat Advanced Cluster Management for Kubernetes 2.0 Support matrix for additional information.
1.2. Network configuration
Configure your network settings to allow the following connections:
Hub cluster:
- Outbound connectivity to cloud provider’s API.
-
Outbound connectivity to the Kubernetes API server of the provisioned
ManagedClusteron port 6443. - Outbound connectivity from the Hub to the channel source, including Github, Object Store, and Helm repository. This is only required when you are using application lifecycle to connect to these sources.
-
Outbound and inbound connectivity to the
WorkManagerservice route on the ManagedCluster on port 443. -
Inbound connectivity to the hub cluster’s kube API server from the
ManagedClusteron port 6443. - Inbound connectivity for post-commit hook from GitHub to the Hub. This setting is only required when you use certain application management functions.
Managed cluster:
- Inbound connectivity to the Kubernetes API server from the hub cluster on port 6443.
-
Inbound connectivity to
WorkManagerservice endpoint from the hub cluster on port 443. - Outbound connectivity to the hub cluster’s Kubernetes API server on port 6443.
- Outbound connectivity from the Hub to channel source, including Github, Object Store, and Helm repository. This is only required when you are using application lifecycle to connect to these sources.
1.3. Performance and scalability
Red Hat Advanced Cluster Management for Kubernetes is tested to determine certain scalability and performance data. The major areas that are tested are cluster scalability and search performance.
You can use this information to help you plan your environment.
Note: Data is based on the results from a lab environment at the time of testing. Your results might vary, depending on your environment, network speed, and changes to the product.
1.3.1. Maximum number of managed clusters
The maximum number of clusters that Red Hat Advanced Cluster Management can manage varies based on several factors, including:
- Number of resources in the cluster, which depends on factors like the number of policies and applications that are deployed.
- Configuration of the hub cluster, such as how many pods are used for scaling.
The following table shows the configuration information for some of the clusters on the Amazon Web Services cloud platform that were used during testing:
| Node | Flavor | vCPU | RAM (GiB) | Disk type | Disk size (GiB)/IOS | Count | Region |
|---|---|---|---|---|---|---|---|
| Master | m5.2xlarge | 8 | 32 | gp2 | 100 | 3 | us-east-1 |
| Worker | m5.2xlarge | 8 | 32 | gp2 | 100 | 3/5 | us-east-1 |
1.3.2. Search scalability
The scalability of the Search component depends on the performance of the data store. The following variables are important when analyzing the search performance:
- Physical memory
- Write throughput (Cache recovery time)
- Query execution time
1.3.2.1. Physical memory
Search keeps the data in-memory to achieve fast response times. The memory required is proportional to the number of Kubernetes resources and their relationships in the cluster.
| Clusters | Kubernetes resources | Relationships | Observed size (with simulated data) |
|---|---|---|---|
| 1 medium | 5000 | 9500 | 50 MB |
| 5 medium | 25,000 | 75,000 | 120 MB |
| 15 medium | 75,000 | 20,0000 | 263 MB |
| 30 medium | 150,000 | 450,000 | 492 MB |
| 50 medium | 250,000 | 750,000 | 878 MB |
By default, the datastore is deployed with a memory limit of 1 GB. If you are managing larger clusters, you might need to increase this limit by editing the deployment named search-prod-xxxxx-redisgraph in the hub cluster namespace.
1.3.2.2. Write throughput (cache recovery time)
Most clusters in steady state generate a small number of resource updates. The highest rate of updates happen when the data in RedisGraph is cleared, which causes the remote collectors to synchronize their full state around the same time.
| Clusters | Kubernetes resources | Relationships | Average recovery time from simulation |
|---|---|---|---|
| 1 medium | 5000 | 9500 | less than 2 seconds |
| 5 medium | 25,000 | 75,000 | less than 15 seconds |
| 15 medium | 75,000 | 200,000 | 2 minutes and 40 seconds |
| 30 medium | 150,000 | 450,000 | 5-8 minutes |
Remember: Times might increase for clusters that have a slow network connection to the hub.
1.3.2.3. Query execution considerations
There are some things that can affect the time that it takes to run and return results from a query. Consider the following items when planning and configuring your environment:
- Searching for a keyword is not efficient.
- The first search takes longer than later searches because it takes additional time to gather the user’s access rules.
- The length of time to complete a request is proportional to the number of namespaces and resources the user is authorized to access.
- The worst performance is observed for a request by a non-administrator user with access to all of the namespaces, or all of the managed clusters.
1.4. Preparing your hub cluster for installation
Before you install Red Hat Advanced Cluster Management for Kubernetes, review the following installation requirements and recommendations for setting up your hub cluster:
1.4.1. Confirm your Red Hat OpenShift Container Platform installation
- You must have a supported Red Hat OpenShift Container Platform version, including the registry and storage services, installed and working in your cluster. For more information about installing the Red Hat OpenShift Container Platform, see the Red Hat OpenShift documentation.
- For Red Hat OpenShift Container Platform version 4.3, see Red Hat OpenShift Container Platform 4.3 Documentation.
To ensure that the Red Hat OpenShift Container Platform cluster is set up correctly, access the Red Hat OpenShift Container Platform web console.
Run the
kubectl -n openshift-console get routecommand to access the Red Hat OpenShift Container Platform web console. See the following example output:openshift-console console console-openshift-console.apps.new-coral.purple-chesterfield.com console https reencrypt/Redirect None
The console URL in this example is
https:// console-openshift-console.apps.new-coral.purple-chesterfield.com. Open the URL in your browser and check the result. If the console URL displaysconsole-openshift-console.router.default.svc.cluster.local, setopenshift_master_default_subdomainwhen you install the Red Hat OpenShift Container Platform.
See Sizing your cluster to learn about setting up capacity for your hub cluster.
1.4.2. Sizing your cluster
Each Red Hat Advanced Cluster Management for Kubernetes cluster has its own characteristics. There are guidelines that provide sample deployment sizes. The recommendations are classified by size and purpose.
Red Hat Advanced Cluster Management applies the following 3 dimensions for sizing and placement of supporting services:
- Availability Zones that isolate potential fault domains across the cluster. Typical clusters should have roughly equivalent worker node capacity in 3 or more availability zones.
- vCPU reservations and limits establish vCPU capacity on a worker node to assign to a container. A vCPU is equivalent to a Kubernetes compute unit. For more information, see Kubernetes Meaning of CPU.
- Memory reservations and limits establish memory capacity on a worker node to assign to a container. Reservations establish a lower bound of CPU or memory and limits establish an upper bound.
The persistent data managed by the product is stored in the cluster-wide etcd data store. Best practices for OpenShift recommend distributing the master nodes of the cluster across three (3) availability zones, as well.
Note: The requirements that are listed are not minimum requirements.
1.4.2.1. Red Hat Advanced Cluster Management for Kubernetes environment
| OpenShift node role | Availability zones | Data stores | Total reserved memory (lower bound) | Total reserved CPU (lower bound) |
|---|---|---|---|---|
| master | 3 | etcd x 3 | Per OpenShift sizing guidelines | Per OpenShift sizing guidelines |
| worker | 3 | redisgraph or redis x 1 | 12 Gi | 6 CPU |
In addition to Red Hat Advanced Cluster Management for Kubernetes, the OpenShift cluster runs additional services to support cluster features. The following list contains the recommended sizes of the three (3) installed nodes that are distributed across availability zones for each of the providers.
Creating an OpenShift cluster on Amazon Web Services
See the Amazon Web Services information in the Red Hat OpenShift product documentation for more information. Also learn more about machine types.
- Node Count: 3
- Availability zones: 3
Instance size: m5.xlarge
- vCPU: 4
- Memory: 16 GB
- Storage size: 120 GB
Creating an OpenShift cluster on Google Cloud Platform
See the Google Cloud Platform product documentation for more information about quotas. Also learn more about machine types.
- Node Count: 3
- Availability zones: 3
Instance size: N1-standard-4 (0.95—6.5 GB)
- vCPU: 4
- Memory: 15 GB
- Storage size: 120 GB
Creating an OpenShift cluster on Microsoft Azure See the following product documentation for more details.
- Node Count: 3
- Availability zones: 3
Instance size: Standard_D2s_v3
- vCPU: 4
- Memory: 16 GB
- Storage size: 120 GB
Creating an OpenShift cluster on bare metal See the following product documentation for more details.
- CPU: 6 (minimum)
- Memory: 16 GB (minimum)
- Storage size: 50 GB (minimum)
1.5. Installing while connected online
Red Hat Advanced Cluster Management for Kubernetes is installed using an operator that deploys all of the required components.
1.5.1. Prerequisites
You must meet the following requirements before you install Red Hat Advanced Cluster Management:
- Your Red Hat OpenShift Container Platform must have access to the Red Hat Advanced Cluster Management operator in the OperatorHub catalog.
- OpenShift Container Platform version 4.3, or later, must be deployed in your environment, and you must be logged into it with the CLI. See the OpenShift version 4.3 documentation or OpenShift version 4.4 documentation.
-
Your OpenShift Container Platform command line interface (CLI) must be version 4.3, or later, and configured to run
occommands. See Getting started with the CLI for information about installing and configuring the OpenShift Container Platform CLI. - Your Red Hat OpenShift Container Platform permissions must allow you to create a namespace.
- You must have an Internet connection to access the dependencies for the operator.
1.5.2. Installing Red Hat Advanced Cluster Management from the CLI
Create a hub cluster namespace where the operator requirements are contained:
oc create namespace <namespace>
Replace namespace with a name for your hub cluster namespace. Note: The value for namespace might be referred to as Project in the OpenShift Container Platform environment.
Important: The Red Hat Advanced Cluster Management operator must be installed in its own namespace. A
ServiceAccountwith aClusterRoleBindingautomatically gives cluster administrator privileges to Red Hat Advanced Cluster Management and to any ID with access to the namespace. For security, make sure that anyone who is given access to this namespace already has cluster-administrator access.Switch your project namespace to the one that you created:
oc project <namespace>
Replace namespace with the name of the hub cluster namespace that you created in step 1.
If you plan to import Kubernetes clusters that were not created by OpenShift Container Platform or Red Hat Advanced Cluster Management, generate a secret that contains your OpenShift Container Platform pull secret information to access the entitled content from the distribution registry. The secret requirements for OpenShift Container Platform clusters are automatically resolved by OpenShift Container Platform and Red Hat Advanced Cluster Management, so you do not have to create the secret if you are not importing other types of Kubernetes clusters to be managed. Important: These secrets are namespace-specific, so make sure that you are in the namespace that you created in step 1.
- Download your OpenShift Container Platform pull secret file from cloud.redhat.com/openshift/install/pull-secret by selecting Download pull secret. Your OpenShift Container Platform pull secret is associated with your Red Hat Customer Portal ID, and is the same across all Kubernetes providers.
Run the following command to create your secret:
oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
Replace secret with the name of the secret that you want to create. Replace namespace with your project namespace. Replace path-to-pull-secret with the path to your OpenShift Container Platform pull secret that you downloaded.
Create an operator group. Each namespace can have only one operator group.
Create a
.yamlfile that defines the operator group. Your file should look similar to the following example:apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <default> spec: targetNamespaces: - <namespace>
Replace default with the name of your operator group. Replace namespace with the name of your project namespace.
Apply the file that you created to define the operator group:
oc apply -f local/<operator-group>.yaml
Replace operator-group with the name of the operator group
.yamlfile that you created.
Apply the subscription.
Create a
.yamlfile that defines the subscription. Your file should look similar to the following example:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: acm-operator-subscription spec: sourceNamespace: openshift-marketplace source: redhat-operators channel: release-2.0 installPlanApproval: Automatic name: advanced-cluster-management
Apply the subscription:
oc apply -f local/<subscription>.yaml
Replace subscription with the name of the subscription file that you created.
Create the MultiClusterHub custom resource by creating a
.yamlfile that defines the custom resource. Your file should look similar to the following example:apiVersion: operator.open-cluster-management.io/v1 kind: MultiClusterHub metadata: name: multiclusterhub namespace: <namespace> spec: imagePullSecret: <secret>
Replace namespace with your project namespace. Replace secret with the name of the secret that you created.
If this step fails with the following error, the resources are still being created and applied:
error: unable to recognize "./mch.yaml": no matches for kind "MultiClusterHub" in version "operator.open-cluster-management.io/v1"
Run the command again in a few minutes when the resources are created.
View the list of routes after about 10 minutes to find your route:
oc get routes
If you are reinstalling Red Hat Advanced Cluster Management and the pods do not start, see Troubleshooting reinstallation failure for steps to work around this problem.
1.5.3. Installing Red Hat Advanced Cluster Management from the console
Create a hub cluster namespace for the operator requirements:
- In the OpenShift Container Platform console navigation, select Administration > Namespaces.
- Select Create Namespace.
- Provide a name for your namespace. This is the namespace that you use throughout the installation process. Note: The value for namespace might be referred to as Project in the OpenShift Container Platform environment.
Select Create.
Important: The Red Hat Advanced Cluster Management operator must be installed in its own namespace. A
ServiceAccountwith aClusterRoleBindingautomatically gives cluster administrator privileges to Red Hat Advanced Cluster Management and to any ID with access to the namespace. For security, make sure that anyone who is given access to this namespace already has cluster-administrator access.
Switch your project namespace to the one that you created in step 1. This ensures that the steps are completed in the correct namespace. Some resources are namespace-specific.
- In the OpenShift Container Platform console navigation, select Administration > Namespaces.
- Select the namespace that you created in step 1 from the list.
If you plan to import Kubernetes clusters that were not created by OpenShift Container Platform or Red Hat Advanced Cluster Management, creater a secret that contains your OpenShift Container Platform pull secret to access the entitled content from the distribution registry. Secret requirements for OpenShift Container Platform clusters are automatically resolved by OpenShift Container Platform and Red Hat Advanced Cluster Management, so you do not have to create the secret if you are not importing other types of Kubernetes clusters to be managed.
- Copy your OpenShift Container Platform pull secret from cloud.redhat.com/openshift/install/pull-secret by selecting Copy pull secret. You will use the content of this pull secret in a step later in this procedure. Your OpenShift Container Platform pull secret is associated with your Red Hat Customer Portal ID, and is the same across all Kubernetes providers.
- In the OpenShift Container Platform console navigation, select Workloads > Secrets.
- Select Create > Image Pull Secret.
- Enter a name for your secret.
- Select Upload Configuration File as the authentication type.
-
In the Configuration file field, paste the pull secret that you copied from
cloud.redhat.com. - Select Create to create the secret.
Subscribe to the operator. Note: The value for namespace might be referred to as Project in the OpenShift Container Platform environment.
- In the OpenShift Container Platform console navigation, select Operators > OperatorHub.
- Select Red Hat Advanced Cluster Management. Tip: You can filter on the Integration & Delivery category to narrow the choices.
- Select Install.
- Update the values, if necessary.
- Select Subscribe.
Create the MultiClusterHub custom resource.
- In the OpenShift Container Platform console navigation, select Installed Operators > Advanced Cluster Management for Kubernetes.
- Select the MultiClusterHub tab.
- Select Create MultiClusterHub.
Update the values, according to your needs. Tip: You can edit the values in the
YAMLfile by selecting YAML View. Some of the values are only available in theYAMLview. The following example shows some sample data in theYAMLview:apiVersion: operator.open-cluster-management.io/v1 kind: MultiClusterHub metadata: namespace: <namespace> name: multiclusterhub spec: {}Add the secret that you created to the imagePullSecret field on the console. In the YAML View, confirm that the namespace is your project namespace.
Select Create to initialize the custom resource. It can take up to 10 minutes for the hub to build and start.
After the hub is created, the status for the operator is Running on the Installed Operators page.
Access the console for the hub.
- In the OpenShift Container Platform console navigation, select Networking > Routes.
- View the URL for your hub in the list, and navigate to it to access the console for your hub.
If you are reinstalling Red Hat Advanced Cluster Management and the pods do not start, see Troubleshooting reinstallation failure for steps to work around this problem.
1.6. Install on disconnected networks
You might need to install Red Hat Advanced Cluster Management for Kubernetes on Red Hat OpenShift Clusters that are not connected to the Internet. The procedure to install on a disconnected hub requires some of the same steps as the connected installation. You must download copies of the packages in order to access them during the installation, rather than accessing them directly from the network during the installation.
Note: Most out-of-the-box policies are functional in a disconnected install, except the image vulnerability policy (ImageManifestVulnPolicy).
1.6.1. Prerequisites for a disconnected installation
You must meet the following requirements before you install Red Hat Advanced Cluster Management for Kubernetes:
- Red Hat OpenShift Container Platform version 4.3, or later, must be deployed in your environment, and you must be logged into it with the command line interface (CLI). Note: For managing bare metal clusters, you must have OpenShift Container Platform version 4.5, or later. See the OpenShift version 4.3 documentation, OpenShift version 4.4 documentation, or OpenShift version 4.5 documentation.
-
Your Red Hat OpenShift Container Platform CLI must be version 4.3, or later, and configured to run
occommands. - Your Red Hat OpenShift Container Platform permissions must allow you to create a namespace.
- You must have a workstation with Internet connection to download the dependencies for the operator.
1.6.2. Installing Red Hat Advanced Cluster Management for Kubernetes in a disconnected environment
Follow these steps to install Advanced Cluster Management for Kubernetes in a disconnected environment:
Create a mirror registry, if necessary.
If you do not already have a mirror registry, create one by completing the procedure in the Creating a mirror registry for installation in a restricted network topic of the Red Hat OpenShift Container Platform documentation.
If you already have a mirror registry, you can configure and use your existing one.
Bare metal only: Provide the certificate information for the disconnected registry in your
install-config.yamlfile. To access the image in a protected disconnected registry, you must provide the certificate information so Red Hat Advanced Cluster Management can access the registry.- Copy the certificate information from the registry.
-
Open the
install-config.yamlfile in an editor. -
Find the entry for
additionalTrustBundle: |. Add the certificate information after the
additionalTrustBundleline. The resulting content should look similar to the following example:additionalTrustBundle: | -----BEGIN CERTIFICATE----- certificate_content -----END CERTIFICATE----- sshKey: >-
-
Save the
install-config.yamlfile.
Enable the disconnected Operator Lifecycle Manager (OLM) Red Hat Operators and Community Operators.
Advanced Cluster Management for Kubernetes is included in the OLM Red Hat Operator catalog.
- Configure the disconnected OLM for the Red Hat Operator catalog. Follow the steps in the Using Operator Lifecycle Manager on restricted networks topic of the Red Hat OpenShift Container Platform documentation.
- Now that you have the image in the disconnected OLM, continue to install Advanced Cluster Management for Kubernetes from the OLM catalog. See the steps in Installing while connected online for the required steps.
1.7. Migrating from a previous version
1.7.1. Migrating from 1.0 to 2.0
Upgrade from version 1.0 of Red Hat Advanced Cluster Management to version 2.0 is not supported. To migrate from the technology preview version of Red Hat Advanced Cluster Management for Kubernetes 1.0 to the generally available version 2.0, you must manually remove version 1.0 and install version 2.0. Complete the following steps to migrate from version 1.0 to version 2.0:
- Detach each of your managed clusters from your Red Hat Advanced Cluster Management hub cluster before unistalling the hub cluster. See Removing a cluster from management for instructions that explain how to remove the managed clusters.
- Uninstall Red Hat Advanced Cluster Management version 1.0 by completing the procedure in Uninstalling.
Install Red Hat Advanced Cluster Management version 2.0 by completing the procedure in Installing while connected online.
When you install version 2.0, select automatic upgrade to enable automatic upgrades for future versions within the same major release. If you prefer to run manual updates, you can select manual upgrade. See the following definitions of the options:
- Automatic upgrade: If you select automatic upgrades when you install the Red Hat Advanced Cluster Management operator, the Operator Lifecycle Manager automatically upgrades the version when a compatible upgrade is available. This method ensures that you always have the latest version of the operator with the latest fixes.
Manual upgrade: If you select manual upgrades when you install the Red Hat Advanced Cluster Management operator, the cluster administrator determines when an upgrade occurs.
When a compatible upgrade is available, the Operator Lifecycle Manager creates a request to upgrade. A cluster administrator must approve the request to upgrade the version.
- Import the clusters to the version 2.0 hub cluster by completing the procedure in Importing a target managed cluster to the hub cluster.
For more information about upgrading your operator, see Adding operators to a cluster.
1.8. Upgrading by using the operator
You control your Red Hat Advanced Cluster Management for Kubernetes upgrades by using the operator subscription settings in the Red Hat OpenShift Container Platform console. When you initially deploy Red Hat Advanced Cluster Management by using the operator, you make the following selections:
- Channel - Corresponds to the version of the product that you are installing. The initial channel setting is often the most current channel that was available at the time of installation.
-
Approval - Specifies whether approval is required for updates within the channel, or if they are done automatically. If set to
Automatic, then minor release updates in the selected channel are deployed without administrator intervention. If theManualsetting is selected, then each update to the minor release within the channel requires an administrator to approve the update.
You also use those settings when you upgrade Red Hat Advanced Cluster Management by using the operator.
Required access: OpenShift Container Platform administrator
Complete the following steps to upgrade your operator:
- Log in to your OpenShift Container Platform operator hub.
- In the OpenShift Container Platform navigation, select Operators > Installed operators.
- Select the Red Hat Advanced Cluster Management for Kubernetes operator.
- Select the Subscription tab to edit the subscription settings.
Ensure that the Upgrade Status is labeled Up to date. This status indicates that the operator is at the latest level that is available in the selected channel. If the Upgrade Status indicates that there is an upgrade pending, complete the following steps to update it to the latest minor release that is available in the channel:
- Click the Manual setting in the Approval field to edit the value.
- Select Automatic to enable automatic updates.
- Select Save to commit your change.
- Wait for the automatic updates to be applied to the operator. The updates automatically add the required updates to the latest version in the selected channel. When all of the updates are complete, the Upgrade Status field indicates Up to date.
- Now that the Upgrade Status is Up to date, click the value in the Channel field to edit it.
Select the channel for the next available feature release. You cannot skip channels when upgrading.
Important: You cannot revert back to an earlier version after upgrading to a later version in the channel selection. You must uninstall the operator and reinstall an earlier version to use it.
- Select Save to save your changes.
- Wait for the automatic upgrade to complete. After the upgrade to the next feature release completes, the updates to the latest patch releases within the channel are deployed.
- If you have to upgrade to a later feature release, repeat steps 7-9 until your operator is at the latest level of the desired channel. Make sure that all of the patch releases are deployed for your final channel.
- Optional: You can set your Approval setting to Manual, if you want your future updates within the channel to require manual approvals.
Red Hat Advanced Cluster Management is running at the latest version of the selected channel.
1.8.1. Upgrading OpenShift Container Platform
You can upgrade the version of Red Hat OpenShift Container Platform that hosts your Red Hat Advanced Cluster Management for Kubernetes hub cluster. Back up your data before initiating any cluster-wide upgrade.
During the upgrade of the OpenShift Container Platform version, the Red Hat Advanced Cluster Management web console might show brief periods when pages or data are unavailable. Indicators can include HTTP 500 (Internal Server Error), HTTP 504 (Gateway Timeout Error), or errors that data that was previously available is not available. This is a normal part of the upgrade, and no data is lost when this occurs. The availability is eventually restored.
The search index is also rebuilt during this upgrade, so any queries that are submitted during the upgrade might be incomplete.
The following table contains some noted observations from an upgrade from OpenShift Container Platform version 4.4.3 to 4.4.10:
| Elapsed time of upgrade process (minutes:seconds) | Observed change | Duration |
|---|---|---|
| 03:40 | Governance and risk console experiences HTTP 500 | Service restored within 20 seconds |
| 05:30 | AppUI experiences HTTP 504 Gateway Timeout | Service restored within 60 seconds |
| 06:05 | Cluster+Search UI experience HTTP 504 Gateway Timeout | Service restored within 20 seconds |
| 07:00 | Cluster+Search UI experience HTTP 504 Gateway Timeout | Service restored within 20 seconds |
| 07:10 | Topology+Cluster UI Display error messages within the page | Service restored within 20 seconds |
| 07:35 | HTTP 500 for most UI pages | Service restored within 60 seconds |
| 08:30 | Service restored for all pages |
1.9. Uninstalling
When you uninstall Red Hat Advanced Cluster Management for Kubernetes, there are two different levels of the process.
The first level is a custom resource removal. It is the most basic type of unistallation that removes the custom resource of the MultiClusterHub instance, but leaves other required components. This level of uninstallation is helpful if you plan another installation that uses the same settings and components of the one that you are removing. Your time to install the next version is reduced when you have all of the other components already installed.
The second level is a more complete uninstallation, except for a few items, like custom resource definitions. This adds the removal of other required components and settings to the items that are removed. When you continue with this step, it removes all of the components and subscriptions that were not removed with the custom resource removal. If you complete this level of uninstallation, you must reinstall the operator before reinstalling the custom resource.
Before you uninstall the Red Hat Advanced Cluster Management hub cluster, you must detach all of the clusters that are managed by that hub cluster. See, Troubleshooting failed uninstallation because resources exist for the work around.
1.9.1. Removing a MultiClusterHub instance by using commands
Change to your project namespace by entering the following command:
oc project <namespace>
Replace namespace with the name of your project namespace.
Enter the following command to remove the MultiClusterHub custom resource:
oc delete multiclusterhub --all
TipIf you plan to reinstall a new version and want to keep your other information, you can skip the rest of the steps in this procedure and reinstall.
Enter the following command to remove all of the related components and subscriptions:
oc delete subs --all
1.9.2. Deleting both components by using the console
When you use the Red Hat OpenShift Container Platform console to uninstall, you remove the operator. Complete the following steps to unistall by using the console:
- In the Red Hat OpenShift Container Platform console navigation, select Operators > Installed Operators > Advanced Cluster Manager for Kubernetes.
- Select the tab for Multiclusterhub operator.
- Select the Options menu for the MultiClusterHub operator.
Select Delete MultiClusterHub.
TipIf you plan to reinstall a new version and want to keep your other information, you can skip the rest of the steps in this procedure and reinstall.
- Navigate to Installed Operators.
- Remove the Red Hat Advanced Cluster Management operator by selecting the Options menu and selecting Uninstall operator.
