mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
59 lines
2.4 KiB
Plaintext
59 lines
2.4 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * installing/installing/installing-troubleshooting.adoc
|
|
|
|
[id="installation-common-issues_{context}"]
|
|
= Troubleshooting common issues with installing on {rh-virtualization-first}
|
|
|
|
Here are some common issues you might encounter, along with proposed causes and solutions.
|
|
|
|
[id="cpu-load-increases-and-nodes-go-into-a-not-ready-state_{context}"]
|
|
== CPU load increases and nodes go into a `Not Ready` state
|
|
|
|
* *Symptom*: CPU load increases significantly and nodes start going into a `Not Ready` state.
|
|
* *Cause*: The storage domain latency might be too high, especially for control plane nodes (also known as the master nodes).
|
|
* *Solution*:
|
|
+
|
|
Make the nodes ready again by restarting the kubelet service:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ systemctl restart kubelet
|
|
----
|
|
+
|
|
Inspect the {product-title} metrics service, which automatically gathers and reports on some valuable data such as the etcd disk sync duration. If the cluster is operational, use this data to help determine whether storage latency or throughput is the root issue. If so, consider using a storage resource that has lower latency and higher throughput.
|
|
+
|
|
To get raw metrics, enter the following command as kubeadmin or user with cluster-admin privileges:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get --insecure-skip-tls-verify --server=https://localhost:<port> --raw=/metrics
|
|
----
|
|
+
|
|
To learn more, see https://access.redhat.com/articles/3793621[Exploring Application Endpoints for the purposes of Debugging with OpenShift 4.x]
|
|
|
|
[id="trouble-connecting-the-rhv-cluster-api_{context}"]
|
|
== Trouble connecting the {product-title} cluster API
|
|
|
|
* *Symptom*: The installation program completes but the {product-title} cluster API is not available. The bootstrap virtual machine remains up after the bootstrap process is complete. When you enter the following command, the response will time out.
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc login -u kubeadmin -p *** <apiurl>
|
|
----
|
|
|
|
* *Cause*: The bootstrap VM was not deleted by the installation program and has not released the cluster's API IP address.
|
|
* *Solution*: Use the `wait-for` subcommand to be notified when the bootstrap process is complete:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ ./openshift-install wait-for bootstrap-complete
|
|
----
|
|
+
|
|
When the bootstrap process is complete, delete the bootstrap virtual machine:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ ./openshift-install destroy bootstrap
|
|
----
|