Kubernetes 1.36 (Haru): qué cambia de verdad en producción

Kubernetes 1.36 (Haru) entró en GA el 22 de abril de 2026. El hilo conductor del release es «empujar la complejidad al núcleo de la plataforma»: menos glue externo (admission webhooks, adaptadores de métricas, log shippers a medida), más endpoints incorporados y CEL dentro del propio API server. Para un equipo de plataforma eso significa que parte del zoo habitual de servicios sidecar por fin se puede jubilar — pero no en todos los sitios donde los blogs gritan «GA». Conviene contrastar con la tabla oficial de feature-gates, porque alrededor de la mitad de los repasos sobre 1.36 ya discrepan con la realidad.

Los mutating webhooks empiezan a morir

MutatingAdmissionPolicy ha llegado a GA — la mutación vive ahora como una expresión CEL dentro de kube-apiserver. Sin webhook HTTP externo, sin rotación TLS, sin pods aparte, sin paneles up{job="...-webhook"}, sin timeouts. Una clase entera de incidentes desaparece en un solo release: certificado caducado, Gatekeeper inalcanzable, latency spike en admission que tira abajo cada CREATE/UPDATE del clúster.

No significa que Kyverno y Gatekeeper se vayan mañana. Las policies complejas con lookups cross-object, la generación de recursos y la image-verification siguen perteneciendo a motores externos. Pero las mutaciones tipo plantilla del estilo «inyectar HTTP_PROXY en cada pod de este namespace» viven ahora de forma nativa en el API server y se pueden probar en staging sin curlar un webhook.

Ingress NGINX ha sido retirado

El 24 de marzo de 2026 SIG Network y el Security Response Committee declararon ingress-nginx retired: sin releases, sin bugfixes, sin parches de seguridad. Las instalaciones existentes siguen sirviendo tráfico — no es un kill switch. Pero las configuraciones cargadas de anotaciones son ahora deuda técnica con un reloj corriendo. Opciones objetivo: Envoy Gateway, Cilium Gateway, ALB/Lattice en los proveedores de nube, con Gateway API como capa de abstracción. La auditoría de migración empieza por el inventario: cuántas features de anotaciones se usan realmente, y cuántas de ellas tienen equivalencia 1:1 en Gateway API. A menudo resulta que el 80 % de las anotaciones son rewrite-target y proxy-buffer-size — esas migran rápido.

HPA Scale-to-Zero es alpha, no GA

Aquí está el mayor ruido. El feature-gate HPAScaleToZero lleva en alpha desde K8s 1.16 y en 1.36 sigue en alpha, default false. Varios repasos afirman lo contrario — es desinformación. Verificar contra la documentación de feature-gates, no contra Medium.

Lo que realmente funciona en 1.36 si se activa --feature-gates=HPAScaleToZero=true en kube-apiserver: HPA puede llevar nativamente a minReplicas: 0 para métricas Object y External (por ejemplo, sqs_queue_length), pero no para CPU/memoria. El adaptador de métricas sigue siendo necesario. En la práctica esto implica que KEDA mantiene su relevancia, porque su catálogo de scalers cubre todas las fuentes que la cadena de métricas nativa de Kubernetes no toca. El combo «Karpenter + HPA scale-to-zero + fuente KEDA» es el Kubernetes serverless que se esperaba desde 2019.

User Namespaces GA — la mayor victoria de seguridad en años

El root del contenedor se mapea a un usuario sin privilegios en el host. Un container breakout al estilo de la CVE de runc aterriza en una sandbox con cero privilegios en lugar de host-root. Para clústeres multi-tenant es el cambio más material del modelo de amenaza en varios años. Se activa con userNamespaces: true en la pod spec, más kernel ≥ 6.5 en los nodos. Las AMI estándar de EKS/GKE ya lo entregan; en bare-metal y Talos, verificar antes de dar por hecho.

Madurez operacional silenciosa

Un puñado de cosas que no son titulares pero cambian el día a día:

• In-Place Vertical Pod Scaling ahora funciona incluso con la policy Static del CPU Manager: VPA muta requests/limits sin restart y sin perder el CPU pinning. Para workloads high-perf VPA pasa a ser por fin verdaderamente no disruptivo.
• Ephemeral Service Account Tokens para image pulls (KEP-2535, GA): kubelet negocia con el registry un token OIDC corto, acotado al ciclo de vida del pod, en lugar de un imagePullSecret de larga vida. Un artefacto zero-trust menos en el Secret store.
• PSI metrics GA: Pressure Stall Information del kernel de Linux llega directamente a las métricas del kubelet. En vez de «memoria al 95 %» (que puede ser file cache) se ve por fin «cuánto tiempo las tasks esperan realmente un recurso». Menos NodeNotReady falsos positivos, ajuste de VPA más fino.
• Node Log Query GA: kubectl get --raw "/api/v1/nodes/<node>/proxy/logs/?query=kubelet" — logs del sistema sin SSH al nodo. Requiere el gate NodeLogQuery y enableSystemLogQuery en la configuración del kubelet.
• Fine-Grained Kubelet Authz GA: en vez del grueso system:kubelet-api-admin hay ahora verbs granulares por subresource (nodes/proxy/logs — get, nodes/proxy/exec — deny). Las cuentas de auditoría obtienen read-only sin heredar el admin completo sobre kubelet.

Qué se rompe en silencio al actualizar

• gitRepo volume queda deshabilitado de forma permanente: los manifiestos con gitRepo: producen pods rotos. El fix es mover el build a la CI y montar el artefacto.
• El modo IPVS de kube-proxy ha sido eliminado (estaba deprecated desde 1.35). Migración: iptables con backend nftables, o Cilium/eBPF.
• 1.36 es el último release con soporte de containerd 1.6. Hay que planificar el salto a containerd 2.x en paralelo con la actualización.
• service.spec.externalIPs ahora emite warnings: la ruta hacia la eliminación. Mudarse a un Ingress controller o a Gateway API.

Triaje para un mes

Adopt early: MutatingAdmissionPolicy GA, User Namespaces GA, Suspended Job mutability, Fine-Grained Kubelet Authz. Adopt selectively: DRA para workloads pesados de GPU, OCI artifact volumes, In-Place VPA (si ya se está sobre VPA). Watch, don't rush: HPA scale-to-zero (sigue en alpha, requiere feature gate), Mixed Version Proxy (beta), Smarter HPA Pod Selection (alpha). Antes de kubeadm upgrade la pareja obligatoria es kubent + Pluto contra manifiestos y Helm charts; los leaks de API deprecada existen en la mayoría de los clústeres y solo afloran durante la propia actualización.