--- title: Validating an installation --- # Validating an installation {#validating-an-installation} You can check the status of an OpenShift Container Platform cluster after an installation or validate boot artifacts before an installation. After you complete the procedures, you can move onto postinstallation cluster tasks. If you experience installation issues, see "Troubleshooting installations" in the *Additional resources*" section. ## Validating RHCOS live media {#rhcos-validate-live-media_validating-an-installation} For user-provisioned infrastructure installations, you can access information and use the OpenShift Container Platform installer to indirectly validate RHCOS bootimage artifacts using their SHA-256 checksums. The OpenShift Container Platform installation program contains pinned versions of RHCOS bootimages. Fully automated installations use these pinned artifacts by default. The mirror registry where you downloaded the installation program contains a `sha256sum` encrypted with the Red Hat product key. **Procedure** - Run the following command to print the metadata for any bootimage artifact: ```terminal $ openshift-install coreos print-stream-json | jq ``` where: ``: Specifies the query for the bootimage you want to obtain information on. For validation purposes, the bootimage artifact must have a generated `sha256sum`. This can include OVA, VHD, QCOW2, and others. For example, to get information on an `x86_64` architecture `iso` file for bare metal platforms, use `.architectures.x86_64.artifacts.metal.formats.iso`. ```text {title="Example output"} { "disk": { "location": "/art/storage/prod/streams//builds/rhcos--live..", "sha256": "abc2add9746eb7be82e6919ec13aad8e9eae8cf073d8da6126d7c95ea0dee962" } } ``` ## Reviewing the installation log {#reviewing-the-installation-log_validating-an-installation} The OpenShift Container Platform installation log contains a summary of the installation, including the information required to access the cluster after installation. **Prerequisites** - You have access to the installation host. **Procedure** - Review the `.openshift_install.log` log file in the installation directory on your installation host: ```terminal $ cat /.openshift_install.log ``` Cluster credentials are included at the end of the log if the installation is successful, as outlined in the following example: ```terminal ... time="2020-12-03T09:50:47Z" level=info msg="Install complete!" time="2020-12-03T09:50:47Z" level=info msg="To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'" time="2020-12-03T09:50:47Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com" time="2020-12-03T09:50:47Z" level=info msg="Login to the console with user: \"kubeadmin\", and password: \"password\"" time="2020-12-03T09:50:47Z" level=debug msg="Time elapsed per stage:" time="2020-12-03T09:50:47Z" level=debug msg=" Infrastructure: 6m45s" time="2020-12-03T09:50:47Z" level=debug msg="Bootstrap Complete: 11m30s" time="2020-12-03T09:50:47Z" level=debug msg=" Bootstrap Destroy: 1m5s" time="2020-12-03T09:50:47Z" level=debug msg=" Cluster Operators: 17m31s" time="2020-12-03T09:50:47Z" level=info msg="Time elapsed: 37m26s" ``` ## Viewing the image pull source {#viewing-the-image-pull-source_validating-an-installation} For clusters with unrestricted network connectivity, you can view the source of your pulled images by using a command on a node, such as `crictl images`. However, for disconnected installations, to view the source of pulled images, you must review the CRI-O logs to locate the `Trying to access` log entry, as shown in the following procedure. Other methods to view the image pull source, such as the `crictl images` command, show the non-mirrored image name, even though the image is pulled from the mirrored location. **Prerequisites** - You have access to the cluster as a user with the `cluster-admin` role. **Procedure** - Review the CRI-O logs for a master or worker node: ```terminal $ oc adm node-logs -u crio ``` ```terminal {title="Example output"} ... Mar 17 02:52:50 ip-10-0-138-140.ec2.internal crio[1366]: time="2021-08-05 10:33:21.594930907Z" level=info msg="Pulling image: quay.io/openshift-release-dev/ocp-release:4.10.0-ppc64le" id=abcd713b-d0e1-4844-ac1c-474c5b60c07c name=/runtime.v1alpha2.ImageService/PullImage Mar 17 02:52:50 ip-10-0-138-140.ec2.internal crio[1484]: time="2021-03-17 02:52:50.194341109Z" level=info msg="Trying to access \"li0317gcp1.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\"" Mar 17 02:52:50 ip-10-0-138-140.ec2.internal crio[1484]: time="2021-03-17 02:52:50.226788351Z" level=info msg="Trying to access \"li0317gcp1.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\"" ... ``` The `Trying to access` log entry indicates where the image is being pulled from. The log might show the image pull source twice, as shown in the preceding example. If your `ImageContentSourcePolicy` object lists multiple mirrors, OpenShift Container Platform attempts to pull the images in the order listed in the configuration, for example: ``` Trying to access \"li0317gcp1.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\" Trying to access \"li0317gcp2.mirror-registry.qe.gcp.devcluster.openshift.com:5000/ocp/release@sha256:1926eae7cacb9c00f142ec98b00628970e974284b6ddaf9a6a086cb9af7a6c31\" ``` ## Getting cluster version, status, and update details {#getting-cluster-version-and-update-details_validating-an-installation} You can view the cluster version and status by running the `oc get clusterversion` command. If the status shows that the installation is still progressing, you can review the status of the Operators for more information. You can also list the current update channel and review the available cluster updates. **Prerequisites** - You have access to the cluster as a user with the `cluster-admin` role. - You have installed the OpenShift CLI (`oc`). **Procedure** 1. Obtain the cluster version and overall status: ```terminal $ oc get clusterversion ``` ```terminal {title="Example output"} NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.6.4 True False 6m25s Cluster version is 4.6.4 ``` The example output indicates that the cluster has been installed successfully. 2. If the cluster status indicates that the installation is still progressing, you can obtain more detailed progress information by checking the status of the Operators: ```terminal $ oc get clusteroperators.config.openshift.io ``` 3. View a detailed summary of cluster specifications, update availability, and update history: ```terminal $ oc describe clusterversion ``` 4. List the current update channel: ```terminal $ oc get clusterversion -o jsonpath='{.items[0].spec}{"\n"}' ``` ```terminal {title="Example output"} {"channel":"stable-4.6","clusterID":"245539c1-72a3-41aa-9cec-72ed8cf25c5c"} ``` 5. Review the available cluster updates: ```terminal $ oc adm upgrade ``` ```terminal {title="Example output"} Cluster version is 4.6.4 Updates: VERSION IMAGE 4.6.6 quay.io/openshift-release-dev/ocp-release@sha256:c7e8f18e8116356701bd23ae3a23fb9892dd5ea66c8300662ef30563d7104f39 ``` **Additional resources** {._additional-resources} - [Querying Operator status after installation](/openshift-docs-markdown/support/troubleshooting/troubleshooting-installations#querying-operator-status-after-installation_troubleshooting-installations) - [Troubleshooting Operator issues](/openshift-docs-markdown/support/troubleshooting/troubleshooting-operator-issues#troubleshooting-operator-issues) - [Updating a cluster using the web console](/openshift-docs-markdown/updating/updating_a_cluster/updating-cluster-web-console#updating-cluster-web-console) - [Understanding update channels and releases](/openshift-docs-markdown/updating/understanding_updates/understanding-update-channels-release#understanding-update-channels-releases) ## Verifying that a cluster uses short-term credentials {#cco-ccoctl-install-verifying_validating-an-installation} You can verify that a cluster uses short-term security credentials for individual components by checking the Cloud Credential Operator (CCO) configuration and other values in the cluster. **Prerequisites** - You deployed an OpenShift Container Platform cluster using the Cloud Credential Operator utility (`ccoctl`) to implement short-term credentials. - You installed the OpenShift CLI (`oc`). - You are logged in as a user with `cluster-admin` privileges. **Procedure** - Verify that the CCO is configured to operate in manual mode by running the following command: ```terminal $ oc get cloudcredentials cluster \ -o=jsonpath={.spec.credentialsMode} ``` The following output confirms that the CCO is operating in manual mode: ```text {title="Example output"} Manual ``` - Verify that the cluster does not have `root` credentials by running the following command: ```terminal $ oc get secrets \ -n kube-system ``` where `` is the name of the root secret for your cloud provider. | Platform | Secret name | | --- | --- | | Amazon Web Services (AWS) | `aws-creds` | | Microsoft Azure | `azure-credentials` | | Google Cloud | `gcp-credentials` | An error confirms that the root secret is not present on the cluster. ```text {title="Example output for an AWS cluster"} Error from server (NotFound): secrets "aws-creds" not found ``` - Verify that the components are using short-term security credentials for individual components by running the following command: ```terminal $ oc get authentication cluster \ -o jsonpath \ --template='{ .spec.serviceAccountIssuer }' ``` This command displays the value of the `.spec.serviceAccountIssuer` parameter in the cluster `Authentication` object. An output of a URL that is associated with your cloud provider indicates that the cluster is using manual mode with short-term credentials that are created and managed from outside of the cluster. - Azure clusters: Verify that the components are assuming the Azure client ID that is specified in the secret manifests by running the following command: ```terminal $ oc get secrets \ -n openshift-image-registry installer-cloud-credentials \ -o jsonpath='{.data}' ``` An output that contains the `azure_client_id` and `azure_federated_token_file` fields confirms that the components are assuming the Azure client ID. - Azure clusters: Verify that the pod identity webhook is running by running the following command: ```terminal $ oc get pods \ -n openshift-cloud-credential-operator ``` ```text {title="Example output"} NAME READY STATUS RESTARTS AGE cloud-credential-operator-59cf744f78-r8pbq 2/2 Running 2 71m pod-identity-webhook-548f977b4c-859lz 1/1 Running 1 70m ``` ## Querying the status of the cluster nodes by using the CLI {#querying-the-status-of-cluster-nodes-using-the-cli_validating-an-installation} You can verify the status of the cluster nodes after an installation. **Prerequisites** - You have access to the cluster as a user with the `cluster-admin` role. - You have installed the OpenShift CLI (`oc`). **Procedure** 1. List the status of the cluster nodes by entering the following command: ```terminal $ oc get nodes ``` 2. Verify that the output lists all of the expected control plane and compute nodes and that each node has a `Ready` status: ```terminal {title="Example output"} NAME STATUS ROLES AGE VERSION compute-1.example.com Ready worker 33m v1.35.4 control-plane-1.example.com Ready master 41m v1.35.4 control-plane-2.example.com Ready master 45m v1.35.4 compute-2.example.com Ready worker 38m v1.35.4 compute-3.example.com Ready worker 33m v1.35.4 control-plane-3.example.com Ready master 41m v1.35.4 ``` 3. Review CPU and memory resource availability for each cluster node: ```terminal $ oc adm top nodes ``` ```terminal {title="Example output"} NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% compute-1.example.com 128m 8% 1132Mi 16% control-plane-1.example.com 801m 22% 3471Mi 23% control-plane-2.example.com 1718m 49% 6085Mi 40% compute-2.example.com 935m 62% 5178Mi 75% compute-3.example.com 111m 7% 1131Mi 16% control-plane-3.example.com 942m 26% 4100Mi 27% ``` **Additional resources** {._additional-resources} - [Verifying node health](/openshift-docs-markdown/support/troubleshooting/verifying-node-health#verifying-node-health) ## Reviewing the cluster status from the OpenShift Container Platform web console {#reviewing-cluster-status-from-the-openshift-web-console_validating-an-installation} You can view specific information in the **Overview** page in the OpenShift Container Platform web console. The **Overview** page displays the following information: - The general status of your cluster - The status of the control plane, cluster Operators, and storage - CPU, memory, file system, network transfer, and pod availability - The API address of the cluster, the cluster ID, and the name of the provider - Cluster version information - Cluster update status, including details of the current update channel and available updates - A cluster inventory detailing node, pod, storage class, and persistent volume claim (PVC) information - A list of ongoing cluster activities and recent events **Prerequisites** - You have access to the cluster as a user with the `cluster-admin` role. **Procedure** - Navigate to **Home** → **Overview**. ## Reviewing the cluster status from Red Hat OpenShift Cluster Manager {#reviewing-cluster-status-from-the-openshift-cluster-manager_validating-an-installation} From the OpenShift Container Platform web console, you can review detailed information about the status of your cluster on OpenShift Cluster Manager. **Prerequisites** - You have logged in to [OpenShift Cluster Manager](https://console.redhat.com/openshift). - You have access to the cluster as a user with the `cluster-admin` role. **Procedure** 1. Go to the **Cluster List** in [OpenShift Cluster Manager](https://console.redhat.com/openshift) and locate your OpenShift Container Platform cluster. 2. Click the **Overview** tab for your cluster. 3. Review the following information about your cluster: - vCPU and memory availability and resource usage - The cluster ID, status, type, region, and the provider name - Node counts by node type - Cluster version details, the creation date of the cluster, and the name of the cluster owner - The life cycle support status of the cluster - Subscription information, including the service level agreement (SLA) status, the subscription unit type, the production status of the cluster, the subscription obligation, and the service level > [!TIP] > To view the history for your cluster, click the **Cluster history** tab. 4. Go to the **Monitoring** page to review the following information: - A list of any issues that have been detected - A list of alerts that are firing - The cluster Operator status and version - The cluster’s resource usage 5. Optional: Go to the **Overview** menu to view information that Red Hat Lightspeed collects about your cluster: - Potential issues that your cluster might be exposed to, categorized by risk level - Health-check status by category **Additional resources** {._additional-resources} - [Using Red Hat Lightspeed to identify issues with your cluster](/openshift-docs-markdown/support/remote_health_monitoring/using-insights-to-identify-issues-with-your-cluster#using-insights-to-identify-issues-with-your-cluster) ## Checking cluster resource availability and utilization {#checking-cluster-resource-availability-and-utilization_validating-an-installation} OpenShift Container Platform provides a comprehensive set of monitoring dashboards that you can analyze to better understand the state of cluster components. As an administrator, you can access dashboards for core OpenShift Container Platform components, including: - etcd - Kubernetes compute resources - Kubernetes network resources - Prometheus - Dashboards relating to cluster and node performance **Figure 1. Example compute resources dashboard** ![Screenshot of the OpenShift Container Platform monitoring dashboard showing compute resources including CPU usage](/openshift-docs-markdown/images/monitoring-dashboard-compute-resources.png) **Prerequisites** - You have access to the cluster as a user with the `cluster-admin` role. **Procedure** 1. In the OpenShift Container Platform web console, navigate to **Observe** → **Dashboards**. 2. Choose a dashboard in the **Dashboard** list. Some dashboards, such as the **etcd** dashboard, produce additional sub-menus when selected. 3. Optional: Select a time range for the graphs in the **Time Range** list. - Select a pre-defined time period. - Set a custom time range by selecting **Custom time range** in the **Time Range** list. 1. Input or select the **From** and **To** dates and times. 2. Click **Save** to save the custom time range. 4. Optional: Select a **Refresh Interval**. 5. Hover over each of the graphs within a dashboard to display detailed information about specific items. **Additional resources** {._additional-resources} - [About OpenShift Container Platform monitoring](https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/latest/html/about_monitoring/about-ocp-monitoring) ## Listing alerts that are firing {#listing-alerts-that-are-firing_validating-an-installation} Alerts provide notifications when a set of defined conditions are true in an OpenShift Container Platform cluster. The Alerting UI in the OpenShift Container Platform web console displays alerts that are firing and provides detailed information about each alert. **Prerequisites** - You have access to the OpenShift Container Platform web console. - You have access to the cluster as a user with the `cluster-admin` role. **Procedure** 1. In the **Administrator** perspective, navigate to the **Observe** → **Alerting** → **Alerts** page. 2. Review the alerts that are firing, including their **Severity**, **State**, and **Source**. Use this information to identify which alerts require immediate attention. 3. Select an alert to view more detailed information in the **Alert Details** page. **Additional resources** {._additional-resources} - [Managing alerts as an Administrator](https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/latest/html/managing_alerts/managing-alerts-as-an-administrator) - [Troubleshooting installations](/openshift-docs-markdown/support/troubleshooting/troubleshooting-installations#troubleshooting-installations) - [Postinstallation cluster tasks](/openshift-docs-markdown/post_installation_configuration/cluster-tasks#post-install-cluster-tasks)