UD3 · Instalación de aplicaciones de despliegue

Objetivos de la unidad

Al finalizar esta unidad el alumno sera capaz de:

• Identificar las aplicaciones del ecosistema MLOps necesarias segun el Plan de aprovisionamiento
• Instalar y configurar orquestadores de contenedores, registros de artefactos y herramientas de monitorización
• Configurar relaciones entre aplicaciones: claves de API, volumenes, permisos y politicas
• Verificar la compatibilidad entre versiones de modelo, entorno y dependencias
• Mantener el inventario actualizado y documentar la instalacion con sus logs

Resultado de aprendizaje: Instala y configura las aplicaciones del Plan de aprovisionamiento para desplegar sistemas de IA.

El ecosistema de aplicaciones MLOps

Mapa de aplicaciones por categoria

┌─────────────────────────────────────────────────────────────┐
│                    CAPA DE ORQUESTACION                     │
│           Kubernetes · Docker Swarm · Nomad                 │
├──────────────────────┬──────────────────────────────────────┤
│  REGISTRO            │  MONITORIZACIÓN                      │
│  Harbor              │  Prometheus + Grafana                │
│  JFrog Artifactory   │  Datadog · New Relic                 │
│  MLflow Registry     │  ELK Stack (logs)                    │
├──────────────────────┼──────────────────────────────────────┤
│  BALANCEO DE CARGA   │  SECRETOS                            │
│  NGINX · HAProxy     │  HashiCorp Vault                     │
│  AWS ALB · Traefik   │  AWS Secrets Manager                 │
├──────────────────────┴──────────────────────────────────────┤
│             FEATURE STORE / ALMACEN DE DATOS                │
│              Feast · Tecton · Hopsworks                     │
└─────────────────────────────────────────────────────────────┘

Orquestadores de contenedores: Kubernetes

Por que Kubernetes para despliegues de IA

Kubernetes (K8s) es el estandar de facto para orquestar contenedores en produccion. Para sistemas de IA aporta:

# Recurso de GPU en un Pod de Kubernetes
resources:
  limits:
    nvidia.com/gpu: 1
    memory: "32Gi"
    cpu: "8"

Instalacion de Kubernetes: componentes clave

Arquitectura del cluster para MLOps

┌─────────────────────────────────┐
│         NODO MASTER             │
│  API Server · Scheduler         │
│  Controller Manager · etcd      │
└─────────────┬───────────────────┘
              │
    ┌─────────┴──────────┐
    │                    │
┌───┴──────────┐  ┌──────┴──────────┐
│  NODO CPU    │  │  NODO GPU        │
│  (API, web,  │  │  (inferencia,    │
│  frontend)   │  │  entrenamiento)  │
└──────────────┘  └─────────────────┘

Instalacion con kubeadm (on-premise)

# En el nodo master
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
# Aplicar CNI (Flannel)
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# Instalar el plugin de dispositivos NVIDIA para GPU
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/nvidia-device-plugin.yml

Registros de artefactos y modelos

Funcion y diferencias entre tipos de registro

Instalacion de MLflow con backend en PostgreSQL y S3

# Instalar MLflow con extras de base de datos y almacenamiento
pip install mlflow[extras]==2.11.0

# Iniciar el servidor de seguimiento
mlflow server \
  --backend-store-uri postgresql://mlflow:password@db:5432/mlflow \
  --default-artifact-root s3://ml-artifacts/ \
  --host 0.0.0.0 --port 5000

Sistemas de monitorización y alarma

Stack Prometheus + Grafana: instalacion con Helm

# Agregar el repositorio de Helm de la comunidad
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Instalar el stack completo (Prometheus + Grafana + Alertmanager)
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitorización --create-namespace \
  --set grafana.adminPassword="cambiar-en-produccion" \
  --set prometheus.prometheusSpec.retention=30d

Configuracion de un exportador personalizado para el modelo

# Exportador Prometheus para metricas del modelo de inferencia
from prometheus_client import Histogram, Counter, start_http_server

latencia_inferencia = Histogram('model_latency_seconds',
    'Latencia de inferencia', buckets=[.05, .1, .25, .5, 1.0, 2.5])
