Problemas conocidos

Cloud Composer 1 | Cloud Composer 2

En esta página, se enumeran los problemas conocidos de Cloud Composer. Algunas correcciones para estos problemas ya están en curso y estarán disponibles en versiones futuras.

Algunos problemas afectan a versiones anteriores y se pueden solucionar si actualizas tu entorno.

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

Cloud Composer depende de GKE a fin de proporcionar compatibilidad con direcciones que no sean RFC 1918 para los Pods y Services. Actualmente, solo se admite la siguiente lista de rangos que no son de RFC 1918 en Cloud Composer:

  • 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

La IU de Airflow no muestra los registros de tareas cuando la serialización de DAG está activada en Composer 1.10.2 y Composer 1.10.3

Habilitar la serialización de DAG en entornos mediante las versiones 1.10.2 y 1.10.3 evita que los registros se muestren en el servidor web de Airflow. Actualiza a la versión 1.0.4 (o posterior) para solucionar este problema.

Error de tarea intermitente durante la programación en Cloud Composer

El problema se observa en un programador de Airflow para la instancia de la tarea durante la ejecución de la tarea. Sin embargo, los registros no explican la causa de la falla de la tarea, y Airflow Worker y Airflow Scheduler parecían relativamente en buen estado.

El mensaje de error en el programador de Airflow puede parecerse al siguiente:

Executor reports task instance <TaskInstance: xx.xxxx scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the task says its queued. (Info: None) Was the task killed externally?

También puede haber algún error en el trabajador de Airflow similar al siguiente:

Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have finished abnormally (e.g. was evicted).

Para garantizar la solidez frente a estos errores derivados de un problema antiguo en Airflow, se recomienda implementar de forma proactiva las estrategias adecuadas de reintento en los niveles de tarea y DAG. Al incorporar estas medidas, el sistema puede mitigar eficazmente el impacto de estos errores, lo que mejora la confiabilidad y la resiliencia general del flujo de trabajo.

No se admite Workload Identity de GKE

Este problema solo se aplica a los entornos de Cloud Composer 1. Los entornos de Cloud Composer 2 usan Workload Identity.

No puedes activar Workload Identity para los clústeres de entorno de Cloud Composer. Como resultado, es posible que veas el resultado WORKLOAD_IDENTITY_DISABLED en Security Command Center.

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

Las etiquetas de entorno actualizadas no se aplican a las VMs de Compute Engine. Como solución alternativa, esas etiquetas se pueden aplicar de forma manual.

Actualizaciones de GKE en el contexto del problema CVE-2020-14386

Estamos trabajando para abordar la vulnerabilidad CVE-2020-14386 en todos los entornos de Cloud Composer. Como parte de la corrección, todos los clústeres de GKE de Cloud Composer existentes se actualizarán a una versión más reciente.

Los clientes que decidan abordar la vulnerabilidad de inmediato pueden actualizar el clúster de GKE de Composer siguiendo estas instrucciones con las siguientes consideraciones:

Paso 1: Si ejecutas una versión de Cloud Composer anterior a 1.7.2, deberás actualizar a una versión más reciente de Cloud Composer. Si ya cuentas con la versión 1.7.2 o superior, ve al siguiente punto.

Paso 2. Actualiza el clúster de GKE (instancia principal y nodos) a la última versión del parche 1.15 que contiene la corrección para esta vulnerabilidad.

Los registros de tareas de Airflow no están disponibles en el servidor web de Airflow después de actualizar de Airflow 1.9.0 a Airflow 1.10.x.

Airflow 1.10.x introdujo cambios incompatibles con versiones anteriores en la convención de nomenclatura para archivos de registro. Ahora, la información de las zonas se agrega a los nombres de registro de las tareas de Airflow.

Airflow 1.9.0 almacena y espera que los nombres de registro tengan el siguiente formato: BUCKET/logs/DAG/2020-03-30T10:29:06/1.log. Airflow 1.10.x almacena y espera que los nombres de registro tengan el siguiente formato: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Como resultado, si actualizas de Airflow 1.9.0 a Airflow 1.10.x y deseas leer el registro de una tarea ejecutada con Airflow 1.9.0, el servidor web de Airflow mostrará el siguiente mensaje de error: Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

Solución alternativa: Cambia el nombre de los registros que generó Airflow 1.9.0 en el depósito de Cloud Storage con el siguiente formato: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

No se pueden crear entornos de Cloud Composer con las restricciones de la política de la organización constraints/compute.disableSerialPortLogging enforced

La creación del entorno de Cloud Composer fallará si constraints/compute.disableSerialPortLogging se aplica 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:

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 Cloud Composer.

    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.

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

