Depuración de nodos trabajadores

[Nube privada virtual] {: tag-vpc} Infraestructura clásica

Revise las opciones para depurar sus nodos trabajadores y encontrar las causas raíz de los errores.

Comprobar notificaciones de nodo trabajador y actualizaciones de mantenimiento

Compruebe el panel de control de estado y salud de IBM Cloud para ver si hay notificaciones o actualizaciones de mantenimiento que puedan ser relevantes para los nodos trabajadores. Estas notificaciones o actualizaciones pueden ayudar a determinar la causa de las anomalías del nodo trabajador.

  1. Clústeres clásicos Compruebe en elpanel de control de estado las notificaciones de mantenimiento de emergencia de IBM Cloud que puedan afectar a los nodos trabajadores clásicos de la cuenta. En función de la naturaleza de la notificación de mantenimiento, es posible que tenga que rearrancar o volver a cargar los nodos trabajadores.
  2. Consulte la IBM Cloud panel de instrumentos Estado para ver los problemas conocidos que pueden afectar a los nodos trabajadores o al clúster. Si alguno de los componentes siguientes muestra un estado de error, dicho componente puede ser la causa de las interrupciones del nodo trabajador.
    • Para todos los clústeres, compruebe los componentes de Kubernetes Service y Container Registry.
    • Para los clusters Red Hat OpenShift, compruebe el componente Red Hat OpenShift on IBM Cloud componente.
    • Para los clústeres de VPC, compruebe los componentes Virtual Private Cloud, Virtual Private Endpoint y Virtual Server for VPC.
    • Para los clústeres clásicos, compruebe los componentes Suministro de infraestructura clásica y Virtual Servers.

Pasos rápidos para resolver problemas del nodo de trabajador

Si el nodo de trabajador no está funcionando como se esperaba, puede seguir estos pasos para actualizar el clúster y las herramientas de línea de mandatos, o para ejecutar pruebas de diagnóstico. Si el problema persiste, consulte Depuración del nodo de trabajador para ver los pasos adicionales.

  1. Actualice el clúster y los nodos de trabajador a la última versión.
  2. Actualice las herramientas de línea de mandatos.

Depuración del nodo de trabajador

Paso 1: Obtener el estado de nodo trabajador

Si el clúster está en estado Crítico, Error al suprimir o Aviso, o se ha bloqueado en el estado Pendiente durante mucho tiempo, revise el estado de los nodos trabajadores.

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

Paso 2: Revisar el estado del nodo trabajador

Revise los campos State y Status de cada nodo trabajador en la salida de la CLI.

Para obtener más información, consulte Estados de los nodos trabajadores.

Paso 3: Obtener los detalles de cada nodo trabajador

Obtenga los detalles del nodo trabajador. Si en los detalles se incluye un mensaje de error, revise la lista de mensajes de error comunes para nodos trabajadores para saber cómo resolver el problema.

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

Paso 4: Revisar el proveedor de infraestructura para el nodo trabajador

Revise el entorno de infraestructura para comprobar si hay otras razones que puedan causar los problemas de nodo trabajador.

  1. Consulte con el equipo de red para asegurarse de que ningún mantenimiento reciente, como las actualizaciones de cortafuegos o de subred, pueda afectar a las conexiones del nodo trabajador.
  2. Consulte IBM Cloud para obtener información sobre Red Hat OpenShift on IBM Cloud y el proveedor de infraestructura subyacente, como Virtual Servers para componentes clásicos relacionados con VPC, o Satellite.
  3. Si tiene acceso a la infraestructura subyacente, como por ejemplo los Servidores virtuales clásicos, revise los detalles de las máquinas correspondientes para los nodos trabajadores.

Paso 5: Reúna los registros y otros detalles sobre sus nodos trabajadores

Ejecutar el comando must-gather

El comando CLI oc adm must-gather recoge la información de su cluster para depurar problemas. Esta herramienta imprescindible recopila definiciones de recursos, registros de servicios y mucho más. Tenga en cuenta que los registros de auditoría no se recogen como parte del conjunto de información por defecto para reducir el tamaño de los archivos.

Al ejecutar oc adm must-gather, se crea un nuevo pod con un nombre aleatorio en un nuevo proyecto del clúster. Los datos se recopilan en ese pod y se guardan en un nuevo directorio que empieza por must-gather.local.

Revisa los siguientes ejemplos de comandos.

oc adm must-gather

Ejemplo de comando para recopilar datos relacionados con una o más características específicas, utilice el argumento --image con una imagen específica.

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Ejemplo de comando para recopilar registros de auditoría.

oc adm must-gather -- /usr/bin/gather_audit_logs

Comando de ejemplo para ejecutar must-gather en un espacio de nombres específico.

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Comandos ejemplo para recopilar los registros de un momento dado.

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

Ejemplo de comando para recopilar registros de red.

oc adm must-gather -- gather_network_logs

Para más ejemplos y argumentos ejecute el siguiente comando

oc adm must-gather -h

Comando de ejemplo para crear un archivo comprimido a partir del directorio must-gather.

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

Adjunte el archivo comprimido a su caso de asistencia.

Recopilación de un informe SOS

