Introducción
Un equipo de plataforma que despliega microservicios con ArgoCD, escala con HPA y monitorea con Prometheus no está automáticamente listo para un pipeline de inferencia LLM. La pregunta que plantea la CNCF en su blog de agosto 2026 no es si Kubernetes puede ejecutar cargas de AI —puede, y lo hace desde hace años— sino si la plataforma operativa que construyeron para contenedores soporta el ciclo de vida completo de un modelo: versionado, evaluación, carga en aceleradores, observabilidad de latencia por token y actualización sin downtime. Los números del CNCF 2025 Annual Cloud Native Survey son elocuentes: 66% de las organizaciones que alojan modelos generativos usan Kubernetes para inferencia, pero apenas el 7% despliega modelos diariamente. El 2025 State of AI in Platform Engineering agrega otro dato incómodo: 35% de los equipos de plataforma todavía no orquestan cargas de AI en absoluto. Esa brecha no se cierra con más GPUs. Se cierra rediseñando la capa de orquestación, delivery y observabilidad para que un modelo sea un artefacto de primer nivel, no un sidecar improvisado.
Qué ocurrió
La adopción de AI en producción generó una presión operativa que las plataformas cloud native no anticiparon en su diseño original. Kubernetes fue construido para orquestar contenedores homogéneos: pods con CPU, memoria, red y almacenamiento persistente. Un workload de AI típico en producción —data preparation, preprocessing, retrieval, orquestación de agentes, inferencia— mezcla CPUs, GPUs NVIDIA (A100, H100, B200), TPUs y en algunos casos FPGAs dentro de un mismo pipeline. El scheduler clásico de Kubernetes, basado en requests y limits de CPU/memoria, no modela topología de aceleradores, partición de VRAM ni afinidad NUMA entre CPU y GPU.
El problema se agrava en el ciclo de delivery. Un equipo de plataforma tiene CI/CD maduro: commit → build → test → deploy. Con AI, el artefacto crítico pasa a ser el modelo mismo, que puede pesar 70 GB (un Llama 3 70B en fp16), depende de un runtime específico (vLLM 0.6.x, TensorRT-LLM 0.12, TGI 2.x) y requiere una fase de evaluación antes de producción. Ningún pipeline GitOps estándar versiona y valida ese artefacto junto con el código.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto operativo es concreto y medible. Equipos que no adaptaron su scheduler reportan tiempos de cola de 12 a 45 minutos para pods que solicitan GPUs en clusters compartidos, porque el scheduler binario (tiene/ no tiene GPU) ignora la topología PCIe y la disponibilidad de VRAM libre. En clusters con MIG (Multi-Instance GPU) en A100/H100, un pod que solicita «1 GPU» puede quedarse en Pending mientras hay instancias MIG-3g.40gb disponibles, porque no hay forma declarativa de pedir esa instancia específica.
En observabilidad, la situación es similarmente insuficiente. Un dashboard de Grafana con CPU, memoria y p99 de HTTP no responde la pregunta real del SRE de AI: «¿El workload está esperando por VRAM, por el scheduler, por carga del modelo en la GPU o por el propio forward pass?» Sin métricas de accelerator utilization (DCGM), queue time del scheduler, model load time y tokens/segundo por endpoint, el diagnóstico de degradación se vuelve una caza manual.
Desde seguridad, los modelos introducen superficies nuevas: artefactos en OCI registries sin firma, endpoints de inferencia expuestos sin rate limiting por token, y datasets de fine-tuning que pueden contener PII si no se aplican políticas de red y acceso a nivel de namespace.
Detalles técnicos
Scheduling heterogéneo con DRA. Dynamic Resource Allocation, que alcanzó GA en Kubernetes 1.33 (abril 2025) y se refinó en 1.34, reemplaza el modelo estático de device plugins con un esquema declarativo de ResourceClaims. Un equipo puede definir un ResourceClaimTemplate que solicita «2 instancias MIG-2g.20gb en una GPU NVIDIA H100 con afinidad NUMA node 0», y el scheduler lo resuelve sin intervención manual del administrador de cluster. El componente kubelet ahora reporta capabilities de aceleradores al kube-apiserver vía DevicePlugin v2 con soporte para partición dinámica.
Model delivery como artefacto versionado. El patrón emergente trata al modelo como un OCI artifact (OCI 1.1, soportado por containerd 1.7+ y CRI-O 1.30+). El flujo queda: Code + Model + Config → Evaluate → Deploy → Observe → Update. Herramientas como KServe 0.13, BentoML 2.x y MLflow 2.16+ ya integran este ciclo, pero la plataforma debe orquestar el pull del artifact desde el registry, la validación de checksums (cosign/Sigstore), y la inyección en el pod sin que el developer gestione volúmenes manualmente.
Observabilidad extendida. El stack mínimo para AI en Kubernetes incluye: DCGM Exporter (nvidia-dcgm-exporter 3.3+) para métricas de GPU (SM utilization, memory bandwidth, ECC errors); OpenTelemetry Collector para correlacionar traces de aplicación con spans de inferencia; y métricas custom de vLLM/TGI (tokens/segundo, time-to-first-token, queue depth). Sin esto, un incidente donde un endpoint cae de 800 a 12 tokens/segundo se diagnostica por syslog y no por alerting.
Self-service con golden paths. El principio de platform engineering —el developer especifica qué, la plataforma resuelve cómo— se extiende. Backstage 1.27+ o Port permiten definir scaffolds que incluyen: selección de modelo, clase de GPU, autoscaling por métrica de cola (no por CPU), network policies para egress del endpoint, y dashboards preconfigurados. El developer no escribe YAML de StatefulSet con toleraciones de GPU.
Qué deberían hacer los administradores y equipos técnicos
Evaluá tu scheduler hoy. Corré kubectl describe nodes | grep -A5 «Allocated resources» en tus nodos GPU. Si ves pods en Pending por «Insufficient nvidia.com/gpu» mientras hay MIG instances libres, necesitás DRA. Actualizá a Kubernetes ≥ 1.33, habilitá el feature gate DynamicResourceAllocation=true (GA desde 1.33, no requiere flag en 1.34+), y migrá los device plugins a ResourceClaimTemplates. El comando para verificar soporte: kubectl api-resources | grep resourceclaim.
Versioná modelos como artefactos OCI. Almacená modelos en tu registry (Harbor 2.12+, ECR, GCR) con OCI 1.1. Firmá con cosign: cosign sign –key cosign.key registry.example.com/models/llama3-70b:fp16. Integrá la verificación en ArgoCD con el plugin argocd-cosign o en Flux con image-reflector-controller + image-automation-controller que valida signature antes de sync.
Extendí tu stack de observabilidad sin crear un silo. Desplegá nvidia/dcgm-exporter como DaemonSet en nodos GPU. Exportá métricas de vLLM/TGI vía ServiceMonitor de Prometheus Operator. Agregá un dashboard en Grafana que correlacione: DCGM GPU metrics → kube-scheduler queue time → vLLM tokens/segundo → HTTP p99 del endpoint. El objetivo es una sola vista donde un spike en queue time se vincule con caída de throughput sin cruzar tres dashboards.
Definí un golden path de AI deployment. Creá un template en tu portal de plataforma (Backstage, Port, o un Helm chart versionado en Git) que incluya: ResourceClaim para la GPU solicitada, toleraciones y nodeSelector, ServiceMonitor, NetworkPolicy restrictiva, HPA basada en métrica de cola de inferencia (vllm:num_requests_waiting), y un job de evaluación post-deploy. El developer instancia el template, ajusta parámetros de modelo y recursos, y hace merge request. El pipeline valida, despliega y registra el artefacto.
Aplicá políticas de seguridad específicas. Usá Kyverno o OPA Gatekeeper para: prohibir endpoints de inferencia sin rate limiting por token, exigir imagePullPolicy y digest pinning en pods con GPU, y restringir egress de namespaces de AI a dominios de registry y storage permitidos.
Conclusión
La pregunta ya no es si Kubernetes ejecuta AI. Lo ejecuta, y bien. La pregunta operativa es si tu plataforma trata a un modelo de 70 GB con la misma rigurosidad de versionado, evaluación, observabilidad y self-service con la que trata un microservicio de 200 MB. El 7% de organizaciones que despliegan modelos a diario no son las que tienen más GPUs: son las que extendieron GitOps, DRA y observabilidad para que el ciclo de vida de un modelo sea tan repetible como el de un contenedor. Si tu equipo todavía diagnostica un endpoint caído revisando nvidia-smi en un nodo y no tiene un golden path para que un ML engineer suba un modelo sin pedir un ticket de infraestructura, la plataforma no está lista. Y la brecha no se cierra sola.
Fuentes
- https://www.cncf.io/blog/2026/08/28/your-kubernetes-platform-is-ready-for-containers-is-it-ready-for-ai/
- https://netflixtechblog.com/
- https://martinfowler.com/