Aplicaciones¶
El panel de control muestra las aplicaciones del namespace actual, una tarjeta por aplicación.
El catálogo¶
El botón Nueva app abre el catálogo de plantillas disponibles, por categoría:
| Categoría | Plantillas |
|---|---|
| Procesamiento | Apache Hop (GUI), Apache Hop Server, Trino, Spark Connect, Apache NiFi |
| Almacenamiento | PostgreSQL |
| Visualización | Digdash BI |
| Gobernanza | Apache Iceberg (catálogo Polaris), OpenMetadata |
| Ciencia de datos | JupyterHub, MLflow |
| DevOps | nginx (sitio estático) |
Las plantillas Apache Iceberg, Trino y JupyterHub se combinan en un lakehouse sobre los buckets S3 de la plataforma — véase Lakehouse.
Forgejo, un caso aparte
El servidor Git Forgejo no aparece en este catálogo: es una aplicación transversal a la plataforma (una única instancia para todo el clúster), gestionada desde Ajustes → Git — véase Git.
Anatomía de una tarjeta¶
Cada tarjeta muestra:
- el nombre (o el nombre para mostrar si se ha personalizado), la plantilla y la imagen desplegada;
- el estado:
Running,Pending(iniciando),Stopped,Error; - los indicadores de CPU y RAM: consumo real respecto a los recursos solicitados;
- la fecha de creación y el autor del despliegue.
Entender los indicadores de CPU y RAM¶
Cada indicador muestra el consumo real del pod (obtenido del servidor de métricas del clúster) en relación con su límite si la aplicación tiene uno, o si no, con su cantidad solicitada (requested) — véase Configurar una aplicación para la diferencia entre ambos.
0,85 / 2,00 cores: 0,85 núcleos consumidos para un límite de 2 núcleos.3,2 Gi / 4,0 Gi: 3,2 Gi de RAM consumidos para un límite de 4 Gi.n/d: el servidor de métricas del clúster aún no tiene medición para este pod (reinicio reciente, por ejemplo) — el indicador permanece en gris.
El color de la barra indica el nivel de consumo respecto a ese tope:
| Color | Umbral | Significado |
|---|---|---|
| 🟢 Verde azulado | < 60 % | Consumo normal |
| 🟠 Ámbar | 60 % – 79 % | Se acerca al tope — vigilar |
| 🔴 Rojo | ≥ 80 % | Cerca o en el tope — la aplicación puede verse limitada (CPU) o eliminada por el kernel (memoria, OOMKill) |
En la captura anterior, la CPU (42,5 % del límite) permanece en verde azulado mientras que la RAM (80 % del límite) pasa a rojo — es la señal para aumentar el límite de memoria de la aplicación desde Configurar.
Acciones disponibles¶
Según la plantilla y el estado de la aplicación:
| Acción | Efecto |
|---|---|
| Abrir (enlace externo) | Acceder a la aplicación desplegada en una nueva pestaña |
| Métricas (enlace externo) | Abrir el dashboard Grafana de la aplicación (pod o namespace) — presente si la supervisión de la plataforma está instalada, ver Clúster |
| Detener / Iniciar | Detener o reiniciar la aplicación sin eliminarla |
| Reiniciar | Reiniciar los pods (rollout) |
| Configurar | Modificar el nombre para mostrar, los recursos, las variables… — véase Configurar |
| Ver detalles | Pods, servicios, rutas, información de conexión interna |
| Gestionar acceso | Autorizar a otros usuarios — véase Acceso y permisos |
| Eliminar | Desinstalar la release (confirmación reescribiendo el nombre, irreversible) |
Acciones específicas de determinadas plantillas¶
- Prueba de compatibilidad de la API (Digdash BI, Apache Hop Server, Forgejo): comprueba de extremo a extremo que la API de la aplicación responde, con un resultado detallado por punto de control (insignia Saludable o Degradado).
- Resincronizar conexiones Hop (Apache Hop GUI): regenera de inmediato los archivos de metadatos del proyecto Hop (conexiones a las bases PostgreSQL, a los servidores Hop y a los buckets del namespace), sin esperar a la sincronización periódica.
- Resincronizar conexiones DigDash (Digdash BI): reaprovisiona las conexiones internas de Audit / Comentarios / Formulario hacia el PostgreSQL integrado.
- Jobs de Hop (Apache Hop Server): seguimiento y lanzamiento de los pipelines y workflows programados — véase Apache Hop Server: jobs y planificación para más detalle.