Errores conocidos

Managed Airflow (3ª gen.) | Managed Airflow (2ª gen.) | Managed Airflow (1ª gen. heredada)

En esta página, se enumeran los problemas conocidos de Managed Airflow. Para obtener información sobre las correcciones de problemas, consulta las Notas de la versión.

Algunos problemas afectan a las versiones anteriores y se pueden solucionar actualizando tu entorno.

Los rangos de direcciones que no son RFC 1918 son compatibles de forma parcial con los Pods y los servicios.

Managed Airflow depende de GKE para ofrecer compatibilidad con direcciones que no sean RFC 1918 para Pods y Services. En Managed Airflow, solo se admite la siguiente lista de rangos que no son RFC 1918:

  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

Las etiquetas de entorno agregadas durante una actualización no se propagan por completo

Cuando actualizas las etiquetas del entorno, no se aplican a las VMs de Compute Engine en el clúster del entorno. Como solución alternativa, puedes aplicar las etiquetas de forma manual.

No se pueden crear entornos de Managed Airflow con las restricciones de la política de la organización/compute.disableSerialPortLogging aplicadas

La creación del entorno de Managed Airflow falla si se aplica la política de la organización constraints/compute.disableSerialPortLogging en el proyecto de destino.

Diagnóstico

Para determinar si este problema te afectará, sigue este procedimiento:

Ve al menú de GKE en la consola de Google Cloud . Visita el menú de GKE.

Luego, selecciona el clúster recién creado. Verifica el siguiente error:

Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:
[CONDITION_NOT_MET]: Instance '<generated instance name>' creation failed:
Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

Soluciones alternativas:

  1. Inhabilita la política de la organización en el proyecto en el que se creará el entorno de Managed Airflow.

    La política de la organización siempre se puede inhabilitar a nivel del proyecto, incluso si los recursos superiores (organización o carpeta) la tienen habilitada. Consulta la página Personaliza políticas de restricciones booleanas para obtener más detalles.

  2. Usa filtros de exclusión

    Usar un filtro de exclusión para los registros del puerto en serie implica el mismo objetivo que inhabilitar la política de la organización, ya que habrá registros de la consola en serie en Logging. Para obtener más detalles, consulta la página Filtros de exclusión.

Uso de Deployment Manager para administrar recursos de Google Cloud protegidos por los Controles del servicio de VPC

Las versiones 2.0.x de Managed Airflow (1ª gen. heredada) y Managed Airflow (2ª gen.) usan Deployment Manager para crear componentes de entornos de Managed Airflow.

En diciembre de 2020, es posible que hayas recibido información sobre la necesidad de realizar una configuración adicional de los Controles del servicio de VPC para poder usar Deployment Manager y administrar los recursos protegidos por los Controles del servicio de VPC.

Queremos aclarar que no es necesario que realices ninguna acción si usas Managed Airflow y no usas Deployment Manager directamente para administrar los recursos de Google Cloud mencionados en el anuncio de Deployment Manager.

Deployment Manager muestra información sobre una función no compatible

Es posible que veas la siguiente advertencia en la pestaña Deployment Manager:

The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.

En el caso de las implementaciones de Deployment Manager que pertenecen a Managed Airflow, puedes ignorar esta advertencia.

No se puede borrar un entorno después de que se borra su clúster

Este problema se aplica a las versiones 2.0.x de Managed Airflow (generación 1 heredada) y Managed Airflow (generación 2).

Si borras el clúster de GKE de tu entorno antes que el entorno, los intentos de borrar el entorno generarán el siguiente error:

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

Para borrar un entorno cuando su clúster ya se borró, haz lo siguiente:

  1. En la consola de Google Cloud , ve a la página Deployment Manager.

    Ir a Deployment Manager

  2. Busca todas las implementaciones marcadas con etiquetas:

    • goog-composer-environment:<environment-name>
    • goog-composer-location:<environment-location>

    Deberías ver dos implementaciones marcadas con las etiquetas descritas:

    • Una implementación llamada <environment-location>-<environment-name-prefix>-<hash>-sd
    • Una implementación llamada addons-<uuid>

  3. Borra de forma manual los recursos que siguen apareciendo en estas dos implementaciones y existen en el proyecto (por ejemplo, temas y suscripciones de Pub/Sub). Para ello, deberás hacer lo siguiente:

    1. Selecciona las implementaciones.

    2. Haz clic en Borrar.

    3. Selecciona la opción Borrar 2 implementaciones y todos los recursos que crearon, como VM, balanceadores de cargas y discos, y haz clic en Borrar todo.

    La operación de eliminación falla, pero se borran los recursos restantes.

  4. Borra las implementaciones mediante una de estas opciones:

    • En la consola de Google Cloud , vuelve a seleccionar ambas implementaciones. Haz clic en Borrar y, luego, selecciona la opción Borrar 2 implementaciones, pero conservar los recursos que crearon.

    • Ejecuta un comando de gcloud para borrar las implementaciones con la política ABANDON:

      gcloud deployment-manager deployments delete addons-<uuid> \
    --delete-policy=ABANDON

gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \
    --delete-policy=ABANDON

  5. Borra tu entorno de Managed Airflow.

Advertencias sobre entradas duplicadas de la tarea “echo” que pertenecen al DAG “echo-airflow_monitoring”

Es posible que veas la siguiente entrada en los registros de Airflow:

in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")

Puedes ignorar estas entradas de registro, ya que este error no afecta al DAG de Airflow ni al procesamiento de tareas.

Trabajamos para mejorar el servicio de Managed Airflow y quitar estas advertencias de los registros de Airflow.

La creación del entorno falla en los proyectos con las APIs de Identity-Aware Proxy agregadas al perímetro de los Controles del servicio de VPC

En los proyectos con los Controles del servicio de VPC habilitados, la cuenta de cloud-airflow-prod@ requiere acceso explícito en tu perímetro de seguridad para crear entornos.

Para crear entornos, puedes usar una de las siguientes soluciones:

  • No agregues la API de Cloud Identity-Aware Proxy ni la API de TCP de Identity-Aware Proxy al perímetro de seguridad.

  • Agrega la cuenta de servicio de cloud-airflow-prod@ como miembro de tu perímetro de seguridad con la siguiente configuración en el archivo de condiciones YAML:

     - members:
    - serviceAccount:cloud-airflow-prod@

La creación o actualización del entorno de Managed Airflow falla cuando se inhabilita la política compute.vmExternalIpAccess

Este problema se aplica a los entornos de Managed Airflow (generación 1 heredada) y Managed Airflow (generación 2).

Los clústeres de GKE de Managed Airflow configurados en el modo de IP pública requieren conectividad externa para sus VMs. Debido a esto, la política compute.vmExternalIpAccess no puede prohibir la creación de VM con direcciones IP externas. Para obtener más información sobre esta política de la organización, consulta Restricciones de las políticas de la organización.

La primera ejecución del DAG para un archivo DAG subido arroja varias tareas con errores

Cuando subes un archivo DAG, a veces las primeras tareas del primer DAG que se ejecutan para él fallan debido al error Unable to read remote log.... Este problema ocurre porque el archivo de DAG se sincroniza entre el bucket de tu entorno, los trabajadores de Airflow y los programadores de Airflow de tu entorno. Si el programador obtiene el archivo DAG y lo programa para que lo ejecute un trabajador, y si el trabajador aún no tiene el archivo DAG, la ejecución de la tarea falla.

Para mitigar este problema, los entornos con Airflow 2 están configurados para realizar dos reintentos de una tarea con errores de forma predeterminada. Si una tarea falla, se reintenta dos veces con intervalos de 5 minutos.

Anuncios sobre la eliminación de la asistencia para las versiones Beta de la API obsoletas de las versiones de GKE

Managed Airflow administra los clústeres de GKE subyacentes que son propiedad de Managed Airflow. A menos que uses de forma explícita esas API en tus DAG y en tu código, puedes ignorar los anuncios sobre las API obsoletas de GKE. Managed Airflow se encarga de las migraciones, si es necesario.

La vulnerabilidad de Apache Log4j 2 (CVE-2021-44228) no debería afectar a Managed Airflow

En respuesta a la vulnerabilidad de Apache Log4j 2 (CVE-2021-44228), Managed Airflow realizó una investigación detallada y creemos que Managed Airflow no se ve afectado por este exploit.

Los trabajadores o programadores de Airflow pueden tener problemas cuando acceden al bucket de Cloud Storage del entorno

Managed Airflow usa gcsfuse para acceder a la carpeta /data en el bucket del entorno y guardar los registros de tareas de Airflow en el directorio /logs (si está habilitado). Si gcsfuse está sobrecargado o el bucket del entorno no está disponible, es posible que se produzcan fallas en la instancia de la tarea de Airflow y que veas errores Transport endpoint is not connected en los registros de Airflow.

Soluciones:

A veces, la IU de Airflow no vuelve a cargar un complemento una vez que se cambia

Si un complemento consta de muchos archivos que importan otros módulos, es posible que la IU de Airflow no pueda reconocer el hecho de que se debe volver a cargar un complemento. En ese caso, reinicia el servidor web de Airflow de tu entorno.

El clúster del entorno tiene cargas de trabajo en el estado No programable

Este problema conocido solo se aplica a Managed Airflow (2ª gen.).

En Managed Airflow (Gen 2), después de crear un entorno, varias cargas de trabajo en el clúster del entorno permanecen en el estado No programable.

Cuando un entorno escala verticalmente, se crean Pods de trabajador nuevos y Kubernetes intenta ejecutarlos. Si no hay recursos libres disponibles para ejecutarlos, los Pods de trabajador se marcan como No programables.

En esta situación, el escalador automático del clúster agrega más nodos, lo que tarda un par de minutos. Hasta que se complete, los Pods permanecerán en el estado No programable y no ejecutarán ninguna tarea.

