2026-06-09 Reinicio inesperado del servicio ap-east-2 y PostgreSQL, interrupción de DB de 68 minutos

Servicios afectados

Environment: environment-698804602579f38ed02c5e4e
App service: service-69921d789fdcdd695840c0ea (nombre del contenedor: stock-trend)
PostgreSQL: tpe1.clusters.zeabur.com:28618
Nodo regional: ip-172-31-90-136.ap-east-2.compute.internal, etc.

【Cronología (UTC)】

13:52:18: El pod de la aplicación fue eliminado (no fue una acción nuestra; nuestro reinicio programado es a las 06:00 UTC, el cual se ejecutó normalmente ese día).
13:52:33: El nuevo pod presentó FailedCreatePodSandBox: plugin type="aws-cni" failed (add): failed to assign an IP address to container.
14:01:21: PostgreSQL se cerró (detectado mediante el monitoreo de la plataforma).
14:01 ~ 15:09: La aplicación recibió continuamente "server closed the connection unexpectedly". El uso de CPU/memoria de la DB era totalmente normal antes del incidente (pico de CPU 1.16%, pico de memoria 197MB), descartando OOM.
15:09: La DB se recuperó y el servicio volvió a la normalidad automáticamente.

【Preguntas】

¿Hubo algún mantenimiento de nodo o node drain en ap-east-2 entre las 13:52 y las 14:01 UTC? ¿Por qué el pod de la aplicación y la DB se reiniciaron fuera de nuestro horario programado?
¿Por qué tomó aproximadamente 68 minutos restaurar la conexión después del reinicio de la DB? ¿Está relacionado con el fallo de asignación de IP de aws-cni en ese momento (agotamiento del pool de IP del nodo)?
¿Tiene nuestro servicio PostgreSQL algún reinicio programado a nivel de plataforma o mal configurado actualmente? (Por favor, ayúdennos a verificar; si es así, desactívenlo).
¿Existe alguna notificación previa o página de estado a la que podamos suscribirnos para futuros mantenimientos de la plataforma?

Adjunto: Registro de tiempo de ejecución (runtime log) del día (archivo completo disponible bajo petición).

Hola, hemos identificado la causa raíz de este incidente. Aquí tienes la respuesta punto por punto:

1. ¿Hubo mantenimiento/drenaje de nodos entre las 13:52 y las 14:01? ¿Por qué se reinició fuera del horario configurado? Sí. Ese día, entre las 13:38 y las 13:52 (UTC), el clúster ap-east-2 (AWS) realizó una ronda de rotación de nodos: varios nodos subyacentes fueron terminados (el registro de eventos indica "el nodo ya no existe en el proveedor de la nube") y se iniciaron nuevos nodos para tomar el relevo. Tu aplicación y el Pod de PostgreSQL fueron reprogramados en los nuevos nodos recién añadidos debido a que los nodos originales fueron eliminados. Por lo tanto, este reinicio no tiene relación con tu reinicio programado a las 06:00; fue una reprogramación inesperada causada por la rotación de nodos de la plataforma.

2. ¿Por qué la base de datos tardó unos 68 minutos en recuperarse? ¿Está relacionado con el fallo de asignación de IP de aws-cni? Sí, hay dos causas principales y ambas están relacionadas:

Cuando los nuevos nodos se unieron, aws-cni aún no había preparado la red (pool de ENI/IP), y en ese momento hubo una gran cantidad de Pods reprogramados que llegaron simultáneamente (docenas de servicios en todo el clúster presentaron "failed to assign an IP address" al mismo tiempo), lo que provocó un cuello de botella en la asignación de IP y dejó a los Pods bloqueados sin poder establecer red.
Los nuevos nodos son "nodos fríos" sin caché de imágenes, por lo que fue necesario volver a descargar las imágenes. La imagen de tu PostgreSQL (postgres:18) tardó aproximadamente 1 hora y 7 minutos en descargarse (incluyendo el tiempo de espera), y la imagen de la aplicación unos 24 minutos (incluyendo el tiempo de espera). Estos dos periodos de espera son la razón principal por la que la interrupción se alargó a unos 68 minutos.

En otras palabras, esto no es un problema de la base de datos en sí (los datos de CPU/memoria que proporcionaste confirman que no hubo OOM), sino un proceso de recuperación demasiado largo debido a la "reprogramación + asignación de red + descarga de imágenes".

3. ¿Tiene PostgreSQL algún reinicio programado por parte de la plataforma o mal configurado? No. Este reinicio de la base de datos fue una reprogramación de Pod causada por la rotación de nodos mencionada anteriormente (cambio de nombre de Pod, descarga de imágenes), no un reinicio programado in-place. Tu servicio no tiene configuraciones de reinicio programado por parte de la plataforma, por lo que no hay nada que desactivar.

4. ¿Habrá notificaciones previas o una página de estado a la que suscribirse para este tipo de mantenimiento en el futuro? Los eventos de la plataforma se pueden consultar en la página de estado https://status.zeabur.com. Actualmente ofrecemos una suscripción RSS (https://status.zeabur.com/feed, que se puede añadir a un lector RSS o herramientas de notificación automática). Además, hemos reportado al equipo de infraestructura los problemas de cuello de botella en la asignación de IP de aws-cni durante la rotación de nodos y los tiempos de recuperación prolongados debido a la descarga de imágenes en nodos fríos. Mejoraremos los procesos de drenaje y precalentamiento de IP durante la rotación de nodos para reducir el tiempo de interrupción en situaciones similares en el futuro.

Sugerencia adicional: La raíz de esta interrupción es que los nodos de un "clúster compartido" rotan junto con el mantenimiento de la plataforma, lo que obliga a tus Pods a ser reprogramados en nodos recién iniciados. Si tu servicio requiere una alta estabilidad de conexión, puedes considerar cambiar a un Servidor Dedicado (Dedicated Server): los servidores dedicados son nodos independientes de inquilino único que no se incluyen en la rotación general de nodos de los clústeres compartidos, lo que reduce drásticamente el impacto de estas reprogramaciones inesperadas y los largos tiempos de recuperación; además, al tener caché de imágenes en el nodo, la recuperación tras el reinicio es mucho más rápida. Si te interesa, puedo ayudarte a evaluar las especificaciones adecuadas.

Foro

1 respuesta