Por Canuto  

Kubernetes 1.37 llega con 67 mejoras y una señal clara para los operadores: la plataforma prioriza estabilidad y producción al retirar componentes heredados, mientras convierte Metrics API en una función estable después de nueve años en beta.
***

  • Kubernetes 1.37 retira kube-dns y prepara el abandono de IPVS y cgroup v1.
  • Metrics API alcanza disponibilidad general tras permanecer nueve años en estado beta.
  • La versión incorpora escalamiento hasta cero, checkpoint de pods, una caché de watch más resiliente y KYAML.

Kubernetes 1.37 llega con una operación de limpieza que revela la madurez alcanzada por el orquestador de contenedores. La versión, apodada Garhwal por una región del Himalaya de Uttarakhand, India, reúne 67 mejoras: 16 alcanzan estabilidad, 23 pasan a beta y 27 entran en alfa, además de una descontinuación.

El movimiento ocurre mientras Kubernetes deja de ser una herramienta reservada para laboratorios y proyectos experimentales. Según una encuesta de la Cloud Native Computing Foundation (CNCF) publicada en enero, aproximadamente el 82% de los usuarios de contenedores ejecuta Kubernetes en producción, frente al 66% registrado en 2023, una evolución que eleva el costo operativo de mantener funciones antiguas.

La plataforma también ocupa un lugar importante en la infraestructura de inteligencia artificial. La CNCF informó que el 66% de las organizaciones que alojan modelos de IA generativa utiliza Kubernetes para administrar toda o parte de sus cargas de inferencia, por lo que los cambios de compatibilidad pueden afectar tanto a equipos de software tradicional como a operadores de sistemas de IA.

Metrics API sale de la beta

La novedad más simbólica es la promoción de Metrics API a disponibilidad general, después de nueve años en estado beta durante los 12 años de existencia pública de Kubernetes. La interfaz proporciona datos de uso de CPU y memoria para pods y nodos, métricas que sirven para informes y también alimentan funciones como el escalamiento automático de cargas.

El paso a una versión estable no implica cambios funcionales esperados, según las notas del lanzamiento. Dipesh Rawat, responsable del lanzamiento de Kubernetes 1.37, explicó a The Register que metrics.k8s.io, pese a la etiqueta beta, ha tenido un uso amplio en producción durante años y que la promoción reconoce formalmente una madurez ya demostrada.

El prolongado estado beta contrasta con una regla adoptada por los mantenedores en 2020. Esa política establece que ninguna función nueva basada en una API debe permanecer en beta durante más de tres versiones menores, aproximadamente 12 meses al ritmo actual, antes de pasar a disponibilidad general o ser reemplazada por otra alternativa.

La regla busca evitar que identificadores temporales como v1beta1 queden incrustados en sistemas automatizados y obliguen a realizar cambios costosos más adelante. También pretende reducir la confusión en herramientas de seguridad, que suelen considerar inapropiado el uso productivo de componentes marcados como software de preproducción.

El caso puede relacionarse con la arquitectura de Metrics API: no la gestiona directamente el servidor API de Kubernetes, sino un servidor separado mediante el mecanismo de API agregada.

El retiro de componentes heredados

Kubernetes 1.37 también inicia el retiro del servidor DNS incorporado originalmente, kube-dns, en favor de CoreDNS. CoreDNS es el complemento DNS predeterminado del clúster desde Kubernetes 1.13, y quienes todavía ejecuten kube-dns deberán actualizar sus clústeres antes de Kubernetes 1.40 para evitar que dejen de funcionar.

El calendario de cambios no termina allí. kube-proxy, el componente que administra el enrutamiento entre pods, dejará de admitir Linux IPVS, o IP Virtual Servers, a partir de Kubernetes 1.43, después de que esa tecnología no cumpliera las expectativas como alternativa para aliviar los cuellos de botella del enrutamiento basado en iptables.

IPVS fue incorporado para resolver problemas de rendimiento asociados con iptables y su modelo de enrutamiento. Sin embargo, los mantenedores orientan ahora el desarrollo hacia nftables, una alternativa que el proyecto considera el camino a seguir para esa parte de la red, lo que obliga a los administradores a revisar configuraciones antes de que llegue la fecha de retiro.

Otro cambio afecta a cgroup v1, la primera versión de los grupos de control de Linux que Kubernetes utiliza para organizar procesos en jerarquías administrables. cgroup v2 ofrece una supervisión más granular de los recursos asignados a los contenedores, y desde Kubernetes 1.35 el proyecto no inicializa nodos que todavía dependan de cgroup v1, aunque existe una solución temporal con vigencia limitada.