Las cargas de trabajo de DaemonSet no programables llamadas composer-gcsfuse y composer-fluentd que no se pueden iniciar en nodos en los que no están presentes los componentes de Airflow no afectan tu entorno.

Si este problema persiste durante mucho tiempo (más de 1 hora), puedes consultar los registros del escalador automático del clúster. Puedes encontrarlos en el Visor de registros con el siguiente filtro:

resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"

Contiene información sobre las decisiones que toma el escalador automático de clústeres: expande cualquier noDecisionStatus para ver el motivo por el que no se puede aumentar o reducir la escala verticalmente del clúster.

Error 504 cuando se accede a la IU de Airflow

Puedes obtener el error 504 Gateway Timeout cuando accedes a la IU de Airflow. Este error puede tener varias causas:

  • Problema de comunicación transitorio. En este caso, intenta acceder a la IU de Airflow más tarde. También puedes reiniciar el servidor web de Airflow.

  • (Solo para Managed Airflow (3ª gen.)) Problema de conectividad. Si la IU de Airflow no está disponible de forma permanente y se generan errores de tiempo de espera o 504, asegúrate de que tu entorno pueda acceder a *.composer.googleusercontent.com.

  • (Solo para Managed Airflow (2ª gen.)) Problema de conectividad. Si la IU de Airflow no está disponible de forma permanente y se generan errores de tiempo de espera o 504, asegúrate de que tu entorno pueda acceder a *.composer.cloud.google.com. Si usas el Acceso privado a Google y envías tráfico a través de IP virtuales de private.googleapis.com, o los Controles del servicio de VPC y envías tráfico a través de IP virtuales de restricted.googleapis.com, asegúrate de que tu Cloud DNS también esté configurado para los nombres de dominio de *.composer.cloud.google.com.

  • El servidor web de Airflow no responde. Si el error 504 persiste, pero aún puedes acceder a la IU de Airflow en ciertos momentos, es posible que el servidor web de Airflow no responda porque está sobrecargado. Intenta aumentar los parámetros de escala y rendimiento del servidor web.

Error 502 cuando se accede a la IU de Airflow

El error 502 Internal server exception indica que la IU de Airflow no puede atender las solicitudes entrantes. Este error puede tener varias causas:

  • Problema de comunicación transitorio. Intenta acceder a la IU de Airflow más tarde.

  • No se pudo iniciar el servidor web. Para comenzar, el servidor web requiere que primero se sincronicen los archivos de configuración. Revisa los registros del servidor web para buscar entradas de registro similares a las siguientes: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp o GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Si ves estos errores, verifica si los archivos mencionados en los mensajes de error siguen presentes en el bucket del entorno.

    En caso de que se quiten de forma accidental (por ejemplo, porque se configuró una política de retención), puedes restablecerlos de la siguiente manera:

    1. Establece una nueva variable de entorno en tu entorno. Puedes usar cualquier nombre y valor de variable.

    2. Anula una opción de configuración de Airflow. Puedes usar una opción de configuración de Airflow que no exista.

Error 500 cuando se accede a la IU de Airflow después de anular [webserver]analytics_tool

En entornos con Airflow 2, si anulas la opción de configuración de Airflow [webserver]analytics_tool para enrutar datos de uso anónimos de la IU de Airflow a un servicio de estadísticas (como Google Analytics, Segment, MetaRouter o Matomo), acceder a la IU de Airflow después de que se actualice el entorno puede devolver una respuesta (500) Internal Server Error, con uno de los siguientes errores en los registros del servidor web de Airflow:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Cuando se configura [webserver]analytics_tool en Airflow 2, el servidor web de Airflow requiere que también se definan las opciones de estadísticas complementarias en la sección [webserver] cuando se renderiza la IU de Airflow.

En Airflow 3, se quitan las opciones de configuración [webserver]analytics_tool, [webserver]analytics_id y [webserver]analytics_url.

Soluciones:

  • Quita la anulación de la opción de configuración de Airflow [webserver]analytics_tool.
  • Especifica todas las opciones de configuración de Airflow requeridas juntas:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (obligatorio en Airflow 2.9 y versiones posteriores, incluso si tu herramienta de estadísticas no usa una URL personalizada)

Cuando se coloca el cursor sobre la instancia de tarea en la vista de árbol, se genera un TypeError no detectado

En Airflow 2, es posible que la vista de árbol en la IU de Airflow no funcione correctamente cuando se usa una zona horaria no predeterminada. Como solución alternativa para este problema, configura la zona horaria de forma explícita en la IU de Airflow.

La IU de Airflow en Airflow 2.2.3 o versiones anteriores es vulnerable a CVE-2021-45229

Como se indica en CVE-2021-45229, la pantalla "Activar DAG con configuración" era susceptible a ataques de XSS a través del argumento de consulta origin.

Recomendación: Actualiza a la versión más reciente de Managed Airflow que admita Airflow 2.2.5.

