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:
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
Selecciona el recurso
Dataflow Step
y especificajob_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, unENTRYPOINT
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.