Del dato a producción

Dos piezas con trabajos distintos: un gateway FastAPI en CPU que valida, decodifica en un threadpool, preprocesa con el mismo preprocess.py, llama a Triton y arma el top-k, y Triton en la T4, configurado en config.pbtxt (dynamic batching de 2 ms, 2 instancias, rechazo en cola a los 100 ms). Los 24 tests de pytest prueban el contrato y cada error sin GPU. Es código que cambia en días; el modelo llega ya hecho de la estación 5.

El proceso, paso a paso

1. Paso 1

   Fijar el contrato

   POST /v1/classify?top_k=5 con los bytes de la imagen; respuesta con model_version; errores 400, 413, 415, 422, 503 y 504.

   MLEgateway/app/main.py

2. Paso 2

   Validar barato primero

   Content-Type, 10 MB (por Content-Length y contando el stream), 40 MP y relación 1:8 leídos del header antes de decodificar.

   MLEmain.py + preprocess.py

3. Paso 3

   Decode fuera del event loop

   run_in_threadpool con un semáforo de 2 decodes por proceso; si no hay lugar en 50 ms, 503 con Retry-After.

   MLEmain.py (CPU del pod del gateway)

4. Paso 4

   Llamar a Triton con presupuesto

   Cliente async de Triton con tensores binarios; 150 ms de timeout → 504, Triton caído → 503; deadline total de 250 ms.

   MLEmain.py → Triton :8000

5. Paso 5

   Configurar Triton

   config.pbtxt: tensorrt_plan, max_batch_size 32, ventana de 2 ms, REJECT a los 100 ms, 2 instancias y warmup.

   MLEtriton/model_repository/classifier/

6. Paso 6

   Probar sin GPU

   pytest con un Triton falso: 24 tests de 200, 4xx, 503, 504, health checks y métricas.

   automático (CI)tu máquina y el job de CI (sin GPU)

Archivos del C01

        result = await asyncio.wait_for(
            client.infer(MODEL_NAME, [inp], outputs=[out], request_id=request_id),
            timeout=timeout,  # ≤ INFER_TIMEOUT_S: lo que quede del presupuesto del request
        )
    except TimeoutError:  # asyncio.TimeoutError es alias de TimeoutError desde Python 3.11
        # 504: Triton está vivo pero lento (cola llena, GPU saturada); el cliente cae a su fallback
        raise HTTPException(504, "timeout de inferencia") from None
    except aiohttp.ClientError:  # conexión rechazada/reseteada, DNS: Triton caído o reiniciando
        raise HTTPException(503, "Triton no disponible", headers={"Retry-After": "1"}) from None
    except InferenceServerException as exc:  # Triton respondió error: modelo no cargado, request rechazado
        detail = f"Triton rechazó la inferencia: {exc.message()}"
        raise HTTPException(503, detail, headers={"Retry-After": "1"}) from None