Los trabajadores requieren más memoria que en las versiones anteriores de Airflow

Síntomas:

  • En tu entorno de Managed Airflow (2ª gen.), todas las cargas de trabajo del clúster del entorno de los trabajadores de Airflow están en el estado CrashLoopBackOff y no ejecutan tareas. También puedes ver las advertencias de OOMKilling que se generan si este problema te afecta.

  • Este problema puede impedir las actualizaciones del entorno.

Causa:

  • Si usas un valor personalizado para la opción de configuración de Airflow [celery]worker_concurrency y la configuración de memoria personalizada para los trabajadores de Airflow, es posible que experimentes este problema cuando el consumo de recursos se acerque al límite.
  • Los requisitos de memoria de los trabajadores de Airflow en Airflow 2.6.3 con Python 3.11 son un 10% más altos en comparación con los trabajadores de versiones anteriores.
  • Los requisitos de memoria de los trabajadores de Airflow en Airflow 2.3 y versiones posteriores son un 30% más altos en comparación con los trabajadores de Airflow 2.2 o Airflow 2.1.

Soluciones:

  • Quita la anulación de worker_concurrency para que Managed Airflow calcule este valor automáticamente.
  • Si usas un valor personalizado para worker_concurrency, establécelo en un valor más bajo. Puedes usar el valor calculado automáticamente como punto de partida.
  • Como alternativa, puedes aumentar la cantidad de memoria disponible para los trabajadores de Airflow.
  • Si no puedes actualizar tu entorno a una versión posterior debido a este problema, aplica una de las soluciones propuestas antes de actualizar.

Activación de DAG a través de redes privadas con Cloud Run Functions

Managed Airflow no admite la activación de DAG con funciones de Cloud Run a través de redes privadas con el uso del conector de VPC.

Recomendación: Usa Cloud Run Functions para publicar mensajes en Pub/Sub. Estos eventos pueden activar sensores de Pub/Sub para activar DAG de Airflow o implementar un enfoque basado en operadores diferibles.

Carpetas vacías en el programador y los trabajadores

Managed Airflow no quita de forma activa las carpetas vacías de los trabajadores y programadores de Airflow. Estas entidades se pueden crear como resultado del proceso de sincronización del bucket del entorno cuando estas carpetas existían en el bucket y, con el tiempo, se quitaron.

Recomendación: Ajusta tus DAG para que estén preparados para omitir esas carpetas vacías.

Estas entidades se quitan de los almacenamientos locales de los programadores y trabajadores de Airflow cuando se reinician estos componentes (por ejemplo, como resultado de operaciones de reducción de escala o mantenimiento en el clúster de tu entorno).

Compatibilidad con Kerberos

Managed Airflow no admite la configuración de Kerberos de Airflow.

Compatibilidad con clases de procesamiento en Managed Airflow (2ª gen.) y Managed Airflow (3ª gen.)

Airflow administrado (3ª gen.) y Airflow administrado (2ª gen.) solo admiten la clase de procesamiento de uso general. Esto significa que no es posible ejecutar Pods que soliciten otras clases de procesamiento (como Equilibrada o Escalamiento horizontal).

La clase de uso general permite ejecutar Pods que soliciten hasta 110 GB de memoria y hasta 30 CPU (como se describe en Solicitudes máximas de clase de procesamiento).

Si quieres usar una arquitectura basada en ARM o necesitas más CPU y memoria, debes usar una clase de procesamiento diferente, que no se admite en los clústeres de Managed Airflow (Gen 3) ni de Managed Airflow (Gen 2).

Recomendación: Usa GKEStartPodOperator para ejecutar Pods de Kubernetes en un clúster diferente que admita la clase de procesamiento seleccionada. Si ejecutas Pods personalizados que requieren una clase de procesamiento diferente, también deben ejecutarse en un clúster de Managed Airflow.

Asistencia para operadores de Google Campaign Manager 360

Los operadores de Google Campaign Manager en las versiones de Managed Airflow anteriores a la 2.1.13 se basan en la API de Campaign Manager 360 v3.5, que dejó de estar disponible y su fecha de baja es el 1 de mayo de 2023.

Si usas operadores de Google Campaign Manager, actualiza tu entorno a la versión 2.1.13 o posterior de Managed Airflow.

Asistencia para operadores de Google Display & Video 360

Los operadores de Google Display & Video 360 en las versiones de Managed Airflow anteriores a la 2.1.13 se basan en la API de Display & Video 360 v1.1, que está obsoleta y su fecha de baja es el 27 de abril de 2023.

