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
How data sovereignty is changing cloud native infrastructure design
Publicado el 2026-07-03 — Leer artículo completo en CNCF Blog
Este artículo de VEXXHOST analiza cómo la soberanía de datos está dejando de ser un problema de geografía para convertirse en una cuestión de control jurisdiccional. El punto central: no importa dónde esté físicamente tu servidor, sino qué leyes pueden obligar a quien lo opera a entregar los datos. Leyes como el CLOUD Act estadounidense permiten acceder a datos independientemente de su ubicación física si el proveedor está bajo jurisdicción de ese país. La propuesta europea CADA (Cloud and AI Development Act) de junio 2026 introduce un marco de cuatro niveles de soberanía para contratación pública cloud, mientras que regulaciones como NIS2 y DORA enfatizan resiliencia operacional y riesgo de concentración de proveedores.
El patrón arquitectónico que está emergiendo en producción combina Kubernetes como capa de control y políticas, OpenStack como infraestructura subyacente soberana, y GitOps para operaciones declarativas. Organizaciones reguladas europeas (operadores ferroviarios nacionales, bancos, telecoms) ya ejecutan cargas de trabajo a escala con esta arquitectura. Kubernetes permite implementar requisitos de soberanía mediante admission controllers, node affinity y motores de políticas (OPA/Gatekeeper, Kyverno) que rechazan recursos no conformes antes de llegar a producción. OpenStack proporciona los servicios de infraestructura (Ironic para bare metal, Keystone para identidad, Neutron para red, Ceph para almacenamiento) completamente autoalojados, sin dependencias externas obligatorias.
El artículo destaca que GitOps es clave para operar múltiples entornos jurisdiccionales de forma consistente: cada cluster reconcilia su estado desde Git de forma autónoma, sin plano de control centralizado, manteniendo trazabilidad completa de cambios. También menciona que la soberanía se está extendiendo a infraestructura de IA: el entrenamiento federado permite entrenar modelos donde residen los datos, usando los mismos controles de políticas y límites de namespace. Especialmente relevante para arquitectos de plataforma, SREs e ingenieros trabajando en sectores regulados o con requisitos de soberanía de datos.
(re)introducing kpt: Your toolchain for infrastructure automation
Publicado el 2026-07-02 — Leer artículo completo en CNCF Blog
Kpt es un proyecto sandbox de CNCF que acaba de completar su incorporación oficial. Se trata de una herramienta CLI para automatizar la gestión de infraestructura Kubernetes mediante el paradigma «Configuration as Data»: la configuración se almacena como datos estructurados (manifiestos KRM/YAML) en lugar de código ejecutable, lo que facilita auditoría, versionado y validación sin necesidad de ejecutar nada.
Lo que diferencia a kpt de herramientas como Kustomize es su enfoque de actualización «in-place»: las transformaciones se aplican directamente sobre los archivos, permitiendo revisar y aprobar el estado final exacto antes del despliegue (WYSIWYG). Separa claramente la configuración pura (paquetes KRM) de la lógica de negocio (funciones KRM), reduciendo efectos secundarios y deriva de configuración. Kpt se integra bien con ArgoCD, Flux, Helm y otros, posicionándose como una pieza modular dentro del ecosistema GitOps.
El proyecto se utiliza activamente en Nephio para desplegar redes RAN y core sobre Kubernetes. Los planes inmediatos incluyen mejorar el rendimiento de pipelines, estabilizar APIs hacia v1, añadir soporte para secretos y multi-cluster, y reestructurar la documentación. Las reuniones del proyecto son semanales (miércoles 14:00 CET) y buscan ampliar su comunidad de usuarios y contribuidores.
Understanding dynamic resource allocation in Kubernetes
Publicado el 2026-07-01 — Leer artículo completo en CNCF Blog
Dynamic Resource Allocation (DRA) alcanzó GA en Kubernetes v1.35, marcando un cambio significativo en cómo los clústeres asignan dispositivos especializados como GPUs. Este tutorial práctico, escrito por un CNCF Ambassador usando el laboratorio CNTUG Infra Labs en Tokio, demuestra cómo DRA supera las limitaciones del Device Plugin tradicional mediante cuatro escenarios reales con GPUs NVIDIA (Tesla T10 y RTX A5000).
Los conceptos clave son DeviceClass (categorías de dispositivos), ResourceSlice (inventario automático por nodo), ResourceClaim (asignación compartida entre pods) y ResourceClaimTemplate (asignación dedicada por pod). El artículo muestra cómo seleccionar GPUs por modelo específico usando expresiones CEL, establecer requisitos mínimos de memoria (ej: >20 GiB), implementar preferencias ordenadas con fallback automático, y habilitar Time Slicing—todo sin necesidad de nodeSelectors complejos ni colocación manual de dispositivos. A partir de v1.36, DRA también reportará el estado de salud de los dispositivos, permitiendo distinguir fallos de hardware de errores de aplicación.
Especialmente relevante para ingenieros de plataforma y SREs que gestionan cargas de trabajo con GPUs o aceleradores. El artículo incluye manifiestos YAML completos y comandos verificables, facilitando la experimentación inmediata. La maduración de DRA abre la puerta a que Cluster Autoscaler provisione nodos con GPUs bajo demanda, mejorando la eficiencia en clústeres heterogéneos.
Kepler, re-architected: Improved power accuracy and a community call to action!
Publicado el 2026-06-30 — Leer artículo completo en CNCF Blog
Kepler, el proyecto sandbox de la CNCF que mide y atribuye consumo energético a workloads de Kubernetes, ha sido completamente reescrito. La arquitectura anterior dependía de eBPF para capturar señales de utilización, lo que requería privilegios CAP_BPF y CAP_SYSADMIN (un bloqueador en muchos entornos de producción) y generaba problemas de precisión al perder procesos de corta duración. La nueva versión elimina eBPF y utiliza acceso de solo lectura a /proc y /sys, reduciendo drásticamente los requisitos de privilegios y simplificando el despliegue mediante Helm.
Los cambios de arquitectura incluyen descubrimiento dinámico de la estructura de medidores de energía del hardware en tiempo de ejecución, en lugar de asumir topologías hardcodeadas (como RAPL). Dos experimentos de validación demuestran mejoras significativas: las métricas de la nueva versión siguen fielmente los patrones de IPMI (el medidor BMC de hardware) eliminando los picos de varios kilovatios que mostraba la versión anterior, y el gap de atribución entre energía total del nodo y energía distribuida a procesos individuales es prácticamente cero (fluctuaciones de solo milivatios). El proyecto alcanza ahora un 90% de cobertura de tests.
El equipo solicita contribuciones de la comunidad en tres áreas específicas: validar la monitorización experimental de GPU (crítica para workloads de IA), entrenar modelos de estimación de energía para entornos virtualizados donde no hay acceso a contadores hardware, y validar precisión de datos contra medidores físicos (IPMI u otros). También planean mejorar la atribución de consumo en idle, actualmente simplificada. Interesa especialmente a equipos que ejecutan Kubernetes en bare metal o con workloads intensivos en GPU/ML.
Dragonfly v2.5.0 is released
Publicado el 2026-06-30 — Leer artículo completo en CNCF Blog
Dragonfly, el sistema de distribución de contenido P2P de la CNCF, lanza su versión 2.5.0 con mejoras significativas en automatización y control de descargas. La novedad más destacada es la descarga directa de repositorios desde Hugging Face y ModelScope mediante comandos como dfget hf:// y dfget modelscope://, acelerando la distribución de modelos de IA mediante P2P mientras los metadatos se obtienen por Git. También introduce dragonfly-injector, un webhook de Kubernetes que inyecta automáticamente capacidades P2P en Pods mediante anotaciones, eliminando la necesidad de reconstruir imágenes de contenedor.
En el plano operativo, la versión añade listas de bloqueo configurables desde la consola del Manager para controlar descargas problemáticas (devolviendo PermissionDenied en gRPC o FORBIDDEN en HTTP), y amplía las capacidades de limitación de velocidad tanto en el plano de control como en clientes. Se simplifica la configuración de proxy de registros de contenedores: ahora dfdaemon puede inferir el registro upstream del parámetro ns de containerd, permitiendo enrutar todos los registros con un único archivo hosts.toml. La nueva herramienta CLI dfctl facilita la gestión de tareas locales y el precalentamiento de caché.
Entre las correcciones críticas destacan arreglos en scripts Lua de Redis que causaban expiración incorrecta de peers, problemas de secuencias SERIAL en PostgreSQL que generaban conflictos de clave primaria, y manejo mejorado de redirecciones HTTP 307 relativas. La versión también incluye actualizaciones de Nydus con soporte para blobs optimizados para prefetch, conversión a formato OCI, y backend virtio-pmem basado en uffd para escenarios Kata. Interesa especialmente a equipos que distribuyen modelos de IA, operan clusters Kubernetes con alto volumen de descargas de imágenes, o necesitan control granular sobre tráfico de red.
OTel and mesh-derived metrics: A 2026 reference
Publicado el 2026-06-29 — Leer artículo completo en CNCF Blog
Este artículo técnico explica cómo integrar métricas derivadas de un service mesh (específicamente Linkerd 2.19+) en un pipeline existente de OpenTelemetry Collector. El autor demuestra que ambas capas de observabilidad son complementarias: OTel instrumenta la aplicación y captura métricas de negocio y trazas distribuidas, mientras que el proxy del mesh observa todo el tráfico este-oeste entre servicios a nivel de red, sin modificar código, proporcionando métricas golden (tasa de peticiones, latencia, errores) con identidad mTLS y clasificación de fallos gRPC que el código de aplicación no ve.
El artículo incluye una configuración de referencia completa y probada: K3s v1.34.6, Linkerd edge-26.5.5, OpenTelemetry Demo como carga de trabajo, OTel Collector contrib 0.118.0 como DaemonSet, y VictoriaMetrics con Grafana. La integración se realiza mediante un pipeline dedicado en el Collector que descubre automáticamente todos los pods con proxy Linkerd (puerto 4191), filtra las 5 familias de métricas más relevantes (response_total, response_latency_ms, y tres contadores TCP), las etiqueta con layer=mesh y las enriquece con metadatos de Kubernetes. El autor documenta explícitamente un problema de compatibilidad con expansión de variables de entorno en versiones anteriores del Collector y advierte sobre la cardinalidad: en su laboratorio, solo response_latency_ms_bucket generó 5.642 series temporales tras el filtrado.
Especialmente útil para equipos SRE y de plataforma que ya ejecutan OpenTelemetry y consideran adoptar un service mesh, o viceversa. El artículo desmitifica la superposición (ambas capas miden tasa de peticiones y latencia, pero desde perspectivas diferentes) y la complementariedad (el mesh detecta fallos gRPC que pasan desapercibidos en HTTP 200; las trazas explican por qué falló). Incluye configuración YAML descargable y dashboard de Grafana listo para usar.
etcd-operator joins Cozystack with a new v1alpha2 API
Publicado el 2026-06-29 — Leer artículo completo en CNCF Blog
El proyecto etcd-operator, originalmente desarrollado por Ænix, ha sido donado a Cozystack y lanza una implementación completamente nueva bajo la API etcd-operator.cozystack.io/v1alpha2. El cambio arquitectónico más significativo: en lugar de usar StatefulSets, el operador ahora gestiona directamente la API de membresía nativa de etcd (MemberAdd, MemberPromote, MemberRemove), lo que le da control total sobre el clúster. Cada miembro se representa mediante un recurso EtcdMember independiente que posee su propio Pod y PVC.
Entre las capacidades destacadas: escalado bidireccional miembro a miembro con joins en modo learner, pausar clústeres sin perder datos (spec.replicas: 0), almacenamiento en PVC o tmpfs, TLS configurable para conexiones cliente y peer (con renovación automática vía cert-manager), snapshots a S3 o PVC, validación CEL en el CRD sin necesidad de webhooks, y un PodDisruptionBudget automático que protege el quorum. Incluye además una herramienta de migración in-place (etcd-migrate) que permite adoptar clústeres del operador v1alpha1 sin reiniciar Pods ni perder quorum.
El artículo incluye una comparación detallada con el operador oficial de etcd-io: aunque el operador oficial está en desarrollo activo, esta implementación ya cubre la mayoría de su roadmap y añade funcionalidades específicas para casos multi-tenant (Cozystack, Kamaji) como scale-to-zero, soporte del subrecurso /scale para kubectl y VPA, y el plugin kubectl-etcd para operaciones de día 2. Relevante para equipos que gestionan etcd en Kubernetes, especialmente en entornos multi-tenant o que requieran control granular sobre la membresía del clúster.
SRE Weekly
SRE Weekly Issue #523
Publicado el 2026-06-29 — Leer artículo completo en SRE Weekly
Esta edición de SRE Weekly destaca varios temas fundamentales para la gestión de incidentes y la observabilidad. El editor, Lex Neva, comienza con una reflexión importante sobre accesibilidad: descartó artículos que contenían información relevante en imágenes sin texto alternativo, recordando que muchos profesionales leen contenido técnico mediante lectores de pantalla.
Entre los artículos más relevantes: un análisis de por qué los incident commanders tienden a abandonar su rol para ponerse a depurar (la solución: delegar en un tech lead competente), y una crítica técnica sobre la correlación de logs, métricas y trazas a escala. Este último advierte que si tus tres tipos de telemetría no pueden relacionarse programáticamente hoy, añadir una capa de IA no resolverá el problema fundamental. También destaca un post-mortem de Honeycomb sobre un mantenimiento de Kafka que técnicamente fue exitoso, pero falló en la comunicación previa—un ejemplo de transparencia poco común. Finalmente, incluye una historia de debugging profundo sobre un bug en la librería HTTP hyper, y reflexiones sobre el uso de IA como herramienta (no solución mágica) en refactorizaciones de sistemas críticos en producción.
Especialmente útil para SREs que gestionan incidentes, equipos que trabajan con observabilidad distribuida, y cualquiera interesado en post-mortems honestos y debugging de bajo nivel.
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.