sosreport es una herramienta que recopila detalles de configuración, información del sistema y datos de diagnóstico de los sistemas Red Hat Enterprise Linux (RHEL) y Red Hat Enterprise Linux CoreOS (RHCOS). Proporciona una forma estandarizada de recopilar información de diagnóstico relativa a un nodo, que puede facilitarse al servicio de asistencia para el diagnóstico de problemas.

En algunas interacciones de soporte, éste puede pedirle que recopile un archivo sosreport para un nodo OpenShift Container Platform específico. Por ejemplo, podría ser necesario revisar los registros del sistema u otros datos específicos del nodo que no se incluyen en la salida de oc adm must-gather.

El método para recopilar un « sosreport » varía en función del sistema operativo del nodo de trabajo. Los nodos RHCOS utilizan el comando « toolbox ». Los nodos RHEL 8 y RHEL 9 no admiten el comando « toolbox »; en su lugar, utiliza el script «sosreport» de Red Hat.

La forma recomendada de generar un sosreport para un nodo de cluster OpenShift Container Platform es a través de un pod de depuración.

Acceda al clúster de Red Hat OpenShift.

  1. Enumera tus nodos de trabajo para identificar el nodo de destino y su sistema operativo.

    oc get nodes -o wide

    Anota el nombre del nodo de trabajo del que deseas recopilar el archivo « sosreport ». La columna «OS-IMAGE» indica si el nodo ejecuta RHCOS o RHEL.

  2. Inicia una sesión de depuración en el nodo de destino.

    oc debug node/node_name

    Para entrar en una sesión de depuración en el nodo de destino contaminado con el efecto NoExecute, añada una tolerancia a un espacio de nombres temporal e inicie el pod de depuración en el espacio de nombres temporal.

    oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'

    oc debug node/my-cluster-node

  3. Establece /host como directorio raíz dentro del shell de depuración. El pod de depuración monta el sistema de archivos raíz del host en « /host » dentro del pod. Si cambias el directorio raíz a /host, podrás ejecutar los archivos binarios que se encuentran en las rutas de ejecutables del servidor.

    chroot /host

    OpenShift Container Platform Los nodos del clúster que ejecutan Red Hat Enterprise Linux CoreOS (RHCOS) son inmutables y dependen de los operadores para aplicar los cambios en el clúster. No se recomienda acceder a los nodos del clúster mediante SSH. Sin embargo, si la API OpenShift Container Platform no está disponible o el kubelet no funciona correctamente en el nodo de destino, las operaciones oc podrían verse afectadas. En tales situaciones, es posible acceder a los nodos utilizando ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN en su lugar.

  4. Recopila el archivo « sosreport » utilizando el método adecuado para el sistema operativo del nodo de trabajo.

    • Nodos RHCOS: Utiliza el comando « toolbox ».

      1. Inicie un contenedor toolbox, que incluye los binarios y plug-ins necesarios para ejecutar el sitio sosreport. Comando « toolbox » solo es compatible con los nodos RHCOS.

        toolbox

        Si ya se está ejecutando un pod de caja de herramientas existente, el comando de caja de herramientas muestra 'toolbox-' already exists. Trying to start…. Elimine el contenedor de caja de herramientas en ejecución con podman rm toolbox- e inicie un nuevo contenedor de caja de herramientas.

      2. Ejecute el comando sos report y siga las instrucciones para recopilar datos de solución de problemas.

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on

        Ejemplo de comando para incluir información sobre las configuraciones de red OVN- Kubernetes de un nodo en su informe.

        sos report --all-logs

        La salida de « sosreport » proporciona la ubicación del archivo y la suma de comprobación. Las siguientes referencias de salida de ejemplo admiten el ID de caso 01234567. La ruta del archivo se encuentra fuera del entorno « chroot », ya que el contenedor de la caja de herramientas monta el directorio raíz del host en « /host ».

        Your sosreport has been generated and saved in:
/host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
The checksum is: 382ffc167510fd71b4f12a4f40b97a4e

    • Nodos RHEL 8 y RHEL 9: El comando « toolbox » no es compatible con los nodos RHEL. Utiliza en su lugar el script de recopilación de informes «sosreport» de Red Hat.

      1. Descarga y ejecuta el script «sosreport» de Red Hat siguiendo las instrucciones que figuran en el artículo de la base de conocimientos Red Hat.

      2. Sigue las instrucciones del script para recopilar los datos de resolución de problemas. Toma nota de la ubicación del archivo comprimido generado a partir de la salida del script.

  5. Envía sosreport a un archivo.

    El contenedor de depuración monta el directorio raíz del host en /host. Al especificar los archivos de destino para la concatenación, utiliza la ruta absoluta desde el directorio raíz del contenedor de depuración, incluyendo « /host ».

    oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz

    OpenShift Container Platform Los nodos del clúster que ejecutan Red Hat Enterprise Linux CoreOS (RHCOS) son inmutables y dependen de los operadores para aplicar los cambios en el clúster. No se recomienda transferir un archivo sosreport desde un nodo de clúster mediante scp. Sin embargo, si la API OpenShift Container Platform no está disponible o el kubelet no funciona correctamente en el nodo de destino, oc las operaciones podrían verse afectadas. En tales situaciones, es posible copiar un archivo sosreport desde un nodo ejecutando scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>.

  6. Cargue el archivo en su caso de asistencia.