predicciones_total = Counter('model_predictions_total', 'Total de predicciones')

Balanceadores de carga

Comparativa de balanceadores para APIs de inferencia

Configuracion de NGINX para un servicio de inferencia

upstream inferencia_backend {
    least_conn;
    server inferencia-01:8080 weight=1;
    server inferencia-02:8080 weight=1;
    keepalive 32;
}
server {
    listen 443 ssl;
    location /predict { proxy_pass http://inferencia_backend; }
}

Gestion de secretos

Por que los secretos no deben estar en el codigo ni en los ficheros de configuracion

Los secretos (claves de API, contrasenas, certificados) almacenados en repositorios Git son la principal causa de filtraciones de credenciales. La gestion correcta exige:

1. Nunca escribir secretos en ficheros de configuracion versionados
2. Usar un gestor de secretos dedicado (Vault, AWS Secrets Manager, Azure Key Vault)
3. Rotar los secretos periodicamente de forma automatica
4. Auditar cada acceso a los secretos

HashiCorp Vault: flujo de uso

# 1. Almacenar un secreto
vault kv put secret/inferencia/registro \
    api_key="tk_prod_abc123" \
    registry_url="registry.empresa.com:5000"

# 2. El pod de Kubernetes lo obtiene en tiempo de ejecucion
vault kv get -field=api_key secret/inferencia/registro

Configuracion de relaciones entre aplicaciones

Patrones de integracion entre componentes MLOps

# Anotacion en un Pod de Kubernetes para inyeccion de secretos con Vault Agent
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "inferencia"
  vault.hashicorp.com/agent-inject-secret-config: "secret/inferencia/registro"

Verificacion de compatibilidad entre versiones

Matriz de compatibilidad: ejemplo real para TorchServe

Verificacion de compatibilidad antes de instalar

# Verificar que el artefacto del modelo es compatible con el runtime instalado
# 1. Comprobar la version de opset ONNX del modelo
python -c "
import onnx
model = onnx.load('modelo.onnx')
print('Opset version:', model.opset_import[0].version)
"
# 2. Comprobar la version maxima de opset soportada por el runtime
python -c "import onnxruntime as ort; print(ort.get_device(), ort.__version__)"

Inventario actualizado y logs de instalacion

Estructura del inventario de aplicaciones instaladas

El inventario es un documento vivo: se actualiza en cada instalacion, actualizacion o desinstalacion.

Actividad practica: instalacion y configuracion de la pila MLOps

Escenario

Un equipo debe instalar la pila basica de MLOps en un cluster Kubernetes de desarrollo de 3 nodos (1 master + 2 workers con GPU). El presupuesto es limitado y se priorizan herramientas open source.

Tarea

Disenar el plan de instalacion:

1. Seleccionar una herramienta de cada categoria (orquestacion, registro, monitorización, secretos) y justificar la eleccion
2. Definir el orden de instalacion y las dependencias entre aplicaciones
3. Disenar la configuracion de relaciones: que credenciales necesita cada aplicacion y como se gestionan sin escribirlas en ficheros de configuracion
4. Disenar la verificacion post-instalacion: que pruebas confirman que todo funciona correctamente

Entregable

Plan de instalacion con orden, justificaciones y checklist de verificacion.

Puntos clave de la UD3

• Las aplicaciones del ecosistema MLOps no son opcionales: sin registro de modelos, sin orquestador y sin monitorización no existe un despliegue reproducible ni operable
• El orden de instalacion importa: primero la capa de secretos (Vault), luego el registro (Harbor, MLflow), luego el orquestador (K8s ya instalado), luego monitorización, luego aplicaciones de inferencia
• Los secretos nunca van en ficheros de configuracion versionados: siempre en un gestor de secretos dedicado
• La verificacion de compatibilidad de versiones debe hacerse antes de instalar, no despues: consultar la matriz de compatibilidad oficial de cada herramienta
• El inventario de aplicaciones instaladas es un documento normativo: sin el no es posible diagnosticar incidencias ni planificar actualizaciones

Criterios de evaluacion — UD3

← Volver a MP02

Navegación

← UD2 · Despliegue de la infraestruct…  ·  Volver al módulo  ·  UD4 · Integración en el flujo produ… →