dynamic_batching {
  max_queue_delay_microseconds: 2000
  # Sin preferred_batch_size a propósito: con un solo perfil de optimización (1–32) Triton arma el
  # batch más grande posible dentro de la espera; fijar tamaños solo tiene sentido con varios
  # perfiles/engines por tamaño, y mal elegidos agregan espera.
  default_queue_policy {
    # Protección ante sobrecarga: un request que lleva 100 ms en cola ya no llega a tiempo al
    # timeout del gateway (150 ms). Mejor rechazarlo y liberar GPU para requests que siguen vivos
    # que calcular una respuesta que nadie espera.
    timeout_action: REJECT
    default_timeout_microseconds: 100000
  }

@pytest.fixture
def api(monkeypatch):
    """App con el fake inyectado. `with TestClient` ejecuta el lifespan (crea y cierra el cliente)."""
    FakeTriton.mode = "ok"
    monkeypatch.setattr(main.triton_http, "InferenceServerClient", FakeTriton)
    with TestClient(main.app) as client:
        yield client

Comandos clave

• cd reference/c01/gateway && pip install -r requirements-dev.txt && pytestCopiar

  Los 24 tests con un Triton falso, en un venv con Python 3.13 (la versión con que se probó); no necesitas GPU.

• uvicorn app.main:app --port 8080Copiar

  Gateway suelto desde gateway/, sin Triton: /healthz da 200, /readyz 503 y /v1/classify 503 con Retry-After.

• curl -fsS http://localhost:8000/v2/health/readyCopiar

  ¿Triton está listo con su modelo cargado? (arranca con --strict-readiness).

• curl -H "Content-Type: image/jpeg" --data-binary @foto.jpg "localhost:8080/v1/classify?top_k=5"Copiar

  Un request de punta a punta contra el gateway, con Triton arriba.

Qué falla aquí

En el curso: C01 · Serving C01 · Archivos de referencia M7 · Qué hace un model server (y qué no) M7 · NVIDIA Triton Inference Server

Herramientas de esta estación

@app.post("/v1/classify")
async def classify(request: Request, response: Response, top_k: int = Query(5, ge=1, le=MAX_TOP_K)):
    """Body = bytes crudos de la imagen (no multipart: menos parsing, sin archivos temporales)."""
    t0 = time.perf_counter()  # el reloj arranca con el request ya recibido (el SLO es server-side)
    # Si el cliente (o un proxy) ya trae un id lo respetamos: así se traza el request de punta a punta
    request_id = request.headers.get("x-request-id") or uuid.uuid4().hex

def test_slow_triton_is_504(api):
    FakeTriton.mode = "slow"
    r = post(api, image_bytes())
    assert r.status_code == 504  # cortamos a los 0.15 s: el cliente cae a su fallback manual
    assert "X-Request-ID" in r.headers  # los errores también son trazables

El C01 empaqueta cada tier en su propia imagen: el gateway (FastAPI, multi-stage sobre python:3.13-slim, ≈ 0.1 GB comprimida) y Triton con config.pbtxt y model.plan horneados (≈ 9.2 GB comprimida). Lo probado es, byte a byte, lo que corre, y desplegar o volver atrás es cambiar un tag. El CI construye la del gateway (estación 8), el pipeline del modelo la de Triton en la T4 (estación 5) y docker compose las prueba juntas en una máquina con GPU.

El proceso, paso a paso

1. Paso 1

   Fijar dependencias

   requirements.txt con == en las 37 dependencias, transitivas incluidas, y la misma versión de Pillow que el entrenamiento.

   MLErepo, en tu máquina

2. Paso 2

   Dockerfile del gateway

   Multi-stage: el venv se arma en builder y solo él pasa a runtime; usuario 10001 y un solo proceso uvicorn.

   MLErepo, en tu máquina

3. Paso 3

   Dockerfile de Triton

   FROM tritonserver:24.08-py3 (mismo YY.MM que el engine) y COPY del model repository; el build falla si falta model.plan.

   MLErepo; la imagen la construye el pipeline del modelo en la T4 (estación 5)

4. Paso 4

   docker build

   Para linux/amd64, con tag = commit (gateway) o versión del modelo (Triton); el .dockerignore del gateway deja fuera tests, secretos y modelos.

   MLEtu máquina o una g4dn de desarrollo; las imágenes oficiales salen del CI (gateway) y del pipeline del modelo (Triton)

5. Paso 5

   Probar todo con compose

   docker compose up --build: Triton con GPU y healthcheck, el gateway espera service_healthy y Prometheus carga las 6 alertas.

   MLEmáquina Linux con GPU NVIDIA y NVIDIA Container Toolkit

6. Paso 6

   Revisar peso y capas

   ≈ 0.1 GB el gateway contra ≈ 9.2 GB Triton, comprimidas (lo que baja cada nodo): el pull de Triton es el que alarga el cold start.

   MLEtu máquina

Archivos del C01

# Solo el venv ya resuelto: pip, compiladores y caches de la etapa builder se quedan atrás
COPY --from=builder /opt/venv /opt/venv
# El código queda con dueño root y solo lectura para "app": el proceso no puede modificarse
COPY app/ ./app/
USER 10001
# Documenta el puerto (no lo publica): el Service de k8s y compose apuntan aquí
EXPOSE 8080
# HEALTHCHECK lo usan `docker run`/compose. Kubernetes lo IGNORA: allá mandan liveness/readiness
# probes. Sin curl en la imagen slim, se usa Python (stdlib) para pegarle a /healthz.
HEALTHCHECK --interval=10s --timeout=2s --start-period=10s --retries=3 \
    CMD ["python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8080/healthz', timeout=1)"]

CMD ["tritonserver", \
     "--model-repository=/models", \
     "--model-control-mode=none", \
     "--disable-auto-complete-config", \
     "--exit-on-error=true", \
     "--strict-readiness=true", \
     "--http-port=8000", \
     "--grpc-port=8001", \
     "--metrics-port=8002", \
     "--exit-timeout-secs=30", \
     "--log-format=ISO8601"]

  gateway:
    build: ./gateway  # imagen multi-stage de gateway/Dockerfile
    ports:
      - "8080:8080"  # la API pública: POST /v1/classify
    environment:  # misma configuración que en k8s, solo cambian los valores
      TRITON_URL: "triton:8000"  # nombre del servicio en la red de compose, sin http://
      MODEL_NAME: "classifier"
      MODEL_VERSION: "2026-09-01-resnet50-fp16"  # lo devuelve la API y queda en cada línea de log
      INFER_TIMEOUT_S: "0.15"
    depends_on:
      triton:
        condition: service_healthy  # no arranca hasta que el modelo esté listo (evita 503 al inicio)

# Secretos locales: jamás dentro de una imagen (se inyectan como env/Secret en runtime)
.env
*.pem
# Imágenes de prueba y modelos en cualquier carpeta (**/): el gateway no los necesita (el modelo vive en Triton)
**/*.jpg
**/*.jpeg
**/*.png
**/*.onnx
**/*.plan

Comandos clave

• docker build --platform linux/amd64 -t classifier-gateway:tag gateway/Copiar

  En un Mac con Apple Silicon --platform es obligatorio: los nodos c6i y g4dn son x86. El tag es el commit.

• docker build -t classifier-triton:version_modelo triton/Copiar

  Falla a propósito si falta model.plan: primero build_engine.sh en la T4.

• docker compose up --buildCopiar

  Desde reference/c01: gateway, Triton con GPU y Prometheus en una máquina.

• curl -s -H "Content-Type: image/jpeg" --data-binary @foto "localhost:8080/v1/classify?top_k=5"Copiar

  La prueba de punta a punta: top-5 con model_version.

• docker history classifier-gateway:tagCopiar

  Una fila por capa: encuentra la que infló la imagen.

• docker buildx imagetools inspect --format '{{json .Image}}' registry/classifier-gateway:tagCopiar

  Antes de desplegar: el config tiene que decir "architecture": "amd64". Sin --format, una imagen de una sola plataforma no muestra la suya.

Qué falla aquí

En el curso: M5 · Un Dockerfile de ML, decisión por decisión M5 · docker compose para desarrollo local M5 · Reducir tamaño (y por qué importa para el cold start) C01 · Archivos de referencia

Herramientas de esta estación

FROM nvcr.io/nvidia/tritonserver:24.08-py3

# El model repository completo: classifier/config.pbtxt + classifier/1/model.plan
COPY model_repository /models

# Falla el BUILD si falta el engine (no se versiona en git): mejor aquí que un pod en CrashLoop
RUN test -f /models/classifier/1/model.plan

# 8000 HTTP/REST (KServe v2, lo usa el gateway) · 8001 gRPC · 8002 métricas Prometheus (nv_*)
EXPOSE 8000 8001 8002

Transbordo · Registro de imágenes (Amazon ECR). Aquí se tocan las líneas semanas, días y continuo. Qué cruza

Cada commit pasa por CI: los 24 tests del gateway corren sin GPU y su imagen se construye una sola vez para linux/amd64 y sube a ECR, donde los tags no se mueven. La de Triton la arma el pipeline del modelo en la T4 antes de registrar la versión (estación 5), con la versión del modelo como tag. Desde el push todo habla del digest: se escanea, se firma y staging y producción despliegan el mismo.

El proceso, paso a paso

1. Paso 1

   Commit y pull request

   El hash corto del commit (3f9c2ab) será el tag del gateway: desde un pod en producción llegas al código exacto.

   MLEtu máquina → GitHub

2. Paso 2

   Tests sin GPU

   pytest corre los 24 tests del gateway contra un Triton falso; el curso suma un test de tensores de referencia del preprocesamiento.

   automático (CI)runner de CI en CPU

3. Paso 3

   Build del gateway y push

   docker buildx build --platform linux/amd64 --push: la imagen sube una sola vez a un repo de ECR con tags inmutables.

   automático (CI)runner de CI → Amazon ECR

4. Paso 4

   Llega la imagen de Triton

   Solo con un modelo nuevo: el pipeline la arma en la T4 (build_engine.sh → docker build triton/ → paridad --backend triton) y la sube con la versión como tag.

   automático (pipeline)runner con T4 (g4dn.xlarge) → Amazon ECR

5. Paso 5

   Digest, escaneo y firma

   Cada push devuelve un digest sha256: el escáner busca CVEs y cosign firma ese digest.

   automático (CI)Amazon ECR y runner de CI

6. Paso 6

   Apuntar los manifests

   El manifest del gateway pasa al tag nuevo (mejor aún, al digest) con un PR al repo de manifests (GitOps) o kubectl set image; un modelo nuevo sigue la escalera de la estación 10.

   automático (CD)repo de manifests → EKS

Archivos del C01

"""Tests del gateway SIN GPU ni Triton: un cliente falso reemplaza a tritonclient (caso c01).

Por qué un fake y no un mock genérico: el fake respeta el contrato real del cliente aio (mismos
métodos async, mismas excepciones) y el gateway sigue construyendo InferInput/InferRequestedOutput
REALES, así que el test detecta si alguien cambia el nombre, shape o dtype del tensor.
Correr: cd gateway && pytest
"""

checkpoint .pt ──export_onnx.py──▶ classifier.onnx ──parity_check.py (ORT, CPU)──▶ ¿pasa?
      └─ en la máquina con T4: build_engine.sh ──▶ model.plan ──docker build triton/──▶ imagen
         └─ Triton arriba ──parity_check.py --backend triton (FP16 vs FP32)──▶ ¿pasa? ──▶ registry / canary

        - name: gateway
          # Tag = commit de git (inmutable); nunca :latest (no sabrías qué versión corre ni cómo volver)
          image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/classifier-gateway:3f9c2ab

Comandos clave

• cd reference/c01/gateway && pip install -r requirements-dev.txt && pytestCopiar

  24 tests sin GPU ni Triton: lo primero que corre el CI.

• aws ecr get-login-password --region region | docker login --username AWS --password-stdin registryCopiar

  Login a ECR; el token dura 12 h. En CI, con un rol asumido por OIDC, sin llaves guardadas.

• docker buildx build --platform linux/amd64 -t registry/classifier-gateway:sha --push gateway/Copiar

  Build único, para la arquitectura de los nodos; sha son los primeros 7 caracteres del commit: git rev-parse --short=7 HEAD (en CI, ${GITHUB_SHA::7}).

• crane digest registry/classifier-gateway:shaCopiar

  El digest es la identidad: es lo que se firma y se despliega.

• cosign sign --yes registry/classifier-gateway@digestCopiar

  Firma keyless con la identidad OIDC del CI.

• kubectl -n classifier set image deployment/gateway gateway=registry/classifier-gateway@digestCopiar

  Despliegue por digest; con GitOps ese valor va en un PR al repo de manifests.

Qué falla aquí

En el curso: M10 · CI/CD para modelos: la pirámide de tests M5 · Registries y tags inmutables Herramientas por categoría · Infraestructura como código, CI y seguridad M15 · Supply chain: imágenes, dependencias y pesos verificados

Herramientas de esta estación

REG=123456789012.dkr.ecr.us-east-1.amazonaws.com
SHA=$(git rev-parse --short=7 HEAD)

# 1) CI construye UNA vez, para la arquitectura de los nodos, con el commit como tag
docker buildx build --platform linux/amd64 -t $REG/classifier-gateway:$SHA --push gateway/

on: [push, pull_request]
jobs:
  gateway-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with: {python-version: "3.13"}
      - run: pip install -r requirements-dev.txt && pytest
        working-directory: reference/c01/gateway

aws ecr create-repository --repository-name classifier-gateway --image-tag-mutability IMMUTABLE
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/classifier-gateway:3f9c2ab

Transbordo · El cluster (Amazon EKS). Aquí se tocan las líneas días, milisegundos y continuo. Qué cruza

En EKS el C01 corre dos Deployments: el gateway en nodos de CPU (3–12 pods, HPA por CPU) y Triton en nodos g4dn.xlarge, una T4 por pod (2–4 pods, KEDA por tiempo en cola), repartidos entre las dos zonas. Tú escribes en YAML el estado deseado; Kubernetes reconcilia sin parar (compara lo pedido con lo que corre y corrige la diferencia): agenda cada pod donde cabe, lo reinicia si muere y lo saca del balanceo si no está listo. A partir del Ingress, el AWS Load Balancer Controller crea el ALB.

El proceso, paso a paso

1. Paso 1

   Preparar el cluster

   EKS con node group g4dn.xlarge (label workload=gpu-t4 y taint nvidia.com/gpu), device plugin, Load Balancer Controller, KEDA y Prometheus.

   plataforma/SREAmazon EKS (IaC y Helm)

2. Paso 2

   Escribir los manifests

   YAML con el estado deseado: Deployments, Services, HPA, ScaledObject, Ingress, PodDisruptionBudget, NetworkPolicy y ServiceMonitors.

   MLErepo (k8s/*.yaml)

3. Paso 3

   kubectl apply

   Namespace classifier con el readiness gate del ALB y apply de los 4 archivos: el API server guarda lo que pediste.

   MLEtu terminal → API server de EKS

4. Paso 4

   Agendar y arrancar pods

   El scheduler pone cada Triton en una T4 libre, repartidos entre zonas; el kubelet baja la imagen y corre startup, readiness y liveness.

   automático (Kubernetes)nodos g4dn.xlarge (T4) y nodos de CPU

5. Paso 5

   Exponer con Service e Ingress

   Services ClusterIP para el gateway y para Triton (este con ruteo por zona); el Load Balancer Controller crea el ALB interno con target-type ip.

   automático (Kubernetes)EKS y ALB de AWS

6. Paso 6

   Escalar solo

   HPA del gateway por CPU al 60 % (3–12 pods) y KEDA para Triton por tiempo en cola con objetivo de 10 ms (2–4 pods).

   automático (Kubernetes)control plane de EKS, KEDA y Karpenter para los nodos

7. Paso 7

   Reconciliar siempre

   Si un pod muere o cae un nodo, los controladores lo recrean; la readiness saca del balanceo al pod que no está listo.

   automático (Kubernetes)control plane de EKS y kubelet de cada nodo

Archivos del C01

Prerequisitos del cluster: NVIDIA device plugin, node group de `g4dn.xlarge` con label
`workload=gpu-t4` y taint `nvidia.com/gpu=present:NoSchedule`, AWS Load Balancer Controller, KEDA,
Prometheus (kube-prometheus-stack, con kube-state-metrics), un CNI que aplique NetworkPolicy (VPC CNI
con `enableNetworkPolicy=true`, o Calico) y las imágenes en ECR. Kubernetes ≥ 1.35: 1.34 sale del
soporte upstream el 27 de octubre de 2026 y del soporte estándar de EKS el 2 de diciembre de 2026. Nada
en los manifests depende de 1.34: pasan la validación estricta contra 1.35–1.37 y
`trafficDistribution: PreferSameZone` es GA desde 1.35 (en 1.31–1.33 cámbialo por `PreferClose`).

    spec:
      # Tiempo total para apagar: preStop (10 s) + --exit-timeout-secs de Triton (30 s) + margen
      terminationGracePeriodSeconds: 60
      nodeSelector:
        workload: gpu-t4  # solo el node group de g4dn.xlarge (T4, sm_75): el engine se compiló para esa GPU
      tolerations:
        # Los nodos GPU tienen el taint nvidia.com/gpu=present:NoSchedule para que ningún pod CPU
        # (gateway, sistema) ocupe una máquina cara; Triton lo tolera explícitamente.
        - key: nvidia.com/gpu
          operator: Equal
          value: present
          effect: NoSchedule

          # readiness: ¿mandarle tráfico? /readyz = modelo listo en Triton (ver main.py)
          readinessProbe:
            httpGet:
              path: /readyz
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 2

        ignoreNullValues: "false"
        # Espera media en cola en ms (misma fórmula que la alerta TritonQueueTimeHigh).
        # clamp_min evita 0/0 = NaN sin tráfico; si todo falla (0 éxitos) el valor se dispara y escala.
        query: |
          sum(rate(nv_inference_queue_duration_us{model="classifier"}[2m]))
            /
          clamp_min(sum(rate(nv_inference_request_success{model="classifier"}[2m])), 1e-9)
            / 1000
        # Objetivo: 10 ms en cola. Normal con max_queue_delay de 2 ms es ≈ 1–3 ms; > 10 ms es saturación.
        # Ojo: la cola es no lineal (casi 0 hasta que la GPU se satura). Alternativa más estable:
        # AverageValue sobre sum(rate(nv_inference_count[1m])) con umbral ≈ 400 img/s por réplica.
        threshold: "10"

Comandos clave

• kubectl create namespace classifierCopiar

  Una vez por cluster.

• kubectl label namespace classifier elbv2.k8s.aws/pod-readiness-gate-inject=enabledCopiar

  Readiness gate del ALB: el rolling update no mata un pod viejo hasta que el ALB ve sano al nuevo.

• kubectl apply -f k8s/triton.yaml -f k8s/keda-triton.yaml -f k8s/gateway.yaml -f k8s/monitoring.yamlCopiar

  Declarativo: guardas el estado deseado y los controladores hacen el resto.

• kubectl get pods -n classifier -o wideCopiar

  Fase, READY, reinicios y nodo: ¿un Triton por zona?

• kubectl describe pod pod -n classifierCopiar

  Primera parada si algo no arranca: los Events del final dicen por qué.

• kubectl get nodes -L node.kubernetes.io/instance-type,topology.kubernetes.io/zone,workloadCopiar

  Tipo, zona y label workload=gpu-t4 de cada nodo.

• kubectl get hpa -n classifierCopiar

  El HPA del gateway y keda-hpa-triton, con su métrica actual contra el objetivo.

Qué falla aquí

En el curso: M6 · Los objetos que sí debes conocer M6 · GPUs en Kubernetes M6 · HPA: por qué escalar por CPU no sirve para un servicio de GPU M6 · KEDA: escalar por eventos y hasta cero M6 · Alta disponibilidad: multi-AZ, PDB y N+1 Docker y kubectl · Depurar pods: síntoma → comandos → causa típica

Herramientas de esta estación

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gateway
  namespace: classifier
  labels:
    app.kubernetes.io/name: gateway
    app.kubernetes.io/part-of: classifier
spec:
  # Sin "replicas": las decide el HPA de abajo (3–12)

          resources:
            requests:
              cpu: "2"  # Triton usa CPU para red, deserializar y el scheduler de batching
              memory: 6Gi  # librerías CUDA + buffers pinned; el modelo en sí vive en la GPU
              nvidia.com/gpu: 1  # recurso extendido del NVIDIA device plugin: una T4 entera por pod
            limits:
              memory: 6Gi  # memoria: límite = request (sin sorpresas de OOM por vecinos)
              nvidia.com/gpu: 1  # las GPUs no se comparten ni se sobre-asignan: request = limit
              # Sin límite de CPU: el nodo es solo para Triton y el throttling de CFS mete latencia

spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: triton  # el Deployment de k8s/triton.yaml
  minReplicaCount: 2  # nunca menos de 2: una GPU por AZ (N+1), aunque 1 sola cubra el pico
  maxReplicaCount: 4  # techo de costo: 4 × g4dn.xlarge; si no alcanza, TritonQueueTimeHigh avisa
  pollingInterval: 15  # cada 15 s KEDA consulta Prometheus

    alb.ingress.kubernetes.io/scheme: internal
    # ip: el ALB manda directo a la IP del pod (sin NodePort ni salto extra de kube-proxy)
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:123456789012:certificate/00000000-0000-0000-0000-000000000000
    # El health check del ALB usa la misma señal que la readiness de k8s
    alb.ingress.kubernetes.io/healthcheck-path: /readyz
    alb.ingress.kubernetes.io/success-codes: "200"
    # Drenado al sacar un pod: 30 s (el default de 300 s hace eternos los deploys)
    alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds=30

En el C01, desplegar una versión registrada es cambiar el tag de la imagen en los manifests, pero un modelo nuevo no entra con un simple rolling update: la release es un par gateway vN + Triton vN con su propio Service, que pasa por shadow (1–2 días), canary 5 % → 25 % → 100 % con rollback automático y, si el cambio es grande, un A/B por vendedor. Al promover, el alias champion se mueve en MLflow y la release anterior queda viva 24–48 h: volver es un cambio de ruteo de segundos, no un redeploy.

El proceso, paso a paso

1. Paso 1

   Release vN sin tráfico

   Los manifests pasan al tag de la versión registrada (ya en ECR): Triton vN con su Service triton-vN y un gateway vN que solo habla con él, todavía sin tráfico.

   automático (CD)repo de manifests → EKS, con una T4 extra

2. Paso 2

   Shadow 1–2 días

   El gateway copia de forma asíncrona una muestra al challenger y solo loguea: acuerdo con el champion, p99, errores y distribución.

   automático (gateway)gateway y Triton challenger en su propia T4

3. Paso 3

   Canary al 5 %

   Pesos en el ALB (o Argo Rollouts): 5 % de los requests durante horas, incluido un pico diurno.

   automático (CD)ALB (target groups con peso)

4. Paso 4

   Análisis contra el estable

   5xx > 0.5 %, p99 > 200 ms o 1.2× el estable, baja confianza > 1.5×, PSI > 0.1: el peso vuelve solo al estable.

   automático (CD)Argo Rollouts o el pipeline de CD, con queries a Prometheus en la misma ventana

5. Paso 5

   25 % y, si aplica, A/B

   Horas al 25 %; si el cambio es grande, A/B por vendedor de 1–2 semanas con el header X-Model-Arm y una regla del ALB.

   MLEALB y backend de publicación

6. Paso 6

   Promover y dejar el bake

   Una persona aprueba el 100 %, el alias champion se mueve en MLflow y la release anterior queda viva 24–48 h.

   MLEMLflow y EKS

Archivos del C01

          # Tag = versión del modelo (imagen horneada). Rollback de emergencia = volver al tag anterior. Un canary
          # o un A/B es otra release (Deployment + Service triton-<versión>): este Service nunca debe mezclar dos modelos
          image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/classifier-triton:2026-09-01-resnet50-fp16

  # Sin "replicas": las decide el HPA de abajo (3–12)
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%  # pods nuevos antes de bajar viejos
      maxUnavailable: 0  # capacidad completa durante todo el deploy

# Solo la versión más nueva del directorio. Con la imagen "horneada" hay una sola versión; el
# rollback es volver a desplegar la imagen anterior, no cargar dos versiones en la misma GPU.
version_policy: { latest: { num_versions: 1 } }

Comandos clave

• kubectl diff -f k8s/triton.yamlCopiar

  Qué cambiaría antes de aplicar (exit 1 = hay diferencias).

• kubectl rollout status deploy/triton -n classifier --timeout=25mCopiar

  Espera el rollout: cada pod de Triton puede tardar minutos (nodo, imagen, engine).

• kubectl argo rollouts promote gateway -n classifierCopiar

  Con Argo Rollouts: sale de la pausa manual del canary.

• kubectl argo rollouts abort gateway -n classifierCopiar

  Devuelve el tráfico al estable; el Rollout queda Degraded hasta que el template vuelva a la versión anterior (con GitOps, un revert).

• kubectl rollout undo deploy/triton -n classifierCopiar

  Vuelve al ReplicaSet anterior: el tag anterior es el modelo anterior. Con GitOps, un revert en git.

• kubectl rollout history deploy/triton -n classifierCopiar

  Revisiones guardadas para volver: el C01 conserva 5.

Qué falla aquí

En el curso: M11 · Shadow deployment: comparar sin afectar a nadie M11 · Canary: porcentajes, tiempos y criterios para avanzar M11 · Blue/green y rollback instantáneo M11 · Rollback: criterios automáticos y qué guardar para volver C01 · Evaluación offline y online

Herramientas de esta estación

  strategy:
    canary:
      trafficRouting:
        alb: {ingress: classifier, servicePort: 8080}   # el Ingress apunta a gateway-stable; pesos exactos en el ALB
      steps:
        - setWeight: 5
        - pause: {duration: 4h}          # horas, no minutos: tiene que cubrir tráfico real
        - setWeight: 25
        - pause: {}                      # sin duración: promoción manual después de un pico diurno
        - setWeight: 100