Problemas conocidos en el entorno flexible de App Engine

Para ver una lista completa de los problemas conocidos o informar de un problema nuevo, consulta el gestor de incidencias.

• Después de desplegar tu aplicación con gcloud app deploy, es posible que tengas que esperar entre 1 y 2 minutos para que empiece a funcionar en https://PROJECT_ID.REGION_ID.r.appspot.com. Mientras tanto, es posible que veas errores HTTP 503.

  App Engine suele registrar estos errores como backend_timeout o failed_to_pick_backend en los registros del balanceador de carga de aplicación externo global. El balanceador de carga de aplicación externo global envía solicitudes a un servicio del entorno flexible de App Engine, independientemente del estado de las instancias individuales. Después de implementar una nueva versión, el balanceador de carga de aplicación externo global tarda un tiempo en actualizar su configuración con las nuevas instancias de backend. Durante esta transición, la disponibilidad de los servicios de backend es inconsistente. Al migrar el tráfico a la nueva versión, el balanceador de carga de aplicación externo global puede intentar enviar tráfico a instancias que no estén totalmente preparadas para recibir solicitudes, lo que provoca errores 503. Esto también puede provocar errores 502, sobre todo si se usa un balanceador de carga de aplicación clásico.

• Si hay una política de la organización en tu proyecto que restringe el acceso a IPs externas, no podrás desplegar una aplicación del entorno flexible de App Engine con direcciones IP externas. Por ejemplo, la política de la organización podría tener el siguiente aspecto:

  • La política efectiva de constraints/compute.vmExternalIpAccess se ha definido como DENY_ALL.
  • La política efectiva de constraints/compute.vmExternalIpAccess se ha configurado para permitir solo instancias de VM específicas.
  • La política efectiva de constraints/compute.requireOsConfig está inhabilitada en el proyecto para evitar que se actualicen los metadatos.

  Estas restricciones no se detectan automáticamente, por lo que las implementaciones pueden agotar el tiempo de espera y fallar. Para consultar la política de la organización de tu proyecto, ejecuta el comando gcloud beta resource-manager org-policies describe compute.vmExternalIpAccess --project=my-project --effective. También puedes anular la política de la organización en un proyecto concreto.

  Sin embargo, aunque se hayan definido estas políticas de organización, puedes desplegar una aplicación de entorno flexible de App Engine privada que solo use su dirección IP interna.

• Después de desplegar una nueva versión de un servicio en el entorno flexible de App Engine con gcloud app deploy, es posible que la métrica "Recuento/seg." que se muestra en el gráfico "Resumen" del panel de control de App Engine disminuya considerablemente. La métrica volverá gradualmente al recuento de solicitudes esperado en los próximos 5-10 minutos.

  Esto no significa que tu aplicación esté atendiendo menos solicitudes. Cuando despliega una nueva versión de su aplicación, hay un retraso entre el momento en que la nueva versión está lista para atender solicitudes y el momento en que las métricas de las nuevas instancias están disponibles.

  Para asegurarte de que esta métrica no se vea afectada por la implementación de una nueva versión, sigue estos pasos:

  1. Implementa la nueva versión con gcloud app deploy --no-promote.
  2. Espera 15 minutos después de que se complete el despliegue.
  3. Migra el tráfico a la nueva versión.

  Si despliegas con --no-promote, pero asignas cualquier cantidad de tráfico a la nueva versión antes de que transcurran 15 minutos desde que se complete el despliegue, esta métrica puede verse afectada.

• En el entorno flexible de App Engine, no se puede configurar app.yaml para que tu aplicación redirija automáticamente las solicitudes para que siempre usen HTTPS. Esto es diferente del entorno estándar de App Engine, donde puedes usar el ajuste secure.

  Como alternativa, puedes gestionar la redirección en el código de tu aplicación analizando el valor del encabezado X-Forwarded-Proto. También puedes animar a los clientes a que usen el encabezado Strict-Transport-Security.

• Si asignas una cuenta de servicio gestionada por el usuario a una versión del entorno flexible de App Engine, es posible que se te facture por las métricas con el prefijo agent.googleapis.com. Normalmente, estas métricas de agente no se cobran a tu proyecto. Te recomendamos que sigas usando la cuenta de servicio predeterminada de App Engine hasta que se resuelva este problema.

• No puedes establecer una conexión SSH con una instancia de VM mediante IAP.

Reducción inesperada del número de instancias

• En raras ocasiones, tu aplicación podría experimentar una reducción inesperada del número de instancias debido a fallos en las zonas o si un grupo completo de instancias deja de responder. Para evitarlo, Google recomienda aprovisionar en exceso tu aplicación para que tu sistema no se quede por debajo del número mínimo de instancias. Puedes definir el tamaño de min_num_instances de tu aplicación del entorno flexible de App Engine al desplegarla. Estos son algunos de los eventos que pueden afectar al número mínimo de instancias del entorno flexible de App Engine:

  1. Lanzar actualizaciones en instancias del entorno flexible
  2. Fallo de zona (problemas de falta de stock, como cuando tu región ha alcanzado la capacidad de la CPU que has seleccionado, etc.)

  El entorno flexible de App Engine usa 3 zonas para distribuir las instancias. En esta configuración, recomendamos aprovisionar un 50% más de instancias de las necesarias.

Métricas de Cloud Load Balancing incoherentes

El panel de control del entorno flexible de App Engine muestra todas las métricas solo de las solicitudes que se han enrutado a través de un backend gestionado del entorno flexible. Si usas el entorno flexible de App Engine con Cloud Load Balancing, algunas métricas de la tabla de métricas de App Engine se registran como métricas de la tabla loadbalancing. Para obtener más información, consulta Registro y monitorización del balanceo de carga HTTP(S).

InterruptedException en tiempos de ejecución que usan JVM durante un fallo en la comprobación del estado

Cuando falla una comprobación del estado, la VM se apaga. Como síntoma de que el contenedor de la aplicación no funciona correctamente, la JVM responde con errores InterruptedException y NullPointerException. Un controlador puede responder a la señal SIGTERM que envía el contenedor durante el cierre para realizar las acciones de limpieza o depuración necesarias y evitar excepciones.