Para los operadores, estas decisiones no representan únicamente una actualización de nomenclatura. Un clúster puede seguir funcionando durante años con componentes heredados, pero el vencimiento de soporte convierte esa comodidad en una exposición operacional, especialmente cuando los equipos deben coordinar cambios de red, DNS y administración de recursos en múltiples entornos.

Causas de movimientos recientes

El lanzamiento de Kubernetes 1.37 y sus cambios de componentes heredados constituyen el catalizador confirmado de esta actualización de la plataforma. No obstante, la evidencia disponible no permite atribuirle por sí sola un efecto concreto sobre el comportamiento de operadores o mercados; cualquier impacto adicional sería, por ahora, una explicación plausible y no una causalidad demostrada.

Nuevas herramientas para operar a escala

El ciclo de desarrollo de Kubernetes 1.37 duró 15 semanas. Varias de las funciones nuevas están orientadas a simplificar despliegues y mejorar la operación diaria, una prioridad coherente con el aumento del uso de la plataforma en sistemas productivos.

Entre las incorporaciones alfa aparece el checkpoint y restore de pods, definido en la propuesta de mejora KEP 5823. La función permite capturar el estado de ejecución de los contenedores que componen un pod y restaurarlo posteriormente desde ese punto, aunque los runtimes de contenedores deben encargarse de gestionar la operación.

El autoscaling también recibe una actualización relevante con HPAScaleToZero, identificada como KEP 2021. La característica, ahora beta y habilitada por defecto, permite que Horizontal Pod Autoscaler reduzca una carga de trabajo hasta cero pods cuando permanece inactiva, utilizando métricas de objetos o externas para determinar cuándo puede reactivarse bajo demanda.

Escalar hasta cero puede reducir recursos consumidos por servicios que no necesitan permanecer activos de forma continua. En la práctica, la función vincula el ahorro de capacidad con la capacidad de respuesta de las métricas, de modo que los operadores deberán evaluar qué señales externas o de objetos reflejan mejor la necesidad de recuperar una carga.

Otra mejora aborda el arranque y la recuperación del servidor API mediante la inicialización resiliente de la caché de watch, descrita en KEP 4568. Antes de este cambio, una watchcache sin inicializar podía hacer que kube-apiserver se bloqueara ante solicitudes watch de larga duración o enviara consultas LIST pesadas directamente a etcd, con el riesgo de saturar la base de datos de respaldo.

La corrección funciona como un filtro temporal para ese periodo vulnerable. El servidor rechaza con errores reintentables las solicitudes de lectura que dependen de watchcache hasta que la caché termina de inicializarse, evitando que una oleada de solicitudes de clientes convierta la recuperación del API server en un problema adicional para etcd.

KYAML busca más consistencia

Kubernetes 1.37 incorpora además KYAML, un subconjunto de YAML diseñado para ajustarse a las convenciones específicas de la plataforma. La propuesta KEP 5295 restringe el formato para que los manifiestos puedan analizarse con mayor previsibilidad mediante otras herramientas, con reglas más estrictas para las cadenas entrecomilladas y una menor sensibilidad a los espacios en blanco.

KYAML alcanza estabilidad sin exigir la modificación de los manifiestos existentes. No reemplaza YAML y ya es reconocido por la herramienta de línea de comandos kubectl, por lo que el proyecto lo presenta como una opción de consistencia para repositorios grandes y equipos que comparten configuraciones.

La ventaja está menos en cambiar el lenguaje que en reducir ambigüedades durante la revisión y el procesamiento automatizado. Cuando varios equipos mantienen archivos de infraestructura, pequeñas diferencias de formato pueden dificultar el análisis, las validaciones y la integración con herramientas que necesitan interpretar los manifiestos de manera uniforme.

Kashish Verma, estudiante de informática, resumió el enfoque en un artículo del blog de Kubernetes al describir KYAML como menos una migración y más un mejor hábito. La idea encaja con el resto de la versión: preservar lo que ya funciona, pero cerrar gradualmente las rutas que acumularon deuda técnica y establecer prácticas más confiables para una plataforma cada vez más crítica.

El lanzamiento deja a los administradores una agenda concreta: migrar desde kube-dns antes de Kubernetes 1.40, preparar la salida de IPVS en Kubernetes 1.43 y abandonar cgroup v1 en favor de cgroup v2. Al mismo tiempo, Metrics API, HPAScaleToZero y KYAML muestran que la estabilidad no significa detener la evolución, sino convertir en infraestructura formal las capacidades que ya demostraron utilidad.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados