Etiqueta
Kubernetes 1.35 GA consolida tres versiones de trabajo: sidecars nativos con ciclo de vida completo, DRA generalizada para FPGAs y NPUs, y un scheduler que reduce el desperdicio un 15-25 % en clusters heterogéneos. Balance desde la operación diaria: qué activar ya, qué vigilar antes de migrar y qué plan seguir si vienes de 1.30.
Kubernetes ganó la batalla de la orquestación, pero Docker Swarm sigue activo como parte de Docker Engine y tiene sentido real para equipos sin SRE dedicado, stacks self-hosted en 1-5 VPS y mini-clusters edge. Para esos contextos, la curva de aprendizaje mínima y el bajo coste operativo de Swarm superan las features avanzadas de Kubernetes.
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.
Seis meses después de la disponibilidad general de containerd 2.0 hay suficiente camino recorrido para evaluar la migración desde la rama 1.x en producción real. Repasamos qué cambia en el archivo de configuración, qué rompe en Kubernetes y en Docker Swarm, y cuándo compensa planificar el salto en vez de esperar.
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.
Kubecost y OpenCost asignan costes reales a namespaces, despliegues y etiquetas en Kubernetes. OpenCost, núcleo de código abierto bajo Apache 2.0, cubre los esenciales gratis. Kubecost añade visibilidad multi-clúster y billing cloud avanzado. Para clústeres con más de 5.000 USD/mes el ROI es inmediato: los ahorros identificados suelen superar el coste del software en el primer mes.
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.
En 2024, el debate sidecar sí o no ya tiene respuesta: Istio Ambient Mesh y Cilium Service Mesh llevan sidecarless a producción, mientras Linkerd sigue con sidecars ultraligeros en Rust. La elección correcta depende del CNI que ya usas, las funciones que necesitas y el tamaño de tu equipo de operaciones, no de qué proyecto es mejor en abstracto.
El carbon-aware computing ejecuta workloads flexibles cuando la red eléctrica emite menos CO2, logrando ahorros del 10-30% sin cambiar infraestructura ni reescribir aplicaciones. La intensidad de carbono varía hasta 16 veces según la hora y la zona; herramientas como Electricity Maps, WattTime y el Carbon Aware SDK permiten programar ese scheduling con datos reales de la red.
Fluent Bit es el recolector de logs de la CNCF: un binario en C de apenas 1,5 MB que rara vez supera los 30 MB de memoria en producción. Compite con Promtail, Vector y Filebeat, y gana cuando hay varios destinos o nodos con pocos recursos, gracias a un pipeline de entradas, parsers, filtros y salidas fácil de razonar y depurar.
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.
Cilium Service Mesh sustituye los sidecars de Istio o Linkerd por eBPF en el kernel: aplica políticas, cifrado WireGuard y observabilidad con Hubble sin un proxy por pod, y reduce el consumo de memoria de unos 100 GB a unos 5 GB en un clúster de 100 nodos. Conviene en clústeres grandes con equipos que dominan eBPF.
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.
Flux CD y ArgoCD son las dos herramientas GitOps graduadas por la CNCF para desplegar en Kubernetes usando Git como fuente de verdad. ArgoCD ofrece una interfaz visual centralizada que gestiona varios clusters desde una instancia; Flux es un conjunto de controllers nativos de Kubernetes con automatización de imágenes integrada. Ninguna opción es incorrecta: depende del equipo y el caso de uso.
ArgoCD ha consolidado GitOps como la práctica de despliegue estándar en Kubernetes: el repositorio Git es la única fuente de verdad del estado deseado, y el agente reconcilia el cluster de forma continua. Esta guía cubre los cuatro principios formales, las sync policies, los errores habituales en producción y la comparativa con Flux.
Un service mesh añade mTLS, observabilidad uniforme y gestión de tráfico entre microservicios sin modificar el código de las aplicaciones. El ecosistema está consolidado: Istio es el más completo y complejo, Linkerd prioriza la simplicidad con proxies en Rust, y Cilium aporta service mesh sin sidecars mediante eBPF.
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.
Kubernetes 1.27 ("Chill Vibes"), publicado en abril de 2023, estabiliza SeccompDefault para bloquear syscalls peligrosos por defecto, lleva KMS v2 a beta con claves rotables para cifrar secrets en etcd, y estabiliza los scheduling gates. También elimina PodSecurityPolicy sin alternativa de migración tardía: sin migrar antes a Pod Security Admission, el salto de versión queda bloqueado.
Cilium reemplaza iptables con programas eBPF en el kernel de Linux, sustituyendo cadenas lineales O(n) por lookups hash O(1). Los benchmarks muestran hasta un 50 % menos de latencia, el doble de throughput y un 70 % menos de CPU de kernel en clústeres Kubernetes.
Kubernetes 1.28 introduce sidecar containers nativos en alpha mediante KEP-753: añadir el campo restartPolicy Always a initContainers garantiza el orden de arranque y apagado correcto. Resuelve el problema de Jobs que nunca terminan. Istio, Linkerd y agentes de observabilidad como Fluent Bit son los beneficiarios directos.
Pixie usa eBPF para instrumentar automáticamente clústeres de Kubernetes sin modificar el código de la aplicación. Un agente por nodo captura tráfico HTTP, gRPC, SQL y Redis a nivel de kernel y expone en minutos mapa de servicios, perfiles de CPU y trazas SQL. Complementa a Prometheus para diagnóstico reactivo sin sidecars ni redeploys.
Migrar de monolito a microservicios implica dividir un sistema único en servicios independientes que se despliegan y escalan por separado. Se gana escalabilidad granular y autonomía de equipos, pero se suma complejidad operativa real: interfaces estables, orquestación con Kubernetes y una cultura DevOps madura son condiciones, no opcionales, para que compense.
