Foro

Hola,

Hemos revisado el estado real de K8s en su nuevo servidor y hemos encontrado la causa raíz: las especificaciones del servidor de destino son insuficientes:

• El servidor que compró (Tencent Tokyo 2C 2GB) tiene actualmente la memoria totalmente consumida por Gitea + svn-server (uso ~120%).
• La clonación del proyecto requiere iniciar 3 Pods adicionales de "migración de volumen (pvmover-restore)" para mover el volumen del proyecto antiguo, pero se han quedado atascados en Pending durante más de 3 horas. Mensaje de K8s: 0/1 nodes are available: 1 Insufficient memory.

Sobre la contradicción de que "cada elemento muestra completado, pero el estado general muestra fallido":

Las 4 marcas de verificación verdes en el panel de progreso solo indican que la plataforma ha "iniciado" estas etapas, no que el trabajo subyacente haya terminado.

• "Clone Started", "Deployment: Template deployed", "Clone Completed: new project ready" y "Volume Copy: Starting" son etapas de inicialización que se activan en el primer segundo.
• El trabajo real de migración de datos se ejecuta después como un Job de K8s en su nuevo servidor, y vemos que esos Jobs están atascados en Pending esperando memoria indefinidamente.
• Los eventos posteriores como "X completed" o "X failed" para la copia de volumen solo aparecen después de que el Job real termine o se agote el tiempo de espera de 6 horas. Hasta entonces, la interfaz no añadirá nuevas marcas verdes, pero el banner de "fallido" podría aparecer debido a un tiempo de espera de sondeo (polling timeout), causando la contradicción visual de "todo completado pero muestra fallido".

Independientemente de lo que muestre la interfaz, el bloqueador real es la falta de memoria. Soluciones recomendadas:

Método A (Muy recomendado): Actualizar las especificaciones del servidor de destino Sugerimos actualizar al menos a 2C 4GB, idealmente 2C 8GB. Después de actualizar, elimine el proyecto bmp-tatous fallido y vuelva a activar la "Clonación de proyecto" desde el origen (cgk1).

Método B: Pausar Gitea y svn-server en el servidor de destino, esperar a que termine la migración del volumen y luego reiniciar

1. Entre en el nuevo proyecto (bmp-tatous) y pause (Pause) Gitea y svn-server.
2. Espere a que pvmover-restore pase de Pending a Running y termine.
3. Reinicie Gitea y svn-server.

Esto es solo una solución temporal; ejecutar estos servicios con 2GB seguirá dando problemas a largo plazo.

Gracias por tu ayuda, el problema ya está resuelto. Me encanta este producto.

Sugiero que, para los escenarios de migración, se pueda evaluar primero si las especificaciones del servidor de destino cumplen con los requisitos.