Proyecto Final Integrador · Arquitectura de Computadoras 2
Mantenimiento predictivo con IA que sigue respondiendo cuando un nodo se apaga
Un clúster K3s de tres mini PC Intel clasifica lecturas de temperatura y vibración de un motor, sin depender de la nube. El proyecto mide qué pasa con el servicio cuando se desconecta un worker.
3 mini PC1 master + 2 workersNodePort 30080Datos sintéticos
El problema
Una máquina que falla sin aviso detiene el trabajo, y la nube no siempre está al alcance
El mantenimiento predictivo busca detectar el desgaste de un motor antes de que se averíe. Para que sirva, la clasificación tiene que ocurrir rápido, cerca de la máquina y sin interrupciones.
La avería llega sin aviso
Sin una lectura continua de temperatura y vibración, el desgaste solo se nota cuando el motor ya falló.
Depender de la nube
Enviar cada lectura a un servicio remoto añade latencia y deja de funcionar si se pierde la conexión a Internet.
Un solo equipo es un riesgo
Si la IA corre en una sola máquina y esa máquina se cae, se pierde también la vigilancia del motor.
Objetivo del proyectoComprobar que un clúster pequeño de tres mini PC ejecuta IA de mantenimiento predictivo en el borde y sigue respondiendo cuando uno de sus nodos se desconecta.
| Opción | Dónde corre la IA | Si se pierde Internet | Si cae un equipo |
|---|---|---|---|
| Servicio en la nube | Servidores remotos | Deja de clasificar | Depende del proveedor |
| Un solo equipo local | Cerca de la máquina | Sigue funcionando | Se pierde el servicio |
| Clúster edge con K3s | Cerca de la máquina, en 3 mini PC | Sigue funcionando: 30 lecturas con el router desconectado | El otro worker sigue respondiendo |
La solución
Clasifica el estado de un motor en tres categorías
Un servicio de inferencia HTTP recibe lecturas simuladas de temperatura y vibración y responde con el estado probable del motor. Corre dentro del clúster, cerca de la máquina, para reducir latencia y no depender de Internet.
Operación estable
Temperatura y vibración dentro del rango esperado. No requiere acción.
Degradación visible
Las señales empiezan a desviarse. Conviene programar una revisión.
Riesgo de avería
Las señales indican una falla cercana. Requiere atención inmediata.
Los datos son sintéticos. Las métricas del modelo describen su desempeño sobre datos simulados, no sobre una máquina real. Las latencias de los modelos se midieron en la computadora donde se entrenó, no en los mini PC.
Arquitectura
Del sensor simulado a la respuesta, dentro del clúster
Cada petición recorre el mismo camino. Si un worker falla, el cliente reintenta contra el otro.
Simulador
simulator.pygenera lecturas de temperatura y vibración y las envía por HTTP.NodePort
El servicio de Kubernetes expone el puerto
30080en cada worker.Pod de inferencia
La imagen Docker
edge-infercarga el modelo y clasifica la lectura.Respuesta
El cliente recibe
normal,desgasteofalla_inminente.
K3s
Kubernetes liviano: 1 master y 2 workers sobre Ubuntu Server 24.04 en mini PC Intel Atom x5-Z8350 de 64 bits.
Anti-afinidad de pods
Los dos pods se reparten, uno por worker. Si un worker cae, el pod de reemplazo queda en espera por la regla estricta.
Prueba de caída
failover_test.py envía peticiones durante 150 s, desconectando un worker a los 30 s, y calcula éxito, latencia y ventanas sin servicio.
Simulación
Provócale una falla al clúster y míralo responder
Cada punto es una petición del simulador de sensores. Sigue el recorrido guiado o usa los controles para apagar nodos, cortar Internet y comparar las políticas del servicio.
Todo funciona
Motor (valores ilustrativos)
Qué está pasando
Es una simulación didáctica. Los comportamientos vienen de las pruebas del proyecto: unos 40 s hasta que Kubernetes retira un nodo caído, 3 intentos por petición, 0,8 s de espera por intento fallido, latencia normal cercana a 28 ms (mediana) y pod de reemplazo en Pending. Los valores del motor, la nube y la reincorporación de un nodo son ilustrativos y no se midieron.
Resultados
Con la política Local no se perdió ninguna petición
El equipo desconectó un worker a los 30 s de corridas de 150 s y comparó dos políticas del servicio. Tres corridas por política, alternando el worker desconectado.
Peticiones sin respuesta por corrida
Con Cluster, kube-proxy puede enviar una petición al pod del worker caído hasta que Kubernetes retira ese endpoint, unos 40 s por defecto. Con Local, cada worker responde solo con su propio pod.
Local, frente a ≈267–280 con ClusterPending con el worker caídoPrueba inicial con la política por defecto
| Corrida | Worker desconectado | Peticiones | Éxito final | Primer intento | Mediana / p95 | Mayor ventana sin servicio |
|---|---|---|---|---|---|---|
| 1 | worker1 | 118 | 106 (89,83 %) | 90 (76,27 %) | 28,0 / 833,6 ms | 2,6 s |
| 2 | worker2 | 118 | 106 (89,83 %) | 92 (77,97 %) | 28,8 / 843,9 ms | 5,1 s |
Las cifras de las series A y B se leyeron de las gráficas y son aproximadas. Se pueden recalcular con python analizar_csv.py archivo.csv --cut-at 30. Con el cable al router desconectado, el simulador completó 30 lecturas: el servicio funciona sin Internet.
Alcance
Qué no se midió
El repositorio separa lo medido de lo que queda como referencia.
Datos simulados
Ninguna métrica proviene de un motor real. El objetivo es la infraestructura, no el diagnóstico industrial.
Sondas y tolerancias de 15 s
Las mejoras de k8s/ con sondas de salud y tolerancias aún no se midieron en el clúster.
Prometheus y Grafana
No se desplegaron en los mini PC para no sobrecargar su RAM ni su CPU. Quedan como referencia en monitoring/.
Pocas repeticiones
Hay una sola corrida inicial por condición y tres por serie, así que no se estima la variación entre repeticiones.
Conclusión
Lo que aprendimos del montaje
Las tres conclusiones salen de las pruebas hechas en los mini PC reales.
La política de tráfico importa
Con externalTrafficPolicy: Local no se perdió ninguna petición al desconectar un worker. Con Cluster se perdieron 11 a 13 por corrida.
El borde funciona aislado
Con el cable al router desconectado, el simulador completó 30 lecturas. La clasificación no depende de la nube.
Cabe en equipos modestos
Cada worker usó cerca de 580 MB de sus 1 571 MB de memoria, con el servicio bajo carga.
Lo que queda por hacer
- Con un worker caído, el pod de reemplazo quedó en
Pendingdurante 76 s por la anti-afinidad estricta, así que el servicio corre con un solo pod hasta que el nodo vuelve. - Medir las sondas de salud y las tolerancias de 15 s del directorio
k8s/. - Desplegar Prometheus y Grafana en un equipo con más memoria y repetir las pruebas con datos reales de un motor.
Equipo
Quiénes lo hicieron
- Kleiver Jedidias García Guarcas
- Ricardo Ismael Pérez Ajanel
- Allan David Alessandro Racancoj López
- Pablo Javier Sandoval
Universidad Mariano Gálvez de Guatemala · Proyecto Final Integrador de Arquitectura de Computadoras 2.
Probarlo
Funciona en una laptop, sin los mini PC
El repositorio incluye el código, los manifiestos de K3s y los pasos para reproducir el montaje completo. Necesitas Python 3.11 o superior para la prueba local.
git clone https://github.com/Paxmer/edge-cluster-k3s cd edge-cluster-k3s python3 -m venv .venv && source .venv/bin/activate pip install -r requirements.txt python train.py python -m unittest discover -s tests -v