Después de las 9:30 p. m. del 9/6, el servicio parece haberse cerrado solo.
Lo redeployé manualmente el 10/6.
¿Podrían revisar los logs para averiguar por qué el servicio se cerró por sí mismo?
ForoNavegación
Plantillas
ForoForoDespués de las 9:30 p. m. del 9/6, el servicio parece haberse cerrado solo.
Lo redeployé manualmente el 10/6.
¿Podrían revisar los logs para averiguar por qué el servicio se cerró por sí mismo?
Hola, hemos investigado la causa de esta interrupción basándonos en los registros del backend. Aquí está la explicación:
Esto no fue un problema con su código o configuración. La aplicación funcionaba perfectamente antes de la interrupción (la última solicitud fue alrededor del 9/6 a las 21:22, sin errores, bloqueos o falta de memoria).
La causa real de la interrupción fue un reemplazo masivo de nodos en el clúster compartido (región Taipei) durante la noche del 9/6. La cronología de los eventos (hora de Taipei) es la siguiente:
Listening on http://0.0.0.0:8080), se quedó atascado en un estado de terminación (FailedKillPod / DeadlineExceeded) mientras el proceso de reemplazo del nodo aún era inestable. Esto causó que el servicio permaneciera anormal hasta que usted lo volvió a desplegar manualmente el 10/6.Actualmente, el servicio se está ejecutando de forma estable en el nuevo nodo (Running, 0 reinicios) y se encuentra en estado normal. Puede estar tranquilo.
Con respecto al tiempo inusualmente largo de descarga de la imagen, proporcionaremos comentarios a nuestro equipo de infraestructura para revisar y minimizar el impacto de futuros reemplazos de nodos en los servicios.
Si su servicio requiere una alta estabilidad y desea evitar el impacto de los reemplazos de nodos en el clúster compartido, puede considerar actualizar a un Dedicated Server (servidor dedicado), donde los recursos y los nodos están aislados de forma independiente.
Si tiene alguna otra pregunta, por favor abra una nueva publicación. ¡Gracias!