Etiqueta
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.
Hace cuatro años era una curiosidad académica. Hoy, planificar cargas por intensidad de carbono de la red eléctrica es una opción integrada de fábrica en Kubernetes, en varios servicios de proveedores cloud y en herramientas de CI. Repasamos qué cambió de verdad y qué sigue siendo más promesa que práctica.
Kubernetes 1.34 llega con la asignación dinámica de recursos (DRA) graduada a estable, mejoras en el planificador y políticas de mutación en CEL que sustituyen a los webhooks. Un repaso práctico de lo que conviene actualizar ya, lo que puede esperar, y qué cambia de verdad para equipos con clusters en producción.
Kubernetes 1.32 Penelope se publicó en diciembre y lleva varios meses rodando en clusters. Es buen momento para mirar qué cambios han envejecido bien, cuáles han generado trabajo extra y qué aprendizajes llevarse al salto hacia 1.33.
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.
Sigstore se ha consolidado como estándar de firma para artefactos OCI. GHCR es el registro mejor integrado; Harbor 2.5+ y Quay ofrecen soporte nativo; AWS ECR empuja su propio esquema KMS. La verificación vale en tres puntos: admission controller del cluster, capa GitOps y pipeline CI/CD. El Rekor público tiene rate limits que, a partir de cierto volumen, obligan a instalar una instancia propia.
Linkerd es el service mesh para Kubernetes que elige simplicidad frente a catálogo de funcionalidades. Su proxy en Rust consume ~10 MB de RAM por sidecar, frente a los 50-100 MB de Envoy bajo Istio. Esta comparativa explica cuándo vale la pena adoptarlo, qué cuesta operarlo y cuándo Istio tiene más sentido.
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.
