Kubernetes 1.35: cgroup v1, ipvs y containerd

La release 1.35 de Kubernetes no trae solo features nuevas: trae tres cortes a nivel de nodo que pueden dejar un clúster sin arrancar si actualizás a ciegas. El kubelet ahora se niega a levantar sobre cgroup v1, el modo ipvs de kube-proxy pasa a estar deprecado y containerd 1.x recibe su último release con soporte. Ninguno es un ajuste cosmético: los tres tocan la base sobre la que corren tus pods, y dos de ellos definen si vas a poder pasar a la 1.36 sin frenar producción.

Kubernetes 1.35 es la versión del orquestador de contenedores donde tres dependencias del plano de nodos dejan de estar garantizadas: cgroup v1 (el mecanismo del kernel Linux que limita CPU y memoria), el modo ipvs de kube-proxy (el balanceo de tráfico de Services) y containerd 1.x (el runtime de contenedores). El kubelet bloquea cgroup v1, ipvs queda deprecado y containerd 1.x llega a su último release soportado antes de la 1.36.

¿Qué tres cosas dejan de estar garantizadas en Kubernetes 1.35?

Kubernetes 1.35 deja afuera cgroup v1, ipvs y containerd 1.x

Son tres cambios de infraestructura que conviven en la misma release, cada uno con su propio KEP y su propio plazo. El siguiente cuadro resume qué pasa con cada uno y desde cuándo tenés que preocuparte:

Componente	Estado en 1.35	KEP	Qué hacer
cgroup v1	El kubelet no arranca (enforcement duro)	KEP-5573	Migrar los nodos a cgroup v2
kube-proxy ipvs	Deprecado (sigue funcionando)	KEP-5495	Migrar a `nftables`
containerd 1.x	Último release con soporte	KEP-4033	Pasar a containerd 2.0+ antes de la 1.36

La diferencia clave entre los tres: cgroup v1 te frena ya (en la propia 1.35), containerd te frena después (recién en la 1.36) e ipvs todavía te da margen, pero con fecha de vencimiento anunciada. Vamos uno por uno.

¿Por qué el kubelet se niega a arrancar en cgroup v1?

Porque en 1.35 el chequeo dejó de ser una advertencia y pasó a ser un bloqueo: si el kubelet detecta cgroup v1 al iniciar, falla. El campo failCgroupV1 de la KubeletConfiguration ahora vale true por defecto, así que un nodo con la jerarquía vieja del kernel directamente no se une al clúster hasta que lo migres.

Esto no salió de la nada. cgroup v2 es stable desde Kubernetes 1.25, según la documentación del proyecto, es decir que hubo diez releases de aviso previo. cgroup v2 unifica la jerarquía de control del kernel (una sola en lugar de una por recurso) y es lo que habilita features modernas como el in-place pod resize; mantener v1 vivo bloqueaba ese roadmap. El cambio está formalizado en KEP-5573 (Cgroup v1 Removal).

Existe una salida de emergencia, pero es una trampa a futuro:

Podés forzar el arranque con failCgroupV1: false. Se agrega al ConfigMap kube-system/kubelet-config (y hay que ignorar el preflight SystemVerification de kubeadm). El análisis de ScaleOps sobre la 1.35 lo describe como "operacionalmente peligroso": solo pospone lo inevitable y te deja afuera de las features que exigen v2.
Casi todas las distros actuales ya vienen en cgroup v2. Ubuntu 22.04+, Debian 11+ y las familias RHEL 9+ arrancan en modo unificado por defecto. El problema real son nodos viejos que nunca se reinstalaron.

# Verificá en qué modo está un nodo:
stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2 (OK para 1.35)
# tmpfs      -> cgroup v1 (el kubelet no va a arrancar)

¿Qué significa que el modo ipvs de kube-proxy quede deprecado?

Significa que ipvs sigue funcionando en 1.35, pero el proyecto anunció que lo va a sacar y ya no le pone trabajo nuevo. La deprecación está en KEP-5495, y según el resumen de ScaleOps la remoción está apuntada a la 1.38. No es un corte inmediato, pero es una cuenta regresiva formal para quien balancea el tráfico de sus Services con ipvs.

El motivo que da el propio blog oficial es de mantenimiento: "mantener la paridad de features entre ipvs y los otros modos de kube-proxy se volvió difícil, por la complejidad técnica y los requisitos divergentes". La respuesta del proyecto es empujar todo hacia un solo backend moderno.

El reemplazo recomendado es nftables. El modo nftables de kube-proxy es stable desde la 1.33 y está pensado para reemplazar tanto a iptables como a ipvs como backend principal en Linux, con mejor escalado en clústeres grandes.
La migración es un cambio de configuración, no de arquitectura. Se ajusta el campo mode del ConfigMap de kube-proxy y se reinician los pods del DaemonSet. Conviene hacerlo en staging y mirar reglas y latencia de Services antes de tocar producción.
Si usás un CNI que no depende de kube-proxy (por ejemplo con eBPF), el punto te afecta menos: ese datapath no pasa por ipvs.

¿Por qué containerd 1.x es el que te obliga a moverte antes de la 1.36?

Porque, a diferencia de cgroup, containerd no te frena en la 1.35 sino en la siguiente: el blog oficial confirma que 1.35 es el último release que ofrece soporte para containerd 1.x y que hay que "pasar a 2.0 o posterior antes de actualizar Kubernetes a la próxima versión". Traducido: si estás en containerd 1.x, la 1.35 es tu ventana para migrar el runtime.

La decisión, formalizada en KEP-4033, se alinea con el fin de vida de la línea containerd 1.7. containerd es el runtime de contenedores que el kubelet invoca vía CRI para crear y correr los pods, así que un salto de versión mayor (1.x → 2.x) merece pruebas: cambian defaults de configuración y el formato del config.toml evolucionó a la versión 3.

El orden recomendado para no romper nada es hacerlo en dos etapas separadas:

Primero actualizá containerd a 2.x mientras seguís en Kubernetes 1.35 (que soporta ambos). Así aislás cualquier problema del runtime del salto de versión del orquestador.
Recién después subí a la 1.36. Para entonces todos tus nodos ya corren un runtime soportado y el upgrade del control plane no arrastra sorpresas.

# Chequeá la versión del runtime en cada nodo:
containerd --version
# Si empieza con 1.x, migralo a 2.x antes de la 1.36.

Si preparás nodos Ubuntu con containerd y kubeadm, este es el momento de revisar esa base: en el blog ya cubrimos ese armado paso a paso y la nota de Kubernetes 1.34 (tracing en el kubelet y VolumeAttributesClass GA) como lectura complementaria del ciclo de releases.

¿Qué conviene chequear hoy en tus nodos antes de actualizar?

Antes de tocar la versión del clúster, hacé un inventario de estos cuatro puntos en cada nodo; los tres primeros son justamente los que la 1.35 puso bajo la lupa:

Modo de cgroup: corré stat -fc %T /sys/fs/cgroup/. Cualquier nodo que devuelva tmpfs hay que migrarlo a cgroup v2 antes de la 1.35, o no va a arrancar.
Versión de containerd: containerd --version. Todo lo que arranque con 1. tiene que pasar a 2.x antes de la 1.36.
Modo de kube-proxy: revisá el campo mode del ConfigMap kube-system/kube-proxy. Si dice ipvs, planificá la migración a nftables aunque todavía funcione.
Distro y kernel de los nodos: los nodos más viejos son los que suelen fallar los tres chequeos a la vez. A veces reinstalar la imagen base resuelve cgroup y runtime de una.

Preguntas frecuentes

¿Kubernetes 1.35 elimina cgroup v1 o solo lo depreca?

Lo bloquea: en 1.35 el kubelet no arranca en un nodo con cgroup v1, porque failCgroupV1 pasa a valer true por defecto (KEP-5573). Ya no es una advertencia como en versiones previas, sino un enforcement duro a nivel de nodo.

¿El modo ipvs de kube-proxy deja de funcionar en 1.35?

No, en 1.35 ipvs sigue funcionando; solo queda deprecado (KEP-5495). La remoción está apuntada más adelante —según ScaleOps, a la 1.38—, así que tenés margen para migrar a nftables de forma planificada.

¿Puedo seguir usando containerd 1.x en Kubernetes 1.35?

Sí, 1.35 es la última versión que soporta containerd 1.x. El corte llega en la 1.36, donde tenés que estar en containerd 2.0 o superior. Por eso conviene migrar el runtime mientras seguís en 1.35.

¿Cómo sé si un nodo usa cgroup v1 o v2?

Corré stat -fc %T /sys/fs/cgroup/ en el nodo. Si devuelve cgroup2fs estás en v2 (compatible con 1.35); si devuelve tmpfs, el nodo está en cgroup v1 y hay que migrarlo antes de actualizar.

¿Qué reemplaza al modo ipvs de kube-proxy?

El modo nftables, stable desde Kubernetes 1.33. Está diseñado para reemplazar tanto a iptables como a ipvs como backend principal en Linux y escala mejor en clústeres con muchos Services.

En resumen

Kubernetes 1.35 empuja tres dependencias de nodo hacia su versión moderna al mismo tiempo. El único que te frena en la propia 1.35 es cgroup v1 (kubelet que no arranca); containerd 1.x te frena en la 1.36 y el modo ipvs de kube-proxy más adelante todavía. La buena noticia es que los tres se chequean con comandos simples y se resuelven antes de tocar la versión del clúster. Migrá primero el nodo (cgroup y runtime), después el plano de control, y probá cada paso en staging antes de producción.

Fuentes: Kubernetes v1.35 Sneak Peek (blog oficial), ScaleOps — Kubernetes 1.35 Upgrade Guide y el CHANGELOG oficial de Kubernetes 1.35.