Kubernetes 1.37 y Cilium 1.20: qué está en beta, qué viene encendido y qué revisar antes de actualizar

0 0 votos

Valora la Publicación

Dos releases que tocan directo al que opera clusters quedaron alineadas esta semana: Kubernetes v1.37 «Garhwal», publicada el 26 de agosto, y Cilium 1.20, cuyo desglose completo salió el 14 de septiembre.

Lo que importa no es la lista de features sino el estado en que llegan. Una cosa es que algo esté en beta, y otra muy distinta es que venga encendido por defecto en tu nodo apenas actualizás el kubelet.

Memory QoS: beta, encendido, y sin efecto hasta que lo configures

Memory QoS (KEP-2570) usa el controlador de memoria de cgroup v2 para darle al kernel mejor información sobre cómo tratar la memoria de cada contenedor, en vez de dejar que el OOM killer decida a ciegas.

En v1.37 el gate MemoryQoS pasó a beta y está activo en todos los kubelets sin que toques nada. Venía en alfa desde v1.22 y solo corre sobre cgroup v2, en Linux.

Que venga encendido no significa que cambie el comportamiento de tus pods, y acá es donde se equivocan casi todos los resúmenes. Con la configuración por defecto el kubelet no escribe ningún valor de memory.high, memory.min ni memory.low en los cgroups.

El motivo es concreto: en alfa memoryThrottlingFactor tenía default 0.9, así que prender el gate implicaba aplicar memory.high. En v1.37 el default pasó a null, para que actualizar no estrangule workloads que hasta ayer corrían sin límite blando.

Antes de actualizar:

Si tu configuración de kubelet ya trae un memoryThrottlingFactor explícito, se preserva y el throttling sigue igual.
Si no lo trae y venías dependiendo del default de 0.9, el kubelet deja de escribir memory.high. Hay que agregarlo a mano.
La reserva por niveles se prende con memoryReservationPolicy: TieredReservation, que por defecto está en None.

La limitación conocida es que esa reserva es a nivel nodo: con TieredReservation todos los pods Guaranteed reciben memory.min y todos los Burstable reciben memory.low, sin forma de excluir a uno.

Pod-Level Resource Managers: beta, pero apagado por defecto

Este es el caso inverso, y por eso conviene no meter las dos en la misma bolsa. Pod-Level Resource Managers (KEP-5526) graduó a beta detrás del gate PodLevelResourceManagers, que sigue deshabilitado por defecto. Entró en alfa recién en v1.36.

Habilita que el Topology Manager, el CPU Manager y el Memory Manager del kubelet lean las declaraciones de recursos a nivel pod (.spec.resources) para decidir dónde ubicar la carga en el hardware.

Antes era todo o nada: para conseguir cores exclusivos alineados a NUMA (CPU y memoria en el mismo zócalo físico) había que ponerle requests enteros a cada contenedor, incluidos los sidecars de logging o telemetría que no necesitan un core dedicado.

Ahora el kubelet reserva lo exclusivo para el contenedor principal y manda los sidecars a un pool compartido aislado del resto del nodo. Los requisitos son específicos:

Hay que prender PodLevelResourceManagers y también PodLevelResources, el gate de recursos a nivel pod que existe desde v1.34.
Solo con la política static del CPU Manager y la política static del Memory Manager, y solo en nodos Linux.
Con el gate apagado los pods con recursos a nivel pod igual se admiten, pero no reciben asignación exclusiva ni alineada a NUMA aunque su QoS sea Guaranteed.

Ojo con los checkpoints de estado que genera la feature: no se pueden bajar de versión a un kubelet que no la soporte.

Lo que v1.37 te empieza a sacar de abajo

Hay una corrección que rompe hoy, no dentro de tres releases: los pods estáticos ya no pueden referenciar Secrets ni ConfigMaps. Era un bug histórico, quedó prohibido, y el gate PreventStaticPodAPIReferences que permitía desactivar la restricción fue eliminado.

Las otras tres son avisos con fecha:

El modo ipvs de kube-proxy queda deprecado y ya loguea un warning al arrancar. Se espera deshabilitado por defecto en v1.40 y removido en v1.43.
cgroup v1 sigue en retirada. Desde v1.35 failCgroupV1 viene en true, así que el kubelet no arranca en un nodo con cgroup v1 salvo override temporal. Sin cgroup v2 tampoco hay Memory QoS.

Cilium 1.20: el Gateway API como capa de tráfico de verdad

Cilium 1.20.0 se etiquetó el 29 de julio con más de 2.660 commits. El salto grande es de Gateway API v1.4 a v1.6.1, y con eso entran cosas que antes obligaban a salirse del modelo:

Filtro ExternalAuth (GEP-1494): el gateway consulta a un servicio de autorización externo antes de reenviar el request. Según lo que responda, reenvía (200), redirige al login (302) o corta ahí mismo (401 o 403), y de paso puede inyectar headers de identidad.
TCPRoute y UDPRoute (GEP-2644 y GEP-2645), ya en el canal Standard de Gateway API v1.6. Exponer una base de datos, un broker o un DNS deja de requerir un Service LoadBalancer o NodePort suelto.

Del lado de red, el IPAM en modo ENI de AWS (el que le da a los pods direcciones reales de la VPC) por fin soporta IPv6, como feature beta. El operador delega un prefijo /80 por ENI de cada nodo y el agente reparte desde ahí, cerrando la última brecha de paridad con IPv4.

Qué revisar antes de tocar Cilium

Las notas de la release avisan que puede hacer falta acción manual si usás Mutual Authentication legacy (que además quedó deprecada, con ztunnel en beta como sucesor), extensiones Go de Envoy, políticas con reconocimiento de Kafka, la API cilium.io/v2alpha1 de CiliumNodeConfig, libnetwork o una configuración de CNI custom.

Y las dos reglas de siempre: el único camino probado es de una minor a la siguiente, y el tráfico que pasa por el proxy en espacio de usuario (política L7, Ingress o Gateway API) se corta durante el upgrade.

Dos betas que no se leen igual

El resumen honesto de la semana es que «beta» no dice nada por sí solo. Memory QoS viaja encendido en cada kubelet v1.37 pero no hace nada hasta que lo configurás, y Pod-Level Resource Managers está en el mismo escalón de madurez y no se prende solo.

¿Ya sabés en qué modo corre tu kube-proxy y si te quedan nodos en cgroup v1? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →