Chapter 7. Troubleshoot
You can open a Red Hat support case and provide debugging information by using must-gather. The must-gather tool collects diagnostic information about your OpenShift Container Platform cluster, including virtual machines and other data.
7.1. Using must-gather Copy linkLink copied to clipboard!
The oc adm must-gather CLI command collects the information from your cluster that is most likely needed for debugging issues, including:
- Resource definitions
- Service logs
By default, the oc adm must-gather command uses the default plugin image and writes into ./must-gather.local.
Alternatively, you can collect specific information by running the command with the appropriate arguments as described in the following sections:
To collect data related to one or more specific features, use the
--imageargument with an image, as listed in a following section.For example:
$ oc adm must-gather --image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel9:1.12.0To collect the audit logs, use the
-- /usr/bin/gather_audit_logsargument, as described in a following section.For example:
$ oc adm must-gather -- /usr/bin/gather_audit_logsNoteAudit logs are not collected as part of the default set of information to reduce the size of the files.
When you run oc adm must-gather, a new pod with a random name is created in a new project on the cluster. The data is collected on that pod and saved in a new directory that starts with must-gather.local. This directory is created in the current working directory.
For example:
NAMESPACE NAME READY STATUS RESTARTS AGE
...
openshift-must-gather-5drcj must-gather-bklx4 2/2 Running 0 72s
openshift-must-gather-5drcj must-gather-s8sdh 2/2 Running 0 72s
...
Optionally, you can run the oc adm must-gather command in a specific namespace by using the --run-namespace option.
For example:
$ oc adm must-gather --run-namespace <namespace> --image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel9:1.12.0
7.2. KataConfig status messages Copy linkLink copied to clipboard!
The following table displays the status messages for the KataConfig custom resource (CR) for a cluster with two worker nodes.
| Status | Description |
|---|---|
| Initial installation
When a |
|
| Installing Within a few seconds the status changes. |
|
| Installing (Worker-1 installation starting)
For a short period of time, the status changes, signifying that one node has initiated the installation of |
|
| Installing (Worker-1 installed, worker-0 installation started)
After some time, |
|
| Installed
When installed, both workers are listed as installed, and the |
|
| Status | Description |
|---|---|
| Initial uninstall
If |
|
| Uninstalling After a few seconds, one of the workers starts uninstalling. |
|
| Uninstalling Worker-1 finishes and worker-0 starts uninstalling. |
|
The reason field can also report the following causes:
-
Failed: This is reported if the node cannot finish its transition. ThestatusreportsTrueand themessageisNode <node_name> Degraded: <error_message_from_the_node>. -
BlockedByExistingKataPods: This is reported if there are pods running on a cluster that use thekata-ccruntime whilekata-ccis being uninstalled. Thestatusfield isFalseand themessageisExisting pods using "kata-cc" RuntimeClass found. Please delete the pods manually for KataConfig deletion to proceed. There could also be a technical error message reported likeFailed to list kata pods: <error_message>if communication with the cluster control plane fails.