Resumen semanal del ecosistema cloud-native y SRE: OpenTelemetry, CNCF y SRE Weekly. Artículos y contenidos originales en inglés resumidos en español para facilitar el seguimiento de novedades, releases y tendencias del sector sin depender de ningún vendor concreto.
CNCF Blog
Where should AI workloads run? A sovereign and sensible approach
Publicado el 2026-07-10 — Leer artículo completo en CNCF Blog
Este artículo de KubeOps plantea una pregunta estratégica para organizaciones que adoptan IA: ¿dónde ejecutar estas cargas de trabajo? Mientras Kubernetes se consolida como base común para infraestructura de IA por su gestión de recursos y portabilidad, la decisión sobre dónde ejecutar los modelos (cloud público, privado, on-premises, colocación) sigue abierta y depende de factores como sensibilidad de datos, cumplimiento normativo y costes a largo plazo.
Los autores argumentan que no todas las cargas de IA requieren modelos de frontera propietarios: tareas rutinarias pueden ejecutarse con modelos de pesos abiertos (open-weight) o versiones anteriores, especialmente cuando involucran datos sensibles o procesos regulados. Destacan que los costes de IA como servicio inevitablemente subirán conforme las empresas necesiten rentabilizar inversiones masivas en infraestructura, lo que hace menos viable el modelo «simplemente contrata una suscripción». Para sectores regulados (trabajan con administración pública alemana), la soberanía digital requiere cinco elementos: autonomía operacional, cumplimiento normativo, auditabilidad, portabilidad y resiliencia.
La recomendación práctica es realizar un «AI readiness check» antes de mover cargas serias: evaluar capacidad de aceleradores, rendimiento de almacenamiento, localidad de datos, aislamiento de red, monitorización, backup y gestión de vulnerabilidades. El mensaje central es construir plataformas que preserven opciones: cargas portables, operaciones reproducibles, seguridad aplicable y costes visibles, aprovechando Kubernetes y el ecosistema CNCF para adaptarse a cambios en modelos, regulaciones y requisitos de negocio sin reconstruir la plataforma cada vez.
Navigating the ingress-NGINX retirement
Publicado el 2026-07-09 — Leer artículo completo en CNCF Blog
El controlador ingress-nginx mantenido por Kubernetes SIG Network alcanzó su fin de vida en marzo de 2026. Este artículo aclara un malentendido común: no es la API de Ingress la que se retira, sino únicamente este controlador específico mantenido por la comunidad. Las organizaciones que continúen usándolo enfrentan riesgos operacionales graves: CVEs sin parchar, ausencia de actualizaciones de funcionalidad y pérdida total del soporte comunitario.
El artículo presenta dos caminos de migración. El Camino A es un «lift-and-shift» hacia otro controlador de Ingress como Contour (basado en Envoy), manteniendo los recursos YAML existentes pero requiriendo traducir manualmente todas las anotaciones propietarias nginx.ingress.kubernetes.io/*. El Camino B implica migrar a Gateway API, el sucesor oficial respaldado por la comunidad upstream. Gateway API introduce un diseño orientado a roles que separa explícitamente las preocupaciones de infraestructura (Gateway, gestionado por operaciones) de las de enrutamiento de aplicaciones (HTTPRoute, gestionado por desarrollo). Aunque requiere reescribir completamente los manifiestos de enrutamiento, ofrece capacidades avanzadas estandarizadas y desarrollo activo continuo, mientras que la API de Ingress está congelada en funcionalidades.
Para equipos con restricciones severas de tiempo, migrar lateralmente a Contour proporciona una solución temporal que permite planificar la modernización con más calma. Sin embargo, es importante entender que esto es solo una medida provisional. El artículo recomienda herramientas como ingress2gateway para automatizar la traducción y sugiere despliegues incrementales comenzando por cargas de trabajo no críticas. La decisión apropiada depende de las restricciones operacionales, plazos de migración y objetivos arquitectónicos a largo plazo de cada organización.
The CNCF Data Storage in Cloud Native AI White Paper
Publicado el 2026-07-08 — Leer artículo completo en CNCF Blog
El TAG Infrastructure de la CNCF ha publicado un white paper técnico que aborda los desafíos específicos de almacenamiento al ejecutar cargas de trabajo de AI/ML en infraestructura cloud-native. El documento identifica tres cuellos de botella críticos: la «trampa de archivos pequeños» (millones de ficheros que saturan los servidores de metadatos), la sobrecarga de llamadas API en arquitecturas desacopladas de cómputo-almacenamiento, y los perfiles de carga radicalmente diferentes entre entrenamiento (alto throughput sostenido) e inferencia (baja latencia, tráfico irregular).
El paper estructura el ecosistema en capas técnicas: data lake houses con formatos abiertos (Apache Parquet, Iceberg), bases de datos vectoriales para embeddings y RAG (menciona Milvus), estrategias de caché y localidad de datos destacando el proyecto CNCF Fluid, interfaces estandarizadas (CSI para block/file, COSI para object storage), y pipelines modernos con CDC y streaming. Dedica secciones específicas a los requisitos de almacenamiento en cada fase: entrenamiento (tolerancia a acceso no secuencial, checkpointing masivo), inferencia (KV caching, prefix caching), y la emergente arquitectura de agentes AI que requiere memoria de corto plazo mutable, repositorios de artefactos intermedios y consolidación de sesiones pasadas.
Especialmente relevante para equipos de plataforma e ingenieros SRE que diseñan infraestructura para cargas AI/ML, o que enfrentan problemas de utilización de GPU por limitaciones de I/O. El TAG invita a contribuir en su repositorio y canal #tag-infrastructure en Slack de CNCF.
Network boundary for AI agents using NGINX and OpenTelemetry
Publicado el 2026-07-08 — Leer artículo completo en CNCF Blog
Este artículo presenta un patrón arquitectónico para controlar y auditar el tráfico de red de agentes de IA autónomos, combinando NGINX como plano de control de tráfico y OpenTelemetry como plano de auditoría. El autor propone usar NGINX en doble rol: como reverse proxy para tráfico entrante y como forward proxy para tráfico saliente del agente, forzando que todas las peticiones pasen por este punto de control mediante reglas de iptables que bloquean cualquier otra ruta de salida.
La implementación genera spans de OpenTelemetry para cada petición, permitiendo correlacionar interacciones de usuarios con llamadas externas del agente y alimentar herramientas de observabilidad como Jaeger, Grafana o plataformas SIEM. El autor validó el diseño desplegando OpenClaw (un agente de IA) en Kubernetes junto con Ollama, NGINX y un OpenTelemetry Collector, demostrando control granular sobre qué dominios puede acceder el agente. El código está disponible en el repositorio OpenClaw Network Boundary.
El artículo reconoce explícitamente las limitaciones: este enfoque controla el comportamiento de red pero no garantiza que las decisiones del agente sean correctas o seguras, y debe considerarse una capa más dentro de una estrategia de defensa en profundidad. Interesará especialmente a equipos de plataforma e ingenieros SRE que estén evaluando cómo integrar cargas de trabajo de IA en infraestructuras cloud-native existentes sin introducir componentes completamente nuevos.
Two months of Open Community Groups
Publicado el 2026-07-07 — Leer artículo completo en CNCF Blog
La CNCF lanzó hace dos meses Open Community Groups (OCG), una plataforma open source para gestionar meetups y eventos de comunidad. El proyecto llevaba casi dos años en desarrollo antes de su lanzamiento, motivado por la falta de opciones open source que se ajustaran a las necesidades reales de las comunidades cloud-native. En lugar de adaptar una solución existente, decidieron construir su propia plataforma desde cero.
La migración se realizó el fin de semana del 2 de mayo mediante un snapshot de la plataforma anterior, con algunos problemas iniciales de DNS que se resolvieron en la primera semana. Las cifras actuales muestran 289 grupos, más de 89.000 miembros, 6.024 eventos y 146.182 asistentes. Los Kubernetes Community Days (KCD) y eventos virtuales permanecen temporalmente en la plataforma antigua mientras se completa su integración.
Las prioridades inmediatas incluyen implementar funcionalidad de pago para eventos como KCDs e integración más estrecha con el ecosistema CNCF (Slack, listas de correo). El proyecto está completamente abierto a contribuciones de la comunidad, con más de 68 issues cerrados y 408 pull requests fusionados hasta la fecha. Interesante para organizadores de comunidades cloud-native y quienes busquen alternativas open source a plataformas comerciales de gestión de eventos.
Why sandboxing your agent is not enough
Publicado el 2026-07-07 — Leer artículo completo en CNCF Blog
Lin Sun, CNCF Ambassador, explora dos proyectos complementarios para ejecutar agentes de IA en Kubernetes: agent-sandbox (parte de Kubernetes SIG Apps) y agent-substrate. Mientras que agent-sandbox se centra en proporcionar aislamiento, identidades fuertes y gestión del ciclo de vida mediante CRDs de Kubernetes, agent-substrate aborda un problema diferente: la eficiencia de recursos y escalabilidad. En lugar de mantener agentes ejecutándose continuamente en pods dedicados, agent-substrate permite que los agentes se ejecuten bajo demanda en un pool compartido de workers, suspendiéndose cuando están inactivos y reanudándose cuando se necesitan.
El artículo argumenta que el sandboxing es necesario pero no suficiente. En entornos con recursos limitados, mantener cientos de agentes ejecutándose permanentemente es inviable, pero arrancarlos y pararlos constantemente añade latencia y sobrecarga. Agent-substrate resuelve este dilema desacoplando el ciclo de vida del pod worker del «actor» del agente, permitiendo que múltiples agentes compartan la misma infraestructura. El autor demuestra cómo integró agent-substrate con kagent, logrando que seis agentes AIRE compartan un único worker pod cuando no se ejecutan concurrentemente, escalando horizontalmente solo cuando aumenta la concurrencia.
Especialmente relevante para equipos de plataforma que evalúan arquitecturas para cargas de trabajo de IA en Kubernetes, donde el coste y la eficiencia de recursos son preocupaciones críticas. El enfoque propone un modelo de agentes efímeros y bajo demanda, similar a serverless, pero manteniendo las garantías de seguridad y aislamiento mediante runtimes ligeros como gVisor o Kata Containers.
The 4-body problem of SRE: Why autonomous operations depend on context
Publicado el 2026-07-06 — Leer artículo completo en CNCF Blog
Sanjeev Sharma, Field CTO de StackGen, propone un marco conceptual para entender por qué las operaciones autónomas basadas en IA siguen siendo problemáticas: el «problema de los 4 cuerpos» de SRE. Basándose en conversaciones con SREs senior en Bengaluru, argumenta que el verdadero obstáculo no es la capacidad de los modelos de IA, sino la fragmentación del contexto operacional.
Los cuatro «cuerpos» que deben integrarse son: (1) código (commits, builds, configuraciones), (2) estado de infraestructura (lo que Terraform dice vs. lo que realmente existe), (3) señales de runtime (métricas, logs, trazas, SLOs), y (4) conocimiento operacional (runbooks, post-mortems, memoria tribal). El problema es que cada uno vive en silos aislados, y las decisiones críticas requieren razonar sobre los cuatro simultáneamente. Históricamente, solo ingenieros senior con años de experiencia pueden mantener esta visión completa en sus cabezas—lo que Sharma llama «people putty» (masilla humana).
La propuesta concreta: antes de desplegar agentes autónomos, las organizaciones deben construir un grafo de conocimiento unificado y versionado que integre estos cuatro cuerpos en tiempo real, con sus relaciones causales. Sin este sustrato, los agentes producen «alucinaciones plausibles»—errores que parecen razonables pero son incorrectos. Además, cada decisión del agente debe generar una traza auditable (inputs, políticas aplicadas, versión del modelo, hipótesis consideradas, acción tomada) para cumplir requisitos de compliance y debugging. El artículo es especialmente relevante para equipos de plataforma que están evaluando dónde invertir en automatización: primero el grafo, después los agentes.
Evolving platform engineering for AI-native workloads
Publicado el 2026-07-06 — Leer artículo completo en CNCF Blog
Nota del editor: Este artículo es contenido patrocinado por VMware/Broadcom que introduce el concepto de «Platform Engineering 2.0» como marco para discutir la evolución de las plataformas internas hacia cargas de trabajo de IA. Aunque presenta ideas válidas sobre los desafíos actuales, el contenido tiene un claro sesgo comercial.
El artículo argumenta que las plataformas actuales (denominadas «Platform Engineering 1.0») se diseñaron principalmente para flujos de trabajo centrados en desarrolladores y contenedores, pero ahora enfrentan nuevos requisitos: aceleración de código mediante IA, agentes autónomos que consumen servicios de plataforma, presión regulatoria sobre soberanía de datos, necesidad de servir a múltiples perfiles (científicos de datos, ingenieros ML, equipos FinOps) más allá de desarrolladores, y gestión de costos de infraestructura de IA (especialmente GPUs).
Propone cinco pilares para esta evolución: plataformas nativas de IA (con soporte de primera clase para GPUs, registro de modelos, gateways MCP), experiencia multi-persona (extendiendo más allá de desarrolladores), FinOps embebido (decisiones de costo en tiempo de aprovisionamiento), seguridad integrada en runtime (no solo shift-left), y diseño composable basado en componentes CNCF intercambiables. El artículo menciona que el grupo técnico de Platform Engineering de CNCF está trabajando en la intersección de plataformas e IA, aunque no detalla iniciativas concretas.
Interesa a equipos de plataforma y SREs que estén evaluando cómo adaptar sus IDPs para soportar cargas de trabajo de ML/IA, aunque conviene leer con perspectiva crítica dado el origen comercial del contenido.
SRE Weekly
SRE Weekly Issue #524
Publicado el 2026-07-06 — Leer artículo completo en SRE Weekly
Esta edición de SRE Weekly reúne varios artículos centrados en aspectos humanos y organizativos de la fiabilidad, junto con algunos temas técnicos específicos. Destaca especialmente el artículo sobre «self-blame» (autocrítica) de Brent Chapman, que argumenta que culparse a uno mismo es tan perjudicial para el aprendizaje como recibir culpa externa: ambos cierran la puerta al análisis constructivo de incidentes.
En el frente técnico, Aksel Allas comparte una solución práctica para organizaciones grandes en GCP: cómo monitorizar automáticamente las cuotas de recursos y APIs a través de múltiples proyectos, un problema que puede causar incidentes inesperados cuando se alcanzan límites desconocidos. Otro artículo interesante cuestiona la complejidad innecesaria: Jos Visser plantea que a veces un sistema de alta disponibilidad complejo puede ser menos fiable que una solución simple de un solo host, debido a la dificultad operativa.
La edición también explora el papel de la IA en SRE desde dos ángulos: Hamed Silatani advierte que usar IA para acelerar el trabajo puede chocar con el «eslabón débil» humano del sistema sociotécnico, mientras que Oren Eini y el artículo de ACM Queue sobre verificación formal sugieren casos de uso más específicos, como generar código desechable para incidentes o ayudar a escribir pruebas formales. Interesante para SREs que buscan equilibrar cultura de aprendizaje con adopción pragmática de nuevas herramientas.
Este resumen se genera semanalmente de forma automática a partir de los feeds RSS oficiales de cada fuente. Los artículos originales son propiedad de sus respectivos autores. Los enlaces apuntan siempre a la fuente original.
