Mi servicio se queda atascado en el estado Starting. Cada vez que vuelvo a desplegar, cambia a Running, pero al día siguiente vuelve a estar en Starting.
Mi servicio se queda atascado en el estado Starting. Cada vez que vuelvo a desplegar, cambia a Running, pero al día siguiente vuelve a estar en Starting.
¡Hola! Hemos revisado kubectl y tu pod de frontend está actualmente en ejecución (37h), pero observamos un patrón en el que se ejecuta durante un tiempo y luego se detiene (estado: Completed), lo que provoca que se cree un nuevo pod.
Esto sugiere que tu aplicación se está cerrando correctamente después de un tiempo (no se está bloqueando). Posibles causas:
¿Podrías comprobar si tu aplicación de frontend tiene un proceso de servidor de larga duración o si se cierra después de compilar? Además, ¿con qué framework está construida?
Hola equipo de soporte de Zeabur,
¡Gracias por revisar esto!
1. Framework: La aplicación está construida con Vite.
2. Proceso de servidor de larga duración:
Según mis registros, después de que termina la compilación, la aplicación se sirve usando Caddy (puedo ver {"logger":"http.log.access.log0", ... "resp_headers":{"Server":["Caddy"]}} devolviendo exitosamente estados 200 para mi index.html y mis assets).
Posible causa:
Debido a que Caddy está sirviendo las solicitudes, sospecho que el problema es que Caddy se está iniciando como un proceso en segundo plano (por ejemplo, usando caddy start) en lugar de en primer plano (por ejemplo, caddy run o caddy file-server). En entornos contenedorizados, si el proceso principal pasa a segundo plano, el contenedor asume que el trabajo ha terminado y se cierra limpiamente (Estado: Completed). Esto coincide perfectamente con el comportamiento de que el pod se detiene y activa uno nuevo.
Aquí hay un fragmento de mis registros que muestra la compilación de Vite y a Caddy sirviendo solicitudes con éxito antes de cerrarse:
codeText
#11 0.770 vite v6.4.1 building for production...
#11 2.216 ✓ 90 modules transformed.
#11 2.473 dist/index.html 2.95 kB │ gzip: 1.07 kB
#11 2.473 dist/assets/index-DlWlCsOa.js 500.73 kB │ gzip: 142.18 kB
...
{"level":"info","msg":"handled request", ... "status":200,"resp_headers":{"Server":["Caddy"]}}
Próximos pasos: ¿Podrían aconsejarme cómo ajustar mi configuración (o el script de inicio de package.json / Dockerfile) para que el servidor estático permanezca adjunto al primer plano y mantenga el pod vivo correctamente?
¿Podría decirme si el sitio web se verá afectado si se queda atascado en "iniciando" (como si se hubiera apagado repentinamente)? ¿O realmente no tiene ningún efecto en mi sitio web sin importar cuánto tiempo se quede atascado, y es solo una señal? Espero poder obtener su respuesta lo antes posible, ya que este sitio web ya está lanzado oficialmente. ¡Gracias!
This post has been inactive for a while. We will be closing it in 2 days if there is no new activity.
Las nuevas respuestas están deshabilitadas para problemas resolved.