Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 7. Collecting OpenShift sandboxed containers data

When troubleshooting OpenShift sandboxed containers, you can open a support case and provide debugging information using the must-gather tool.

If you are a cluster administrator, you can also review logs on your own, enabling a more detailed level of logs.

When opening a support case, it is helpful to provide debugging information about your cluster to Red Hat Support.

The must-gather tool enables you to collect diagnostic information about your OpenShift Container Platform cluster, including virtual machines and other data related to OpenShift sandboxed containers.

For prompt support, supply diagnostic information for both OpenShift Container Platform and OpenShift sandboxed containers.

7.1.1. About the must-gather tool
Copier lien

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 --image argument with an image, as listed in a following section.

    For example: 

    $ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.10.0
    Copy to Clipboard Toggle word wrap

  • To collect the audit logs, use the -- /usr/bin/gather_audit_logs argument, as described in a following section.

    For example: 

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    Copy to Clipboard Toggle word wrap
    Note

    Audit 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
...
Copy to Clipboard Toggle word wrap

To collect OpenShift sandboxed containers data with must-gather, you must specify the OpenShift sandboxed containers image: 

--image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel8:1.2.0
Copy to Clipboard Toggle word wrap

7.2. About OpenShift sandboxed containers log data
Copier lien

When you collect log data about your cluster, the following features and objects are associated with OpenShift sandboxed containers:

  • All namespaces and their child objects that belong to any OpenShift sandboxed containers resources
  • All OpenShift sandboxed containers custom resource definitions (CRDs)

The following OpenShift sandboxed containers component logs are collected for each pod running with the kata runtime:

  • Kata agent logs
  • Kata runtime logs
  • QEMU logs
  • Audit logs
  • CRI-O logs

7.3. Enabling debug logs for OpenShift sandboxed containers
Copier lien

As a cluster administrator, you can collect a more detailed level of logs for OpenShift sandboxed containers. Enhance logging by changing the log_level in the CRI-O runtime for the worker nodes running OpenShift sandboxed containers.

Procedure

  1. Create a YAML file for the ContainerRuntimeConfig CR with the following manifest: 

    apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: crio-debug
spec:
 machineConfigPoolSelector:
  matchLabels:
    pools.operator.machineconfiguration.openshift.io/worker: ''
    1 
    
 containerRuntimeConfig:
    logLevel: debug
    Copy to Clipboard Toggle word wrap
    1
    Specify a label for the machine config pool that you want you want to modify.

  2. Create the ContainerRuntimeConfig CR: 

    $ oc create -f ctrcfg.yaml
    Copy to Clipboard Toggle word wrap
    Note

    The file name listed above is a suggestion. You can create this file using another name.

  3. Verify the CR is created: 

    $ oc get ctrcfg
    Copy to Clipboard Toggle word wrap

    Example output

    NAME           AGE
crio-debug   3m19s
    Copy to Clipboard Toggle word wrap

Verification

  1. Monitor the machine config pool until the UPDATED field for all worker nodes appears as True: 

    $ oc get mcp worker
    Copy to Clipboard Toggle word wrap

    Example output

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h
    Copy to Clipboard Toggle word wrap

  2. Verify that the log_level was updated in CRI-O:

    1. Open an oc debug session to a node in the machine config pool and run chroot /host. 

      $ oc debug node/<node_name>
      Copy to Clipboard Toggle word wrap 
      sh-4.4# chroot /host
      Copy to Clipboard Toggle word wrap

    2. Verify the changes in the crio.conf file: 

      sh-4.4# crio config | egrep 'log_level
      Copy to Clipboard Toggle word wrap

      Example output

      log_level = "debug"
      Copy to Clipboard Toggle word wrap

7.3.1. Viewing debug logs for OpenShift sandboxed containers
Copier lien

Cluster administrators can use the enhanced debug logs for OpenShift sandboxed containers to troubleshoot issues. The logs for each node are printed to the node journal.

You can review the logs for the following OpenShift sandboxed containers components:

  • Kata agent
  • Kata runtime (containerd-shim-kata-v2)
  • virtiofsd

Logs for QEMU do not print to the node journal. However, a QEMU failure is reported to the runtime, and the console of the QEMU guest is printed to the node journal. You can view these logs together with the Kata agent logs.

Prerequisites

  • You have installed the OpenShift CLI (oc).
  • You have access to the cluster as a user with the cluster-admin role.

Procedure

  • To review the Kata agent logs and guest console logs, run: 

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata -g “reading guest console”
    Copy to Clipboard Toggle word wrap

  • To review the kata runtime logs, run: 

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata
    Copy to Clipboard Toggle word wrap

  • To review the virtiofsd logs, run: 

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t virtiofsd
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat