Kubernetes 1.30 “Uwurnetes” ha sido publicada como la nueva versión estable del conocido orquestador de contenedores, el cual nació en las instalaciones de Google y actualmente está bajo el paraguas de The Linux Foundation. Los responsables han definido este lanzamiento como “el más bonito” en la trayectoria de este software y han dicho que incluye un total de 45 novedades, de las cuales 17 están en fase estable, 18 en beta y 10 en alfa. Sin embargo, aquí solo mencionaremos lo más importante.
La primera novedad que se me menciona de Kubernetes 1.30 es la publicación en fase estable de la reconstrucción de Robust VolumeManager después de reiniciar el kubelet, que consiste en una refactorización del administrador de volúmenes que permite que el kubelet complete la información adicional sobre cómo se montan los volúmenes existentes durante el inicio del kubelet. En términos generales, esto hace que la limpieza del volumen sea más sólida después de reiniciar el kubelet o la máquina.
También ha llegado en fase estable la evitación de la conversión no autorizada del modo de volumen durante la restauración del propio volumen, que consiste en que el plano de control evita cambios no autorizados en los modos de volumen cuando se restaura una instantánea en un volumen persistente (PersistentVolume). Los administradores de clústeres deberán otorgar permisos a los directores de identidades adecuados si necesitan permitir este tipo de cambio en el momento de la restauración.
Otra cosa que ha llegado en fase estable en Kubernetes 1.30 es la preparación de la planificación de los pods, que abre la puerta a que el orquestador evite la planificación de un pod que ha sido definido cuando el clúster todavía no tiene los recursos aprovisionados para permitir vincular dicho pod a un nodo. A esto se suma un control personalizado para que un Pod pueda planificar a la vez que permite al usuario implementar mecanismos de cuotas, controles de seguridad y más.
El poder marcar pods como exentos de planificación, como es de esperar, reduce el trabajo que tiene que realizar el planificador (scheduler), generando así pods que no pueden o no se quiere que planifiquen en los nodos que tiene el clúster. En caso de que el escalado automático del clúster esté activo, el uso de puertas de planificación reduce la carga del planificador, por lo que puede repercutir en un ahorro de dinero. Sin puertas de planificación, el escalador automático podría lanzar un nodo que no necesita iniciarse.
Los dominios mínimos (parámetro minDomains) para las restricciones de PodTopologySpread permiten definir la cantidad mínima de dominios y son otra característica que llega en fase estable con el lanzamiento de Kubernetes 1.30. Está diseñada para ser usada con el escalador automático de clúster (Cluster Autoscaler), que aprovisionaría nodos en nuevos dominios.
Como ultima cosa que ha llegado en fase estable está que el repositorio de Kubernetes usa ahora los espacios de trabajo de Go. Este cambio no debería impactar a los usuarios finales, pero sí a los desarrolladores de proyectos downstream. El cambio a los espacios de trabajo de Go ha provocado algunos cambios importantes en las flags de varias herramientas de k8s.io/code-generator.
En lo que respecta a las características que han entrado en fase beta, lo primero que se menciona es la consulta de registro del nodo (NodeLogQuery), que requiere de estar habilitada para el nodo y que las opciones de configuración del kubelet enableSystemLogHandler y enableSystemLogQuery tengan valor true. Esto en Linux supone que los registros están disponibles en journald, mientras que en Windows se supone que los registros de servicio están disponibles en el proveedor de registros de la aplicación.
Otra característica que llega en fase beta es la puerta de trinquete de validación de CRD (CRDValidationRatcheting), que luego se aplica a todas las definiciones de recursos personalizados (CustomResourceDefinitions) del clúster. Con esto, la API del servidor está dispuesta a aceptar actualizaciones de recursos que no son válidos después de la actualización, bajo la condición de que cada parte del recurso que no ha podido ser validado no haya sido modificada por la operación de actualización.
El registro contextual (Contextual Logging), también en fase beta, permite a los desarrolladores y los operadores inyectar detalles contextuales personalizables y con correlación como nombres de servicios e identificadores (ID) de transacciones en los registros a través WithValues y WithName. Esto simplifica la correlación y el análisis de los datos de registro entre sistemas distribuidos, lo que mejora significativamente la eficiencia de los esfuerzos en la resolución de problemas.
El comportamiento del equilibrador de carga, servido a través de la característica LoadBalancerIPMode, está ahora habilitado por defecto. Permite configurar .status.loadBalancer.ingress.ipMode para un servicio con type establecido en LoadBalancer. .status.loadBalancer.ingress.ipMode especifica cómo se comporta la IP del equilibrador de carga.
La configuración de la autenticación estructurada (Structured Authentication Configuration) es una función que representa el primer paso para corregir ciertas limitaciones presentes en el orquestador de contenedores, como por ejemplo las imposibilidades de usar múltiples autenticadores del mismo tipo y de cambiar la configuración sin tener que reiniciar la API del servidor. Además, proporciona una manera más extensible para configurar la cadena de autenticación en Kubernetes.
Y cerramos las características en fase beta con la configuración de la autorización estructurada (Structured Authorization Configuration), que tiene como propósito proporcionar una configuración de la cadena de autorización más estructurada y versátil.
Para cubrir algunas cosas que están en fase alfa, lo primero que ha sido mencionado por los responsables del software es que la versión 1.27 incluyó una optimización que establece etiquetas de SELinux en el contenido de los volúmenes utilizando solo un tiempo constante, el cual es alcanzado por Kubernetes mediante el uso de una opción de montaje. La novedad que trae la opción de montaje de SELinux en Kubuernetes 1.30 es que el soporte ha sido extendido a todos los volúmenes en fase alfa, mientras que el soporte limitado a los volúmenes de pods de leer y escribir una vez (ReadWriteOncePod) llegó en la versión 1.27 y está en fase beta.
Los montajes de solo lectura recursivos son otra característica que ha llegado en fase alfa y que representa una nueva capa de seguridad para los datos. Permite configurar volúmenes y sus submontajes como de solo lectura, evitando así modificaciones accidentales.
Los trabajos indexados soportan .spec.successPolicy a partir de Kubernetes 1.30 para definir cuándo un trabajo puede ser declarado como exitoso basándose en los pods exitosos. Esta función permite definir dos tipos de criterio: succeededIndexes (índices exitosos), que indica que el trabajo puede ser declarado como exitoso cuando estos índices tuvieron éxito incluso si otros fallaron, y succeededCount (conteo exitoso), que indica que el trabajo puede declararse exitoso cuando el número de índices exitosos alcanza dicho criterio.
El campo spec.trafficDistribution ha sido introducido en el servicio de Kubernetes en fase alfa y permite expresar preferencias sobre cómo se debe enrutar el tráfico a los puntos finales del servicio. Si bien las políticas de tráfico se centran en garantías semánticas estrictas, la distribución del tráfico permite expresar preferencias, lo que puede ayudar a optimizar el rendimiento, el costo o la confiabilidad. Es posible usar el campo mediante la habilitación de la puerta de función ServiceTrafficDistribution para el clúster y todos los nodos.
Continuando con más cosas relacionadas con la distribución del tráfico, PreferClose indica una preferencia por enrutar el tráfico a puntos finales que están topológicamente próximos al cliente. Establecer este valor otorga permiso a las implementaciones para realizar diferentes compensaciones.
Y como última novedad destacada de Kubernetes 1.30, también en fase alfa, es la nueva API para la migración de la versión del almacenamiento (StorageVersionMigration). El orquestador depende de una API de datos que está siendo reescrita de manera activa para soportar algunas actividades de mantenimiento relacionadas con el almacenamiento en reposo.
Y estas son todas las novedades destacadas de Kubernetes 1.30. Todos los detalles están publicados en el anuncio oficial y las notas de lanzamiento, mientras que el código fuente del software puede obtenido a partir de la sección de lanzamientos del repositorio GitHub del proyecto.