Si usas operadores de Google Display & Video 360, actualiza tu entorno a la versión 2.1.13 o posterior de Managed Airflow. Además, es posible que debas cambiar tus DAG porque algunos de los operadores de Google Display & Video 360 están obsoletos y se reemplazaron por otros nuevos.

  • Se dio de baja GoogleDisplayVideo360CreateReportOperator. En su lugar, usa GoogleDisplayVideo360CreateQueryOperator. Este operador devuelve query_id en lugar de report_id.
  • Se dio de baja GoogleDisplayVideo360RunReportOperator. En su lugar, usa GoogleDisplayVideo360RunQueryOperator. Este operador devuelve query_id y report_id en lugar de solo report_id, y requiere query_id en lugar de report_id como parámetro.
  • Para verificar si un informe está listo, usa el nuevo sensor GoogleDisplayVideo360RunQuerySensor que utiliza los parámetros query_id y report_id. El sensor GoogleDisplayVideo360ReportSensor obsoleto solo requería report_id.
  • GoogleDisplayVideo360DownloadReportV2Operator ahora requiere los parámetros query_id y report_id.
  • En GoogleDisplayVideo360DeleteReportOperator, no hay cambios que puedan afectar tus DAG.

Restricciones de nombres de rangos secundarios

CVE-2023-29247 (la página de detalles de la instancia de tarea en la IU es vulnerable a una XSS almacenada)

La IU de Airflow en las versiones de Airflow de la 2.0.x a la 2.5.x es vulnerable a CVE-2023-29247.

Si usas una versión de Managed Airflow anterior a la 2.4.2 y sospechas que tu entorno podría ser vulnerable al exploit, lee la siguiente descripción y las posibles soluciones.

En Managed Airflow, el acceso a la IU de Airflow está protegido con IAM y el control de acceso de la IU de Airflow.

Esto significa que, para aprovechar la vulnerabilidad de la IU de Airflow, los atacantes primero deben obtener acceso a tu proyecto junto con los permisos y roles de IAM necesarios.

Solución:

El DAG de supervisión de Airflow del entorno de Composer de Managed Airflow (2ª gen.) no se vuelve a crear después de borrarlo

El DAG de supervisión de Airflow no se vuelve a crear automáticamente si el usuario lo borra o lo mueve del bucket en entornos con composer-2.1.4-airflow-2.4.3.

Solución:

  • Esto se corrigió en versiones posteriores, como composer-2.4.2-airflow-2.5.3. El enfoque sugerido es actualizar tu entorno a una versión más reciente.
  • Una solución alternativa o temporal para una actualización del entorno sería copiar el DAG airflow_monitoring de otro entorno con la misma versión.

No es posible reducir el almacenamiento de Cloud SQL

Managed Airflow usa Cloud SQL para ejecutar la base de datos de Airflow. Con el tiempo, el almacenamiento en disco de la instancia de Cloud SQL puede crecer porque el disco se escala para adaptarse a los datos almacenados por las operaciones de Cloud SQL cuando crece la base de datos de Airflow.

No es posible reducir el tamaño del disco de Cloud SQL.

Como solución alternativa, si quieres usar el tamaño de disco de Cloud SQL más pequeño, puedes volver a crear entornos de Managed Airflow con instantáneas.

La métrica de uso del disco de la base de datos no se reduce después de quitar registros de Cloud SQL

Las bases de datos relacionales, como Postgres o MySQL, no quitan físicamente las filas cuando se borran o actualizan. En su lugar, las marca como "tuplas inactivas" para mantener la coherencia de los datos y evitar el bloqueo de transacciones simultáneas.

Tanto MySQL como Postgres implementan mecanismos para recuperar espacio después de borrar registros.

Si bien es posible forzar a la base de datos a recuperar el espacio en el disco sin usar, esta es una operación que consume muchos recursos y que, además, bloquea la base de datos, lo que hace que Managed Airflow no esté disponible. Por lo tanto, se recomienda confiar en los mecanismos de compilación para recuperar el espacio no utilizado.

Acceso bloqueado: error de autorización

Si este problema afecta a un usuario, el diálogo Acceso bloqueado: Error de autorización contiene el mensaje Error 400: admin_policy_enforced.

Si la opción Controles de API > Apps de terceros no configuradas > No permitir que los usuarios accedan a ninguna app de terceros está habilitada en Google Workspace y la app de Apache Airflow en Managed Airflow no está permitida de forma explícita, los usuarios no pueden acceder a la IU de Airflow, a menos que permitan la aplicación de forma explícita.

Para permitir el acceso, sigue los pasos que se indican en Permite el acceso a la IU de Airflow en Google Workspace.

Bucle de acceso cuando se accede a la IU de Airflow

Este problema puede deberse a las siguientes causas:

Las instancias de tareas que se realizaron correctamente en el pasado se marcaron como FALLIDAS

En algunas circunstancias y situaciones poco frecuentes, las instancias de tareas de Airflow que se realizaron de forma correcta en el pasado se pueden marcar como FAILED.

Si esto sucede, por lo general, se activó por una operación de actualización o actualización del entorno, o por el mantenimiento de GKE.

Nota: El problema en sí no indica ningún problema en el entorno y no causa fallas reales en la ejecución de la tarea.

El problema se solucionó en la versión 2.6.5 o posterior de Managed Airflow.

Los componentes de Airflow tienen problemas cuando se comunican con otras partes de la configuración de Managed Airflow

Este problema solo se aplica a las versiones 2.10.2 y anteriores de Managed Airflow (2ª gen.).

En casos muy excepcionales, la lentitud de la comunicación con el servidor de metadatos de Compute Engine puede hacer que los componentes de Airflow no funcionen de forma óptima. Por ejemplo, es posible que se deba reiniciar el programador de Airflow, que se deban volver a intentar las tareas de Airflow o que el tiempo de inicio de la tarea sea más largo.

Síntomas:

Los siguientes errores aparecen en los registros de los componentes de Airflow (como los programadores, los trabajadores o el servidor web de Airflow):

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

Solución:

  • Actualiza tu entorno a una versión posterior de Managed Airflow. Este problema se corrigió a partir de la versión 2.11.0 de Managed Airflow.

La carpeta /data no está disponible en el servidor web de Airflow

En Managed Airflow (2ª gen.) y Managed Airflow (3ª gen.), el servidor web de Airflow está diseñado para ser un componente principalmente de solo lectura, y Managed Airflow no sincroniza la carpeta data/ con este componente.

En ocasiones, es posible que quieras compartir archivos comunes entre todos los componentes de Airflow, incluido el servidor web de Airflow.

Solución:

  • Une los archivos que se compartirán con el servidor web en un módulo de PYPI y, luego, instálalo como un paquete de PYPI normal. Después de instalar el módulo de PyPI en el entorno, los archivos se agregan a las imágenes de los componentes de Airflow y están disponibles para ellos.

  • Agrega archivos a la carpeta plugins/. Esta carpeta se sincroniza con el servidor web de Airflow.

Diagramas de tiempos de análisis de DAG no continuos y de tamaño de bolsa de DAG en la supervisión

Los diagramas de tiempos de análisis de DAG no continuos y de tamaño de bolsa de DAG en el panel de supervisión indican problemas con tiempos de análisis de DAG largos (más de 5 minutos).

Gráficos de tiempos de análisis de DAG de Airflow y de tamaño de DAG bag que muestran una serie de intervalos no continuos
Figura 1. Gráficos de tiempos de análisis de DAG no continuos y tamaño de la bolsa de DAG (haz clic para ampliar)

Solución: Recomendamos mantener el tiempo total de análisis de DAG en menos de 5 minutos. Para reducir el tiempo de análisis de los DAG, sigue los lineamientos para escribir DAG.

Faltan los registros de los componentes de Managed Airflow en Cloud Logging

Hay un problema en el componente del entorno responsable de subir los registros de los componentes de Airflow a Cloud Logging. A veces, este error provoca una situación en la que puede faltar el registro a nivel de Managed Airflow para un componente de Airflow. El mismo registro sigue disponible en el nivel de componente de Kubernetes.

Ocurrencia del problema: muy poco frecuente, esporádica

Causa:

Comportamiento incorrecto del componente de Managed Airflow responsable de subir registros a Cloud Logging.

Soluciones:

  • Actualiza tu entorno a la versión 2.10.0 o posterior de Managed Airflow.

  • En las versiones anteriores de Managed Airflow, la solución temporal cuando te encuentras con esta situación es iniciar una operación de Managed Airflow que reinicie los componentes para los que falta el registro.

No se admite el cambio del clúster del entorno a GKE Enterprise Edition

Esta nota se aplica a Managed Airflow 1 y Managed Airflow 2.

El clúster de GKE del entorno de Managed Airflow se crea en GKE Standard Edition.

A partir de diciembre de 2024, el servicio de Managed Airflow no admite la creación de entornos de Managed Airflow con clústeres en Enterprise Edition.

Los entornos de Managed Airflow no se probaron con GKE Enterprise Edition y tienen un modelo de facturación diferente.

En el segundo trimestre de 2025, se enviarán más comunicaciones relacionadas con la edición GKE Standard en comparación con la edición Enterprise.

Componentes de Airflow que tienen problemas para comunicarse con otras partes de la configuración de Managed Airflow

En algunos casos, debido a una resolución de DNS con errores, los componentes de Airflow pueden experimentar problemas cuando se comunican con otros componentes de Managed Airflow o extremos de servicio fuera del entorno de Managed Airflow.

Síntomas:

Los siguientes errores pueden aparecer en los registros de los componentes de Airflow (como los programadores, los trabajadores o el servidor web de Airflow):

google.api_core.exceptions.ServiceUnavailable: 503 DNS resolution failed ...
... Timeout while contacting DNS servers

o

