Soluciona problemas de contenedores personalizados en Dataflow

En este documento, se proporcionan instrucciones para solucionar problemas que pueden ocurrir cuando se usan contenedores personalizados con Dataflow. Se centra en los problemas con contenedores o trabajadores que no se inician. Si tus trabajadores pueden iniciar y el trabajo avanza, sigue las instrucciones generales para solucionar problemas de tu canalización.

Antes de comunicarte con el equipo de asistencia, asegúrate de haber descartado los problemas relacionados con la imagen de contenedor:

  • Sigue los pasos para probar la imagen de contenedor de forma local.
  • Busca errores en los registros de trabajos o en los registros de trabajador y compara cualquier error que se encuentre con la guía de errores comunes.
  • Asegúrate de que la versión del SDK de Apache Beam y la versión del idioma que usas para iniciar la canalización coincidan con la versión del SDK en tu imagen de contenedor personalizada.
  • Si usas Java, asegúrate de que la versión principal de Java que usas para iniciar la canalización coincida con la versión instalada en la imagen del contenedor.
  • Si usas Python, asegúrate de que la versión principal y secundaria de Python que usas para iniciar la canalización coincida con la versión instalada en la imagen de contenedor y que la imagen no tenga dependencias en conflicto. Puedes ejecutar pip check para confirmar.

Busca registros de trabajador relacionados con contenedores personalizados

Los registros de trabajador de Dataflow para los mensajes de error relacionados con contenedores pueden usar el Explorador de registros:

  1. Selecciona nombres de registro. Es muy probable que los errores personalizados de inicio del contenedor sean de uno de los siguientes:

    • dataflow.googleapis.com/kubelet
    • dataflow.googleapis.com/docker
    • dataflow.googleapis.com/worker-startup
    • dataflow.googleapis.com/harness-startup

  2. Selecciona el recurso Dataflow Step y especifica job_id.

Si ves mensajes de registro Error Syncing pod..., sigue la guía de errores común. Puedes consultar estos mensajes de registro en los registros de trabajador de Dataflow a través del Explorador de registros con la siguiente consulta:

resource.type="dataflow_step" AND jsonPayload.message:("IMAGE_URI") AND severity="ERROR"

Problemas comunes

Los siguientes son algunos problemas comunes cuando se usan contenedores personalizados.

El trabajo tiene errores o falló porque no se puede extraer la imagen de contenedor

Los trabajadores de Dataflow deben poder acceder a las imágenes de contenedor personalizadas. Si el trabajador no puede extraer la imagen debido a URL no válidas, credenciales mal configuradas o falta de acceso a la red, el trabajador no se inicia.

En los trabajos por lotes en los que no se inició ningún trabajo y no se pueden iniciar varios trabajadores de forma secuencial, Dataflow no realiza el trabajo. De lo contrario, Dataflow registra los errores, pero no realiza ninguna acción para evitar destruir el estado del trabajo de larga duración.

Para obtener información sobre cómo solucionar este problema, consulta La solicitud de extracción de imágenes falló con un error en la página de solución de errores de Dataflow.

Los trabajadores no se inician o el trabajo no progresa

A veces, si el contenedor del SDK no se inicia debido a un error, Dataflow no puede determinar si el error es permanente o grave. Luego, Dataflow intenta reiniciar el trabajador constantemente.

Si no hay errores evidentes, pero ves registros de nivel INFO de [topologymanager] RemoveContainer en dataflow.googleapis.com/kubelet, estos registros indican que la imagen de contenedor personalizada sale antes y no inició el proceso del SDK de trabajador de larga duración.

Si los trabajadores se iniciaron de forma correcta, pero no hay trabajo, es posible que un error esté impidiendo que se inicie el contenedor del SDK. En este caso, aparece el siguiente error en las recomendaciones de diagnóstico:

Failed to start container

Además, los registros de trabajador no contienen líneas como las siguientes:

Executing: python -m apache_beam.runners.worker.sdk_worker_main or Executing: java ... FnHarness

Encuentra errores específicos en registros de trabajador y consulta la guía de errores comunes.

Las causas comunes de estos problemas incluyen las siguientes:

  • Problemas con la instalación del paquete, como errores de instalación de pip debido a problemas de dependencia. Consulta Error de sincronización del Pod… no se pudo ejecutar “StartContainer”.
  • Si el contenedor que se usó no es compatible con la arquitectura de la CPU de la VM de trabajador, es posible que veas errores como exec format error. Para obtener más información, consulta Error de sincronización del Pod ... no se pudo ejecutar "StartContainer".
  • Errores con los argumentos de comandos personalizados o con el ENTRYPOINT configurado en el Dockerfile. Por ejemplo, un ENTRYPOINT personalizado no inicia la secuencia de comandos de inicio predeterminada /opt/apache/beam/boot o no pasa argumentos de manera adecuada a esta secuencia de comandos. Para obtener más información, consulta Modifica el punto de entrada del contenedor.
  • Errores cuando la versión del SDK de Apache Beam no coincide entre el entorno de inicio y el entorno de ejecución. En un modo de falla, es posible que los valores predeterminados establecidos en las opciones de canalización del SDK de Apache Beam no se reconozcan. Por ejemplo, es posible que veas errores como sdk_worker_main.py: error: argument --flink_version: invalid choice: '1.16' (choose from '1.12', '1.13', '1.14', '1.15') en los registros de trabajador. Para solucionar este problema, instala la misma versión del SDK de Apache Beam en la imagen de contenedor que usas a fin de iniciar la canalización. Para obtener más información, consulta Haz que el entorno de lanzamiento sea compatible con el entorno de ejecución.