A principios de 2026, varias plataformas de orquestación incluyen carbon-aware scheduling como opción por defecto o muy visible. Con meses de datos reales, toca evaluar si la promesa de reducir emisiones sin dañar rendimiento se cumple y en qué escenarios.
Con 1.34 liberado en agosto de 2025 y el ciclo de 1.35 en su última fase de congelación de funciones, qué llegará estable, qué quedará en beta, qué nos interesa a quienes mantenemos clústeres pequeños o medianos y qué podemos ignorar sin culpa hasta el siguiente ciclo.
La integración de WebAssembly dentro de containerd como tiempo de ejecución alternativo ha madurado. Ya es posible desplegar cargas mixtas Linux y Wasm en el mismo clúster de Kubernetes con argumentos operativos sólidos. Cuándo compensa y cuándo no.
La release 1.33 llega el 23 de abril con el nombre Octarine, y el sneak peek oficial de marzo ya deja ver las líneas fuertes: in-place pod resize pasa a beta con el gate activado por defecto, los sidecar containers alcanzan por fin GA, y llegan varias deprecaciones de seguridad y de la API de endpoints que conviene revisar antes del upgrade.
El profiling continuo con eBPF captura flame graphs de CPU de todos los procesos de un nodo Linux las 24 horas, sin instrumentar código ni reiniciar servicios, con menos del 1 % de overhead. Parca cubre el clúster completo, Beyla añade métricas y trazas HTTP/gRPC automáticas, y Pyroscope aporta detalle nativo por lenguaje en los servicios más críticos.
Kubernetes 1.30, publicada en abril de 2024, lleva ValidatingAdmissionPolicy a disponibilidad general y elimina la necesidad de webhooks externos para políticas CEL. Añade pod scheduling readiness para controlar cuándo entra un pod en el ciclo de scheduling, y job success policy para definir qué índices deben completar un Job distribuido.
Kubernetes 1.31 no trae fuegos artificiales, pero cierra deudas antiguas: AppArmor llega a GA, los sidecars nativos ya funcionan habilitados por defecto camino a su estable en 1.33, y DRA avanza en alpha hacia la beta. Repaso práctico desde la óptica de quien opera clústeres en producción.
Contenerizar SCADA tiene sentido en las capas superiores de la arquitectura: HMI, historians y gateways de datos. Los PLCs siguen controlando el hardware con determinismo duro. El mayor riesgo es cultural: aplicar patrones DevOps sin adaptar al contexto OT produce incidentes. NIS2 exige gestionar los contenedores como cualquier activo de infraestructura critica.
Falco es un proyecto graduado de la CNCF que engancha el kernel de Linux con eBPF y detecta comportamientos anómalos en syscalls sin instrumentar ninguna aplicación. Se despliega como DaemonSet en Kubernetes, emite eventos en JSON y necesita proceso de triaje para aportar valor. En producción, la alert fatigue es el problema más común.
containerd es el runtime que ejecuta los contenedores en la mayoría de los clusters Kubernetes modernos, y casi nadie lo nota. Gestiona todo el ciclo de vida del contenedor: descarga de imagen, arranque, red y montaje de filesystem. Se convirtió en el runtime por defecto tras la retirada del dockershim en Kubernetes 1.24, en mayo de 2022.
7 min2444,4
Usamos cookies propias y de terceros para analizar el tráfico del sitio. Puedes aceptarlas, rechazarlas o configurar tu elección.
Más información sobre las cookies
Preferencias de cookies
NecesariasImprescindibles para el funcionamiento del sitio. Siempre activas.
AnalíticasNos ayudan a entender cómo se usa el sitio (Google Analytics).