Kubernetes 1.32 introduce el streaming de API para corregir picos de memoria en solicitudes de lista

En una publicación del blog de Kubernetes en diciembre de 2024, ingenieros de Upbound, Google y Red Hat detallaron una mejora crítica en la eficiencia de memoria del servidor de API de Kubernetes. La actualización aborda cómo los clústeres grandes manejan la recuperación masiva de datos, introduciendo un mecanismo de streaming que previene el agotamiento súbito de memoria bajo cargas elevadas.

Qué ocurrió

La gestión de clústeres grandes de Kubernetes suele generar una sobrecarga significativa de memoria cuando los componentes emiten solicitudes list. En la implementación tradicional, kube-apiserver debe ensamblar toda la respuesta en memoria antes de enviar cualquier dato al cliente. Si el cuerpo de la respuesta tiene cientos de megabytes, o si llegan múltiples solicitudes simultáneamente tras una interrupción de red, este proceso puede consumir rápidamente toda la RAM disponible. Aunque los mecanismos existentes de Prioridad y Equidad de API protegen contra la sobrecarga de CPU, ofrecen una protección limitada frente a estos picos de memoria ilimitados.

La investigación reveló que esta asignación de memoria ocurre porque el servidor obtiene datos de la base de datos, los deserializa y luego construye el formato final de la respuesta todo a la vez. Esta secuencia crea una huella temporal masiva de memoria que ni la recolección de basura de Go ni los límites de memoria configurados pueden gestionar eficazmente durante picos súbitos. En entornos de alta disponibilidad, esto puede derivar en un fallo en cascada donde un servidor de API se bloquea debido a una condición de falta de memoria (OOM), trasladando las mismas solicitudes pesadas a otros nodos y provocando su caída también.

Para resolver esto, el equipo de Kubernetes promovió la función watch list a beta en la versión 1.32. Esto permite a los clientes optar por el streaming de listas cambiando de solicitudes list estándar a una forma especializada de solicitudes watch. Al servir estas solicitudes desde la caché de watch, el servidor transmite cada elemento individualmente en lugar de almacenar toda la colección en búfer. Este cambio garantiza que la sobrecarga de memoria permanezca constante, limitada solo por el tamaño máximo de un objeto único más asignaciones menores, mejorando drásticamente la estabilidad de los clústeres con muchos objetos grandes.

Cómo funciona

El mecanismo central se basa en pasar del procesamiento por lotes al streaming. Las solicitudes list tradicionales requieren que el servidor mantenga todo el conjunto de datos en RAM durante la serialización. En contraste, el nuevo enfoque watch list aprovecha la caché de watch existente, que es una caché en memoria diseñada para escalar operaciones de lectura. Cuando un cliente utiliza este método, el servidor de API envía los objetos uno por uno a medida que se recuperan de la caché, evitando la necesidad de asignar memoria para todo el cuerpo de la respuesta a la vez.

Este cambio arquitectónico desacopla el uso de memoria del número total de objetos en una colección. En lugar de que el consumo de memoria crezca linealmente con el tamaño de la lista, permanece plano independientemente de cuántos elementos se devuelvan. Esto hace que el servidor de API sea resiliente incluso al manejar miles de recursos grandes, como Secrets con cargas sustanciales, sin riesgo de terminaciones por OOM.

Detalles clave

• La función watch list alcanzó estado beta en Kubernetes 1.32.
• Los clientes deben habilitar explícitamente la puerta de características WatchListClient en client-go para usar listas de streaming.
• Las pruebas sintéticas mostraron que el uso de memoria se estabilizó en 2 GB con el streaming habilitado, en comparación con 20 GB con él deshabilitado.
• La función requiere versiones de etcd 3.4.31+ o 3.5.13+.
• En Kubernetes 1.33, se introdujeron nuevas puertas de características StreamingCollectionEncodingToJSON y StreamingCollectionEncodingToProtobuf para el streaming del lado del servidor sin cambios en el cliente.
• La puerta de características WatchList está deshabilitada por defecto en Kubernetes 1.33, aunque estaba habilitada por defecto para kube-controller-manager en 1.32.

Por qué importa

Para ingenieros de plataforma y SREs que gestionan clústeres a gran escala, esta actualización aborda un punto frágil en la estabilidad del plano de control. El agotamiento de memoria en el servidor de API es difícil de diagnosticar y recuperar, resultando a menudo en cortes completos del plano de control. Al adoptar listas de streaming, los equipos pueden ejecutar clústeres más grandes con recursos más complejos sin temer que un bucle de reconciliación rutinario o una sincronización post-interrupción colapsen su capa de gestión.

Este cambio también tiene implicaciones en cómo se calculan los costos de API en futuras versiones. Actualmente, Prioridad y Equidad de API asigna un costo bajo a las solicitudes list para mantener el paralelismo en casos de uso típicos. A medida que el ecosistema migra hacia watch lists, el sistema puede aumentar de forma segura la estimación de costos para las solicitudes list tradicionales. Esto proporcionará una mejor protección contra clientes heredados o herramientas mal configuradas que continúan emitiendo solicitudes masivas costosas, asegurando una distribución más justa de los recursos en todo el clúster.

Qué puedes hacer

• Actualiza tu clúster a Kubernetes 1.32 o posterior para acceder a la función beta watch list.
• Verifica que tu versión de etcd sea al menos 3.4.31 o 3.5.13 para asegurar la compatibilidad.
• Actualiza los clientes basados en Golang para habilitar la puerta de características WatchListClient en client-go.
• Monitoriza el uso de memoria en tus servidores de API durante picos de carga para identificar si las solicitudes list grandes siguen causando picos.
• Anima a los controladores y operadores de terceros en tu entorno a adoptar la API de streaming durante la fase beta.
• Planifica futuras actualizaciones a Kubernetes 1.33 para aprovechar las funciones de codificación de streaming del lado del servidor que no requieren cambios en el código del cliente.