Could not access *.googleapis.com: HTTPSConnectionPool(host='www.googleapis.com', port=443): Max retries exceeded with url: / (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7c5ef5adba90>: Failed to resolve 'www.googleapis.com' ([Errno -3] Temporary failure in name resolution)"))

o

redis.exceptions.ConnectionError: Error -3 connecting to
airflow-redis-service.composer-system.svc.cluster.local:6379.
Temporary failure in name resolution.

Soluciones posibles:

  • Actualiza a Managed Airflow 2.9.11 o

  • Establece la siguiente variable de entorno: GCE_METADATA_HOST=169.254.169.254.

El entorno se encuentra en estado de ERROR después de que se borró o desactivó la cuenta de facturación del proyecto, o se inhabilitó la API de Cloud Composer

Los entornos de Managed Airflow afectados por estos problemas no se pueden recuperar:

  • Después de que se borró o desactivó la cuenta de facturación del proyecto, incluso si se vinculó otra cuenta más adelante.
  • Después de que se inhabilitó la API de Cloud Composer en el proyecto, incluso si se habilitó más tarde.

Puedes hacer lo siguiente para solucionar el problema:

  • Aún puedes acceder a los datos almacenados en los buckets de tu entorno, pero los entornos en sí ya no se pueden usar. Puedes crear un nuevo entorno de Managed Airflow y, luego, transferir tus DAGs y datos.

  • Si deseas realizar alguna de las operaciones que hacen que tus entornos no se puedan recuperar, asegúrate de crear una copia de seguridad de tus datos, por ejemplo, creando una instantánea del entorno. De esta manera, puedes crear otro entorno y transferir sus datos cargando esta instantánea.

Advertencias sobre el presupuesto de interrupción de Pods para los clústeres de entorno

Puedes ver las siguientes advertencias en la IU de GKE para los clústeres de entornos de Managed Airflow:

GKE can't perform maintenance because the Pod Disruption Budget allows
for 0 Pod evictions. Update the Pod Disruption Budget.

A StatefulSet is configured with a Pod Disruption Budget but without readiness
probes, so the Pod Disruption Budget isn't as effective in gauging application
readiness. Add one or more readiness probes.

No es posible eliminar estas advertencias. Trabajamos para evitar que se generen estas advertencias.

Soluciones posibles:

  • Ignora estas advertencias hasta que se solucione el problema.

No se puede quitar un valor de campo en una conexión de Airflow

Causa:

La interfaz de usuario de Apache Airflow tiene una limitación por la que no es posible actualizar los campos de conexión a valores vacíos. Cuando intentas hacerlo, el sistema vuelve a la configuración guardada anteriormente.

Soluciones posibles:

Si bien la versión 2.10.4 de Apache Airflow incluye una corrección permanente, existe una solución temporal para los usuarios de versiones anteriores. Esto implica borrar la conexión y, luego, volver a crearla, específicamente dejando vacíos los campos obligatorios. La interfaz de línea de comandos es el enfoque recomendado para borrar la conexión:

gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
connections delete -- \
CONNECTION_ID

Después de borrar la conexión, vuelve a crearla con la IU de Airflow y asegúrate de que los campos que quieres dejar vacíos estén en blanco. También puedes crear la conexión ejecutando el comando connections add de la CLI de Airflow con Google Cloud CLI.

No se recopilan los registros de las tareas de Airflow si [core]execute_tasks_new_python_interpreter se establece en True

Managed Airflow no recopila registros de las tareas de Airflow si la opción de configuración de Airflow [core]execute_tasks_new_python_interpreter está establecida en True.

Solución posible:

  • Quita la anulación de esta opción de configuración o establece su valor en False.

Faltan datos en las métricas, ValueError: No se puede determinar la ruta sin el nombre del bucket

Los entornos con las versiones 2.16.0 y 2.16.1 de Managed Airflow (2ª gen.) pueden experimentar un problema conocido con los informes de métricas. Puedes observar algunos puntos de datos omitidos en las métricas informadas y ver mensajes de error sobre los reinicios del Pod de airflow-monitoring en los registros del entorno.

Ejemplo de un mensaje de error: ValueError: Cannot determine path without bucket name error.

Este problema no afecta la funcionalidad del entorno. El entorno sigue operativo y la información de supervisión y estado del entorno se informa correctamente. Puedes ignorar los mensajes de error.

Rendimiento degradado del entorno en varias versiones del paquete google-api-core

Versiones de la 2.28.0 a la 2.30.2

Las versiones del paquete preinstalado google-api-core de la 2.28.0 a la 2.30.2 podrían provocar una degradación del rendimiento del entorno, lo que puede generar tiempos más largos para ejecutar una tarea y tiempos más largos para mover una tarea del estado en cola al estado de ejecución.

Las imágenes de contenedor base para las compilaciones afectadas ahora están parchadas, por lo que los entornos creados recientemente no se ven afectados. Solo se verán afectados los entornos existentes que no hayan actualizado sus imágenes de contenedor desde el 4 de noviembre de 2026.

Compilaciones de Managed Airflow (3ª gen.) afectadas:

  • composer-3-airflow-3.1.7-build.0 a composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 a composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • De composer-3-airflow-2.10.5-build.22 a composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 a composer-3-airflow-2.9.3-build.53

Compilaciones de Managed Airflow (2ª gen.) afectadas:

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 a composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 a composer-2.16.10-airflow-2.9.3

Soluciones:

Para mitigar este problema en un entorno existente, actualiza a una imagen lanzada el 6 de noviembre de 2026 o después de esa fecha (que incluye google-api-core 2.43.1), actualiza a una de las siguientes compilaciones (que incluyen google-api-core 2.27.0) o sigue los pasos de mitigación de autoservicio en Versiones de la 2.30.3 a la 2.43.0 en Python 3.11:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

Versiones de la 2.30.3 a la 2.43.0 en Python 3.11

A partir del 24 de octubre de 2026, las versiones 2.30.3 a 2.43.0 del paquete google-api-core (así como las versiones 2.28.0 a 2.30.2) ejecutan una verificación de baja de Python 3.11 que analiza los metadatos del paquete instalado cada vez que se importa una biblioteca cliente de Google Cloud en un nuevo subproceso de Python.

En los entornos de Managed Airflow que ejecutan Python 3.11, este comportamiento puede degradar el rendimiento, en especial en entornos que tienen muchos DAG, tareas frecuentes de corta duración o la integración de linaje de datos habilitada.

Estado:

  • Se corrigió en las versiones del 6 de noviembre de 2026 y posteriores: Las imágenes composer-3-airflow-3.3.1-build.6, composer-3-airflow-3.2.2-build.10, composer-3-airflow-2.11.1-build.23, composer-2.17.17-airflow-2.11.1 y posteriores preinstalan google-api-core 2.43.1, lo que corrige este problema.
  • Imágenes base con parches para compilaciones anteriores: Las imágenes de contenedor base para todas las compilaciones afectadas que se indican en esta sección se corrigieron en todas las regiones. Los entornos recién creados no se ven afectados, incluso si los creas con una compilación anterior.
  • Entornos existentes: Los entornos creados antes del 5 de noviembre de 2026 siguen usando imágenes de contenedor almacenadas en caché hasta que se actualicen a través del mantenimiento programado o uno de los pasos de mitigación de esta sección.

Entre los síntomas, se incluyen los siguientes:

  • Aumento de los tiempos de análisis de DAG y mayor uso de CPU en los procesadores de DAG de Airflow.
  • Tiempos de ejecución de tareas más largos y mayor uso de CPU en los trabajadores de Airflow.
  • Entradas de registro frecuentes de FutureWarning de google/api_core/_python_version_support.py que indican que la compatibilidad con Python 3.11 finaliza el 24 de octubre de 2027.

Antes de la actualización de la imagen, este problema afectaba a los entornos de Python 3.11 en los que se preinstalaba o instalaba manualmente la versión 2.30.3 a 2.43.0 de google-api-core, incluidas las siguientes compilaciones.

Compilaciones de Managed Airflow (3ª gen.) afectadas:

  • composer-3-airflow-3.3.1-build.0 a composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 a composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 a composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 a composer-3-airflow-3.1.7-build.13
  • De composer-3-airflow-2.11.1-build.3 a composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 a composer-3-airflow-2.10.5-build.52

Compilaciones de Managed Airflow (2ª gen.) afectadas:

  • composer-2.17.0-airflow-2.11.1 a composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 a composer-2.17.13-airflow-2.10.5

Mitigación para entornos existentes:

Elige una de las siguientes opciones en cualquier región:

  • Opción 1: Actualiza tu entorno. Actualiza a composer-2.17.17-airflow-2.11.1 o a otra versión posterior de la imagen de Managed Airflow (2ª gen.).

  • Opción 2: Activa una actualización del paquete de PyPI (requiere acceso al repositorio de PyPI). Actualiza un paquete de PyPI personalizado existente o instala un paquete adicional para volver a compilar la imagen del entorno sobre la imagen base parcheada y reiniciar todos los Pods de Airflow. No instales google-api-core>=2.43.1 directamente en imágenes de composer-2.17.16 o anteriores, ya que requiere opentelemetry-api>=1.44.0 y causa conflictos de dependencia.

  • Opción 3 (solución alternativa sin actualizar ni cambiar los paquetes de PyPI): Aplica un parche de entorno de ejecución de sitecustomize.py. Usa esta opción si, por ejemplo, tu entorno usa los Controles del servicio de VPC sin acceso al repositorio de PyPI y no puedes actualizar de inmediato:

    1. Descarga sitecustomize.py desde GitHub.

    2. Sube sitecustomize.py a la carpeta dags/patches en el bucket de tu entorno.

    3. Establece la variable de entorno PYTHONPATH como /home/airflow/gcs/dags/patches.

      Si ya se estableció PYTHONPATH, antepón /home/airflow/gcs/dags/patches: al valor existente. Ejemplo: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Limpieza: Después de actualizar tu entorno o volver a compilar su imagen con los pasos anteriores, puedes quitar la anulación de PYTHONPATH y borrar dags/patches/sitecustomize.py.

¿Qué sigue?