Composer usa el Administrador de implementaciones para crear componentes de entornos de Cloud Composer.

Es posible que en diciembre de 2020 se le haya informado que podría necesitar realizar una configuración adicional en los Controles del servicio de VPC para poder usar Deployment Manager a fin de administrar recursos protegidos por los Controles del servicio de VPC.

Nos gustaría aclarar que no se requiere ninguna acción de tu parte si usas Composer y no utilizas Deployment Manager directamente para administrar los recursos de Google Cloud que se mencionan en el anuncio de Deployment Manager.

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

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

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

Para borrar un entorno cuando su clúster de GKE ya fue borrado, sigue estos pasos:

  1. Abre la página Deployment Manager en la consola de Google Cloud.

    Abre la página de Administrador de implementación

  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 conserva 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 Cloud Composer.

El Administrador de implementaciones muestra información sobre una función no compatible

Es posible que veas la siguiente advertencia en la pestaña Administrador de implementaciones:

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

Si las implementaciones del Administrador de implementaciones son propiedad de Cloud Composer, puedes ignorar esta advertencia.

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 a fin de mejorar el servicio de Cloud Composer para quitar estas advertencias de los registros de Airflow.

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

En los proyectos que tienen habilitados los Controles del servicio de VPC, la cuenta cloud-airflow-prod@system.gserviceaccount.com requiere acceso explícito al 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 cloud-airflow-prod@system.gserviceaccount.com como miembro del perímetro de seguridad con la siguiente configuración en el archivo de condiciones YAML:

     - members:
        - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
    

La creación del entorno de Cloud Composer 1 falla cuando se habilita la política compute.requireOsLogin

Si estableces la política compute.requireOsLogin como true en tu proyecto, fallarán las operaciones de creación del entorno de Cloud Composer 1 v1.

Para crear entornos de Cloud Composer 1, inhabilita esta política en tu proyecto.

Para obtener más información sobre esta política de la organización, consulta Restricciones de la política de la organización.

La creación o actualización del entorno de Cloud Composer falla cuando se inhabilita compute.vmExternalIpAccess

Los clústeres de GKE que son propiedad de Cloud Composer y están configurados en el modo de IP pública requieren conectividad externa para las VM. 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 las restricciones de las políticas de la organización.

La creación del entorno de Cloud Composer falla cuando la política compute.vmCanIpForward está inhabilitada.

Los entornos de Cloud Composer 1 creados en el modo que no es nativo de la VPC (con alias de IP) requieren esta política para permitir la creación de VM con la función habilitada de “reenvío de IP”. Para obtener más información sobre esta política de la organización, consulta las 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. Estas sincronizaciones se realizan de forma independiente. 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.

Como solución alternativa, los entornos de Airflow 2 en Cloud Composer 1.17.0-preview.9 y versiones posterioresversions están configurados para realizar dos reintentos para una tarea con errores de forma predeterminada. Si una tarea falla, se vuelve a intentar dos veces con intervalos de 5 minutos.

Para usar la solución alternativa a este problema en Airflow 1, haz lo siguiente:anula core-default_task_retriesAirflow: Opción de configuración y configúrala en un número mayor o igual que 2.

La tarea falla debido al error “Error de SO: [Errno 5] Error de entrada/salida” en las versiones 1.10.15 o anteriores de Airflow

Un error en las versiones de Airflow 1 hace que las tareas se coloquen en la cola de Redis dos veces en casos excepcionales.

A veces, puede generar una condición de carrera en el archivo de registro y una falla posterior de la tarea. Las tareas fallan con OSError: [Errno 5] Input/output error en Cloud Logging y Task is in the 'running' state which is not a valid state for execution. en el registro de intentos de la tarea.

Este error se corrige en Airflow 2. Si encuentras este problema en Airflow 1 en una tarea de larga duración, aumenta el valor de la opción de configuración de Airflow [celery_broker_transport_options]visibility_timeout (el valor predeterminado). es 604800 para Composer 1.17.0, 21600 para entornos anteriores). Para tareas de corta duración, considera agregar reintentos adicionales a las tareas afectadas o migrar tu entorno a Airflow 2.

Los operadores de Dataproc/Dataflow fallan debido al error Negsignal.SIGSEGV

Este es un problema intermitente de la biblioteca grcpio, cuando se usa desde un trabajador de Celery. Este problema afecta a Airflow 1.10.14 y versiones posteriores.

