Introducción
El desarrollo de modelos de inteligencia artificial para sistemas avanzados de asistencia al conductor (ADAS) como EyeSight de Subaru exige ciclos iterativos de procesamiento de datos, entrenamiento, validación e inferencia. Sin embargo, la infraestructura on-premise basada en GPUs que utilizaba Subaru se convirtió en un cuello de botella crítico: las imágenes de contenedores de IA, que superaban los 30 GB, requerían hasta 3 horas para descargarse antes de que los workloads pudieran iniciarse. Los procesos de despliegue dependían de scripts manuales en lugar de configuraciones declarativas, y las pipelines de machine learning carecían de un framework unificado de orquestación. Esto no solo ralentizaba la iteración de modelos, sino que también comprometía la reproducibilidad y la eficiencia operativa.
La solución implementada por Subaru —basada en Kubernetes y proyectos CNCF como Envoy Gateway, Gateway API, MetalLB, Argo CD y Argo Workflows— logró reducir el tiempo de pull de imágenes de 3 horas a 3 minutos, una mejora de 60x. Además, la adopción de GitOps con Helmfile y la automatización de pipelines de ML permitieron escalar la plataforma sin sacrificar consistencia operativa. Este caso, ganador del CNCF End User Case Study Contest 2026, demuestra cómo las tecnologías cloud native pueden resolver problemas reales de infraestructura en entornos de IA a gran escala.
Qué ocurrió
Subaru identificó que su entorno on-premise para desarrollo de IA no escalaba con la demanda de sus equipos de ADAS. Los principales problemas eran:
- Tiempos de descarga de imágenes: Las imágenes de contenedores, con tamaños entre 25 y 35 GB, tardaban hasta 3 horas en descargarse debido a la latencia en la red y la falta de optimización en el registry.
- Despliegues manuales: Los procesos dependían de scripts personalizados, lo que introducía errores humanos y dificultaba la auditoría.
- Falta de orquestación: Las pipelines de ML (entrenamiento, validación, inferencia) se ejecutaban de forma aislada, sin sincronización ni seguimiento centralizado.
Para abordar estos desafíos, el equipo de DevOps de Subaru, liderado por Ryoji Kobayashi, diseñó una arquitectura cloud native sobre Kubernetes. La clave fue combinar herramientas CNCF para:
- Acelerar la distribución de imágenes: Usando Envoy Gateway (versión 1.0.0) como proxy de Capa 7 para balanceo de carga y MetalLB (versión 0.13.10) para asignación de IPs en el clúster, junto con Harbor como registry local.
- Automatizar despliegues: Adoptando GitOps con Argo CD (versión 2.9.0) y Helmfile para gestionar definiciones de aplicaciones de forma declarativa.
- Orquestar pipelines de ML: Implementando Argo Workflows (versión 3.4.0) para automatizar flujos de trabajo complejos, desde la preparación de datos hasta el despliegue de modelos.
El resultado fue una reducción drástica en los tiempos de pull de imágenes (de 180 minutos a 3 minutos) y una mejora en la reproducibilidad de los experimentos de ML, gracias a la trazabilidad integrada en Argo Workflows.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps e infraestructura, el caso de Subaru ofrece lecciones concretas sobre cómo las tecnologías cloud native pueden optimizar workloads de IA:
1. Eficiencia en la distribución de imágenes:- La combinación de Envoy Gateway y MetalLB permitió balancear el tráfico de descarga de imágenes entre múltiples nodos, eliminando cuellos de botella en el registry. Según el caso de estudio, esto redujo la latencia en un 95% para transferencias de imágenes grandes.
- Harbor (versión 2.7.0), como registry local, eliminó la dependencia de registros externos y permitió el uso de cache de capas (layer caching), reduciendo el ancho de banda necesario en un 40%.
- Argo CD centralizó la gestión de configuraciones, reduciendo el tiempo de despliegue de aplicaciones de 45 minutos a menos de 5 minutos. Además, la integración con Helmfile permitió gestionar múltiples entornos (dev, staging, prod) desde un único repositorio Git.
- La adopción de GitOps eliminó la necesidad de acceso SSH a los nodos, mejorando la seguridad al reducir la superficie de ataque. Según el informe de Subaru, los incidentes relacionados con configuraciones inconsistentes cayeron un 80%.
- Argo Workflows automatizó el 100% de las pipelines de ML, desde la extracción de datos hasta el despliegue de modelos. Esto permitió:
– Escalabilidad: Los workflows podían ejecutarse en paralelo en múltiples GPUs, reduciendo el tiempo de entrenamiento de modelos en un 30%.
4. Costos y escalabilidad:- La migración a Kubernetes permitió un uso más eficiente de los recursos GPU. Según datos de Subaru, la utilización de GPUs pasó de un 40% a un 85%, gracias a la capacidad de Kubernetes para programar workloads en función de la disponibilidad de recursos.
- El ahorro en costos de infraestructura se estimó en $200,000 USD anuales, principalmente por la reducción en el tiempo ocioso de GPUs y la optimización del ancho de banda.
Detalles técnicos
Arquitectura implementada
Subaru diseñó un clúster de Kubernetes (versión 1.28) en un entorno híbrido (on-premise + cloud privado), con los siguientes componentes clave:
- Capa de red y balanceo:
– MetalLB (v0.13.10): Asignó IPs externas a los servicios de tipo LoadBalancer en el clúster, eliminando la dependencia de soluciones proprietary de balanceo.
– Calico (v3.26.0): Como CNI (Container Network Interface) para gestionar el networking entre pods, con políticas de red para aislar workloads de ML.
- Registry y distribución de imágenes:
– Cache de capas: Almacenaba capas de imágenes descargadas previamente para evitar transferencias redundantes.
– Replicación geográfica: Sincronizaba imágenes entre múltiples instancias de Harbor en diferentes zonas.
– Vulnerability scanning: Integración con Trivy para escanear imágenes en busca de CVEs antes de su despliegue.
- GitOps y despliegues:
/subaru-ai-platform
├── helmfile.yaml
├── charts/
│ ├── ml-pipeline/ # Chart para Argo Workflows
│ ├── registry/ # Chart para Harbor
│ └── monitoring/ # Chart para Prometheus + Grafana
└── environments/
├── dev/
├── staging/
└── prod/
– Kustomize: Usado en conjunto con Helm para personalizar configuraciones por entorno sin duplicar código.
- Orquestación de ML:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: eyesight-training-
spec:
entrypoint: training-pipeline
templates:
- name: training-pipeline
steps:
- - name: data-preprocessing
template: preprocess
- - name: train-model
template: train
arguments:
parameters:
- name: epochs
value: "50"
- name: preprocess
container:
image: subaru/ml-preprocess:v1.2.0
command: ["python", "preprocess.py"]
resources:
limits:
cpu: "4"
memory: "8Gi"
- name: train
inputs:
parameters:
- name: epochs
container:
image: subaru/ml-train:v1.2.0
command: ["python", "train.py", "--epochs", "{{inputs.parameters.epochs}}"]
resources:
limits:
nvidia.com/gpu: 1
– Prometheus + Grafana: Monitoreaban métricas de los workflows, como tiempo de ejecución, uso de GPU y éxito/fracaso de los pasos.
- Monitoreo y observabilidad:
– Uso de CPU/GPU en nodos y pods.
– Latencia en las descargas de imágenes (métrica harbor_image_pull_duration_seconds).
– Estado de los workflows de Argo (argo_workflows_status).
– Loki (v2.8.0): Almacenaba logs de los contenedores y workflows, con consultas como:
{container="ml-train"} |= "error" | json | line_format "{{.message}}"
Qué deberían hacer los administradores y equipos técnicos
Si tu equipo enfrenta problemas similares con workloads de IA o ML en Kubernetes, estas son las acciones concretas basadas en el caso de Subaru:
1. Optimizar la distribución de imágenes:- Implementar Harbor como registry local con cache de capas y replicación geográfica:
helm repo add harbor https://helm.goharbor.io
helm install harbor harbor/harbor --version 2.7.0 \
--set persistence.enabled=true \
--set cache.enabled=true \
--set trivy.enabled=true
- Configurar Envoy Gateway para balancear el tráfico de pull de imágenes:
# gateway-api.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: harbor-gateway
spec:
gatewayClassName: envoy-gateway
listeners:
- name: harbor
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
- Desplegar Argo CD:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.9.0/manifests/install.yaml
- Configurar un repositorio Git con Helmfile para gestionar aplicaciones:
# helmfile.yaml
repositories:
- name: argo
url: https://argoproj.github.io/argo-helm
releases:
- name: ml-pipeline
namespace: ml
chart: argo/argo-workflows
version: 3.4.0
values:
- values/ml-pipeline.yaml
- Sincronizar Argo CD con el repositorio:
argocd repo add https://github.com/tu-organizacion/subaru-ai-platform --username <user> --password <token>
- Instalar Argo Workflows:
kubectl create namespace argo
kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.4.0/install.yaml
- Definir workflows para pipelines de ML (ver ejemplo en la sección de detalles técnicos) y monitorearlos con:
argo list -n argo
argo get -n argo <workflow-name>
- Desplegar kube-prometheus-stack:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack --version 45.0.0
- Configurar dashboards en Grafana para métricas de:
nvidia_gpu_utilization).– Tiempo de pull de imágenes (harbor_image_pull_duration_seconds).
– Estado de workflows (argo_workflows_status).
- Escanear imágenes con Trivy antes de su despliegue:
trivy image subaru/ml-train:v1.2.0
- Aplicar políticas de red con Calico para aislar workloads de ML:
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
name: ml-isolation
spec:
selector: app == "ml-train"
types:
- Ingress
- Egress
ingress:
- action: Allow
protocol: TCP
source:
namespaceSelector: name == "ml"
egress:
- action: Allow
protocol: TCP
destination:
namespaceSelector: name == "ml"
Conclusión
El caso de Subaru demuestra que los problemas de escalabilidad y eficiencia en entornos de IA no requieren soluciones proprietary ni migraciones costosas a la nube pública. Mediante la adopción de tecnologías cloud native maduras —Kubernetes, Envoy Gateway, Argo CD, Argo Workflows y Harbor— es posible lograr mejoras significativas en el tiempo de despliegue, la reproducibilidad de los experimentos y la utilización de recursos. Los resultados de Subaru (60x más rápido en pull de imágenes, 85% de utilización de GPUs, y $200K USD anuales en ahorros) son un testimonio del valor de combinar herramientas CNCF con prácticas como GitOps y la orquestación declarativa.
Para equipos de DevOps e infraestructura, este caso ofrece un roadmap claro: optimizar la distribución de imágenes, automatizar despliegues con GitOps, orquestar pipelines de ML y monitorear todo el flujo con herramientas nativas de Kubernetes. La clave está en integrar estos componentes de manera coherente, como hizo Subaru, para construir una plataforma escalable y operativamente eficiente.
Fuentes
https://www.cncf.io/announcements/2026/07/28/subaru-wins-cncf-end-user-case-study-contest-for-accelerating-ai-development-with-cloud-native-infrastructure/