Kubernetes hace una gran limpieza: kube-dns, IPVS y cgroup v1 pasan a la historia

Los grandes clústeres de Kubernetes han ganado una resistencia notable frente a fallos y cargas pico. El equipo del proyecto publicó Kubernetes 1.37 con el nombre en clave Garhwal, añadiendo 67 mejoras. De ellas, 16 funciones pasaron a estado estable, 23 llegaron a la versión beta y otras 27 aparecieron en modo experimental.

Uno de los principales cambios fue una inicialización más robusta del watch cache, que el servidor API utiliza para atender rápidamente las solicitudes sobre el estado del clúster. Antes, iniciar o reinicializar la caché podía aumentar de forma brusca el flujo de solicitudes al almacenamiento distribuido etcd. En Kubernetes 1.37, el mecanismo limita la carga y rechaza las solicitudes sobrantes con el código HTTP 429 en lugar de acumular la cola. Los desarrolladores esperan que este enfoque reduzca el riesgo de fallo del plano de control en clústeres grandes.

Se introdujeron cambios importantes en la forma en que el sistema gestiona las credenciales digitales de las cargas de trabajo. Los mecanismos Pod Certificates y ClusterTrustBundles alcanzaron el estado estable. Kubernetes ahora ofrece un método integrado para entregar a los pods claves privadas, certificados X.509 y conjuntos de certificados de confianza. Un controlador puede emitir y renovar certificados automáticamente, y la aplicación los recibe a través de un volumen montado, sin necesidad de almacenar credenciales de larga duración de forma manual.

También pasó a la rama estable la API StorageVersionMigration. El mecanismo ayuda a reescribir automáticamente los objetos almacenados después de que una API pase a una nueva versión y puede ser útil tras cambiar la configuración de cifrado de datos. Antes, los administradores tenían que ejecutar sus propios scripts con kubectl o instalar un componente separado. Ahora la migración la gestiona un controlador integrado de Kubernetes.

Kubernetes 1.37 continuó desarrollando herramientas para tareas que consumen muchos recursos, incluido el aprendizaje automático y la computación de alto rendimiento. El gang scheduling pasó a estado beta y permite al planificador considerar un grupo relacionado de pods como un todo. En lugar de ejecutar una tarea parcialmente, Kubernetes puede esperar hasta que haya suficientes recursos para todo el grupo. Este enfoque ayuda a evitar situaciones en las que parte de los pods ya haya ocupado procesadores o aceleradores, mientras que los demás esperan indefinidamente recursos libres.

El escalador horizontal HorizontalPodAutoscaler ahora puede, por defecto, reducir el número de réplicas a cero cuando opera con métricas externas o de objetos. Cuando la carga vuelve, Kubernetes vuelve a iniciar los pods necesarios. Esta posibilidad es especialmente útil para trabajos por lotes, procesadores de colas y tareas con aceleradores gráficos, donde los recursos inactivos aumentan directamente los costes. Escalar a cero en función de la carga de CPU o memoria aún no es posible, ya que para obtener esas métricas se necesitan pods en ejecución.

Los desarrolladores también pasaron a estado beta la compatibilidad con Quality of Service de memoria (Memory QoS) basada en cgroups v2. Kubernetes puede proteger la memoria reservada frente a ser desalojada y limitar las aplicaciones hasta alcanzar un límite estricto. La función está habilitada por defecto, pero la configuración estándar se ha elegido para que la actualización de clústeres existentes no provoque restricciones inesperadas en las cargas de trabajo.

Otra modificación reduce gradualmente la dependencia de kubelet respecto a cAdvisor para la recopilación de estadísticas de contenedores y pods. Kubernetes amplió la Container Runtime Interface (CRI), es decir, la interfaz de interacción con el entorno de contenedores, para que kubelet pueda obtener las métricas necesarias directamente del tiempo de ejecución. De momento la función está en estado beta y desactivada por defecto.

También alcanzó el estado estable KYAML, una variante de YAML más estricta y unívoca para Kubernetes. El formato sigue siendo compatible con YAML, por lo que no es necesario cambiar manifiestos, herramientas o canalizaciones existentes. Al mismo tiempo, tras casi nueve años en beta, la API metrics.k8s.io se volvió estable, a través de la cual Kubernetes obtiene las métricas de CPU y memoria de pods y nodos.

El ciclo de desarrollo de Kubernetes 1.37 comenzó el 18 de mayo y finalizó el 26 de agosto. El nombre Garhwal lo eligieron en honor a la región montañosa Garhwal en el estado indio de Uttarakhand. La nueva versión ya está disponible para descarga, y la publicación de materiales detallados sobre las funciones incluidas en el lanzamiento comenzó el 27 de agosto.