La solución alternativa es cambiar la estrategia de sondeo grpcioy agregar la siguiente variable de entorno a tu entorno: GRPC_POLL_STRATEGY=epoll1. Esta solución alternativa ya se aplicó en Cloud Composer 1.17.1 y versiones posteriores.

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

Cloud Composer administra los clústeres de GKE que son de su propiedad. 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. Cloud Composer se encarga de cualquier migración, si es necesario.

Actualizaciones de GKE en el contexto del problema de seguridad CVE-2021-25741

Todos los clústeres de GKE existentes de Cloud Composer se actualizarán automáticamente a versiones más recientes de GKE con una solución para los problemas descritos en CVE-2021-25741.

Si deseas abordar esta vulnerabilidad de inmediato, actualiza el clúster de GKE de tu entorno mediante las instrucciones para actualizar un clúster.

  • Si tienes un entorno de Cloud Composer 1 y una versión de GKE 1.18.x o anterior, actualiza a la versión 1.18.20-gke.4501.

  • Si tienes un entorno de Cloud Composer 1 y una versión de GKE 1.19.x, actualiza a 1.19.14-gke.301.

  • Si tienes un entorno de Cloud Composer 2 y una versión de GKE 1.21.x, actualiza a 1.21.4-gke.301.

Cloud Composer no debería verse afectado por la vulnerabilidad de Apache Log4j 2 (CVE-2021-44228)

En respuesta a la vulnerabilidad de Apache Log4j 2 (CVE-2021-44228), Cloud Composer realizó una investigación detallada y creemos que Cloud Composer no es vulnerable a este exploit.

Cloud Composer 2: Los trabajadores o programadores de Airflow pueden experimentar problemas cuando acceden a los buckets de Cloud Storage

En algunas situaciones esporádicas, en el caso de los entornos de Cloud Composer 2 cuando se reinicia el trabajador o el programador de Airflow, es posible que falle y tenga problemas cuando se accede al contenido del bucket de Cloud Storage.

En esa situación, es posible que veas errores que comienzan con Transport endpoint is not connected en los registros de Airflow.

Por ejemplo, el registro de errores del trabajador de Airflow podría verse de la siguiente manera:

[Errno 107] Transport endpoint is not connected: '/home/airflow/gcs/logs/airflow_monitoring/echo/2022-01-11T22:50:48+00:00'

Solución:

  • Actualiza a Cloud Composer 2.0.26 o una versión más reciente

Es posible que, a veces, la IU de Airflow no vuelva a cargar un complemento una vez que se modifique.

Si un complemento consiste en muchos archivos que importan otros módulos, es posible que la IU de Airflow no pueda reconocer que se debe volver a cargar un complemento. En ese caso, es necesario activar un reinicio del servidor web de Airflow. Puedes hacerlo si agregas una variable de entorno o si instalas o desinstalas dependencias de PYPI. También puedes reiniciar el servidor web de Airflow.

Problemas intermitentes durante la comunicación con la base de datos de metadatos de Airflow

Este problema conocido solo se aplica a Cloud Composer 1.

Es posible que algunos entornos más antiguos de Cloud Composer 1 (1.16.3 o anteriores) creados antes del 12 de agosto de 2021 experimenten problemas transitorios relacionados con la comunicación con las bases de datos de metadatos de Airflow.

Si experimentas este problema, en los registros de tareas de Airflow verás el siguiente mensaje de error:

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

El equipo de Cloud Composer trabaja para resolver este problema. Mientras tanto, si crees que este problema te afectó mucho, puedes hacer lo siguiente para eliminarlo:

  1. En la consola de Google Cloud, ve a la página Configuración del entorno de los entornos de Cloud Composer afectados.
  2. Sigue el vínculo Ver detalles del clúster para navegar al clúster de GKE subyacente del entorno.
  3. Navega a la pestaña Nodos y haz clic en el default-pool visible en la sección Grupos de nodos. seleccionar grupo-predeterminado
  4. Haz clic en Editar, en la parte superior de la página.
  5. Cambia el tipo de imagen a Container-Optimized OS con containerd y guarda la configuración como se muestra a continuación. Cambia el tipo de imagen del grupo de nodos de Docker a containerd
  6. Una vez que se envíe el cambio, tu grupo de nodos default-pool se volverá a configurar para usar containerd como su entorno de ejecución de contenedor. Algunas de tus tareas de Airflow pueden fallar mientras se vuelve a configurar el grupo de nodos. Si esas tareas tienen reintentos configurados, Airflow volverá a ejecutarlas una vez que se complete la operación en el grupo de nodos.

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

Este problema conocido solo se aplica a Cloud Composer 2.

En Cloud Composer 2, después de que se crea un entorno, varias cargas de trabajo en el clúster del entorno permanecen en el estado No programable.

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

En esta situación, el escalador automático del clúster agrega más nodos, lo que tarda algunos minutos. Hasta que finalice, 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 pueden iniciarse en nodos en los que los componentes de Airflow no están presentes no afectan tu entorno.

Si este problema persiste durante mucho tiempo (más de 1 hora), puedes verificar 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 tomó el escalador automático del clúster: expande cualquier noDecisionStatus para ver el motivo por el que no se puede escalar o reducir verticalmente la escala del clúster.

Error 504 cuando se accede a la IU de Airflow

El error 504 Gateway Timeout puede generarse 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 adelante. También puedes reiniciar el servidor web de Airflow.
  • Problema de conectividad (solo Cloud Composer 2). Si la IU de Airflow no está disponible de forma permanente y se generan errores 504 o tiempo de espera, 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 private.googleapis.com o Controles del servicio de VPC y envías tráfico a través de IP virtuales restricted.googleapis.com, asegúrate de que Cloud DNS también esté configurado para nombres de dominio *.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 entregar solicitudes entrantes. Este error puede tener varias causas:

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

  • Se produjo un error al iniciar el servidor web. Para comenzar, el servidor web requiere que los archivos de configuración se sincronicen primero. Verifica los registros del servidor web para buscar entradas de registro que sean similares a: GCS sync exited with 1: gsutil -m cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp o GCS sync exited with 1: gsutil -m 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 aún están presentes en el bucket del entorno.

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

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

    2. Anular una opción de configuración de Airflow Puedes usar una opción de configuración de Airflow que no existe.

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

Como se señaló 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 Cloud Composer que admita Airflow 2.2.5.

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

Síntomas:

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

  • 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% mayores en comparación con los trabajadores en versiones anteriores.
  • Los requisitos de memoria del trabajador de Airflow en Airflow 2.3 y versiones posteriores son un 30% mayores en comparación con los trabajadores de Airflow 2.2 o Airflow 2.1.

Soluciones:

  • Quita la anulación de worker_concurrency para que Cloud Composer 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 de forma automática 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 la actualización.

Activación de DAG mediante redes privadas con Cloud Functions

Cloud Composer no admite la activación de DAG con Cloud Functions a través de redes privadas con el uso del conector de VPC.

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

Problemas con los comandos de gcloud composer en la versión 410.0.0

En la versión 410.0.0 de gcloud, se aplican los siguientes comandos de Cloud Composer:

  • gcloud composer environments run
  • gcloud composer environments list-packages

devolverá un código de error distinto de cero y mostrará el siguiente mensaje de error:

  (ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)

Este comportamiento se produce además de los resultados habituales que producen los comandos de gcloud y no afecta su funcionalidad.

Si este problema no afecta a tus operaciones, puedes seguir usando la versión 410.0.0 e ignorar el mensaje de error incorrecto. Si necesitas usar la versión 410.0.0 y utilizas el comando de gcloud de manera programática, implementa una lógica adicional para ignorar el código de error distinto de cero y la información sobre el seguimiento de pila de errores en el resultado. También puedes consultar la sección Solución para descubrir otras soluciones alternativas.

Solución

Carpetas vacías en el programador y los trabajadores

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

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

Con el tiempo, estas entidades se quitan de los almacenamientos locales de los programadores y trabajadores de Airflow cuando se reinician estos componentes (p.ej., como resultado de las operaciones de reducción de escala o de mantenimiento en el clúster de Cloud Composer).

Compatibilidad con Kerberos

Cloud Composer aún no admite la configuración de Kerberos de Airflow.

Compatibilidad con clases de procesamiento en Cloud Composer 2

Cloud Composer 2 solo admite clases de procesamiento de uso general. Significa que no es posible ejecutar Pods que soliciten otras clases de procesamiento (como Balanced o Scale-Out).

La clase de uso general permite ejecutar Pods que soliciten hasta 110 GB de memoria y hasta 30 CPU (como se describe en Solicitudes de máximo 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 es compatible con los clústeres de Cloud Composer 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 que no sea Cloud Composer 2.

Asistencia para operadores de Google Campaign Manager 360

Los operadores de Google Campaign Manager de las versiones de Cloud Composer 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 desactivación 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 Cloud Composer.

Compatibilidad con los operadores de Google Display and Video 360

Los operadores de Google Display & Video 360 en las versiones de Cloud Composer anteriores a la 2.1.13 se basan en la API de Display & Video 360 v1.1 que está obsoleta y su fecha de desactivación es el 27 de abril de 2023.

Si usas los operadores de Google Display & Video 360, actualiza tu entorno a la versión 2.1.13 o posterior de Cloud Composer. 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.

  • GoogleDisplayVideo360CreateReportOperator dejó de estar disponible. En su lugar, usa GoogleDisplayVideo360CreateQueryOperator. Este operador muestra query_id en lugar de report_id.
  • GoogleDisplayVideo360RunReportOperator dejó de estar disponible. En su lugar, usa GoogleDisplayVideo360RunQueryOperator. Este operador muestra query_id y report_id en lugar de 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 usa 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 a 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 un XSS almacenado)

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

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

En Cloud Composer, 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 explotar la vulnerabilidad de la IU de Airflow, los atacantes primero deben obtener acceso a tu proyecto junto con los permisos y las funciones de IAM necesarios.

Solución:

  • Verifica los permisos y roles de IAM en tu proyecto, incluidos los roles de Cloud Composer asignados a usuarios individuales. Asegúrate de que solo los usuarios aprobados puedan acceder a la IU de Airflow.

  • Verifica las funciones asignadas a los usuarios a través del mecanismo de control de acceso a la IU de Airflow (este es un mecanismo independiente que proporciona acceso más detallado a la IU de Airflow). Asegúrate de que solo los usuarios aprobados puedan acceder a la IU de Airflow y de que todos los usuarios nuevos estén registrados con un rol adecuado.

  • Considera un endurecimiento adicional con los Controles del servicio de VPC.

Después de la eliminación, el DAG de supervisión de Airflow del entorno de Cloud Composer 2 no se vuelve a crear.

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

Solución:

  • Este problema 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.

Las operaciones de actualización pueden fallar si Sentry está habilitado

La operación de actualización para un entorno de Cloud Composer puede fallar si configuraste Sentry en tu entorno y estableciste la configuración [sentry]sentry_on como true.

Solución:

  • Desactiva Sentry en tu entorno, realiza la actualización y vuelve a configurar Sentry.

No es posible reducir el almacenamiento en Cloud SQL

Cloud Composer usa Cloud SQL para ejecutar la base de datos de Airflow. Con el tiempo, el almacenamiento en disco para la instancia de Cloud SQL podría crecer debido a que el disco escala verticalmente 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 deseas usar el tamaño de disco más pequeño de Cloud SQL, puedes volver a crear entornos de Cloud Composer 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 filas de forma física cuando se borran o actualizan. En cambio, los marca como “tuplas muertas” para mantener la coherencia de los datos y evitar el bloqueo de transacciones simultáneas.

MySQL y Postgres implementan mecanismos de recuperación de espacio después de borrar registros.

Si bien es posible forzar a la base de datos a recuperar espacio en disco sin usar, esta es una operación que requiere muchos recursos y, además, bloquea la base de datos, por lo que Cloud Composer no está disponible. Por lo tanto, te recomendamos que utilices los mecanismos de compilación para recuperar el espacio sin usar.

Acceso bloqueado: Error de autorización

Si este problema afecta a un usuario, el diálogo Acceso bloqueado: Error de autorización contendrá 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 Apache Airflow en la app de Cloud Composer no está permitido 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.

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

En algunas circunstancias y situaciones poco frecuentes, las instancias de tareas de Airflow que tuvieron éxito en el pasado se pueden marcar como FAILED.

Si ocurre, por lo general, se activó mediante una actualización del entorno o una operación de actualización, o por un mantenimiento de GKE.

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

El problema se solucionó en Cloud Composer 2.6.5 o versiones posteriores.

Los componentes de Airflow tienen problemas cuando se comunican a otras partes de la configuración de Cloud Composer

En casos muy poco frecuentes, la lentitud de la comunicación con el servidor de metadatos de Compute Engine puede provocar que los componentes de Airflow no funcionen de manera óptima. Por ejemplo, el programador de Airflow podría reiniciarse, las tareas de Airflow deban reintentarse o el tiempo de inicio de la tarea podría ser más largo.

Síntomas:

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

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

Solution:

Configura la siguiente variable de entorno: GCE_METADATA_TIMEOUT=30.

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

En Cloud Composer 2, el servidor web de Airflow está diseñado principalmente como un componente de solo lectura, y Cloud Composer no sincroniza la carpeta data/ con este componente.

A veces, es posible que desees compartir archivos comunes entre todos los componentes de Airflow, incluido el servidor web de Airflow.

Solution:

  • 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. Una vez que el módulo de PYPI se instala 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 está sincronizada con el servidor web de Airflow.

¿Qué sigue?