"Kubernetes v1.34 ha promocionado las métricas de Información de Presión de Parada (PSI) a Beta, ofreciendo una herramienta crítica para monitorear la salud de los nodos en clústeres en crecimiento. PSI, una característica del kernel de Linux, cuantifica la presión de recursos midiendo el tiempo de parada de las tareas debido a la contención, en lugar de solo la utilización. Proporciona métricas para CPU, memoria y E/S, categorizadas como presión "parcial" (al menos una tarea detenida) o presión "total" (todas las tareas que no están inactivas detenidas). Estas métricas están disponibles en ventanas deslizantes de 10 segundos, 1 minuto y 5 minutos. El feature gate KubeletPSI permite que el kubelet recopile y exponga métricas PSI a través de la API de Resumen y el endpoint de Prometheus `/metrics/cadvisor`. Ahora se puede acceder a nuevas métricas de Prometheus como `container_pressure_cpu_stalled_seconds_total`. Estas métricas ayudan a identificar fugas de memoria, optimizar las solicitudes de recursos y activar el autoescalado. Para habilitar PSI, los nodos deben ejecutar el kernel de Linux 4.20+ con cgroup v2, y el feature gate KubeletPSI debe estar habilitado. Las métricas PSI son específicas de Linux y no están disponibles en nodos Windows. Esta característica beta se está desarrollando activamente y se alienta la retroalimentación."

Kubernetes v1.34 promueve la Integración de Tokens de Cuenta de Servicio para Proveedores de Credenciales de Kubelet a beta. Esta mejora permite a los proveedores de credenciales utilizar tokens de cuenta de servicio específicos de la carga de trabajo para credenciales de registro, reemplazando los secretos de extracción de imágenes de larga duración. La versión beta introduce un campo cacheType obligatorio para las configuraciones de proveedores de credenciales. Hay dos estrategias de caché disponibles: Token, para credenciales vinculadas a la vida útil del token, y ServiceAccount, para credenciales válidas para todos los pods que utilizan la misma cuenta de servicio. La versión beta también proporciona una mayor aislamiento de seguridad, asegurando que los pods solo puedan acceder a imágenes extraídas utilizando sus cuentas de servicio autorizadas. Este sistema rastrea la identidad de la Cuenta de Servicio, verificándola cuando un pod utiliza una imagen en caché. Los administradores pueden revocar el acceso a las imágenes eliminando y volviendo a crear las Cuentas de Servicio. La función se basa en la restricción de audiencia de nodos de cuenta de servicio para solicitudes de tokens seguras. Para utilizar la función beta, asegúrese de tener Kubernetes v1.34 o posterior y actualice los proveedores de credenciales. La migración desde alpha requiere agregar el campo cacheType y revisar las estrategias de caché. La comunidad de Kubernetes está buscando comentarios sobre esta función, especialmente de los implementadores de proveedores de credenciales. Se planea un desarrollo y recopilación de comentarios adicionales para versiones futuras.

"Kubernetes v1.34 introduce la función beta `prefer-align-cpus-by-uncorecache` para la política estática del Gestor de CPU. Esta opción optimiza las cargas de trabajo en procesadores con arquitecturas de caché "uncore" dividida. La caché "uncore", también conocida como caché de último nivel (LLC), se comparte entre los núcleos de la CPU. Los procesadores modernos utilizan cachés "uncore" divididas para reducir la latencia al agrupar la caché entre grupos de CPU. Esta función permite a Kubernetes colocar las CPU de los contenedores dentro de la misma caché "uncore", minimizando la latencia y la contención. Esta colocación consciente de la caché mejora el rendimiento de las aplicaciones sensibles. Por defecto, Kubernetes utiliza una metodología de "packed" (empaquetada), que puede generar problemas de vecinos ruidosos (noisy neighbor) y latencia entre cachés. Habilitar esta función aísla los contenedores en cachés individuales, resolviendo la contención. Los casos de uso incluyen aplicaciones de telecomunicaciones como vRAN, pero los beneficios dependen de la carga de trabajo, especialmente para aplicaciones ligadas al ancho de banda de memoria. Para habilitarla, configure la política del Gestor de CPU como estática y active `CPUManagerPolicyBetaOptions`. La configuración implica modificar el archivo de configuración del kubelet para establecer la política y las opciones. La función funciona en procesadores con caché "uncore" monolítica imitando la alineación por socket."

Kubernetes 1.34 trae mejoras significativas a la Asignación Dinámica de Recursos (DRA). La funcionalidad principal de DRA ha alcanzado la Disponibilidad General (GA), lo que la hace estable y lista para su adopción a largo plazo. DRA permite la gestión flexible de hardware especializado como las GPUs, al permitir que las cargas de trabajo especifiquen sus necesidades de dispositivos y que el planificador asigne los dispositivos reales. Con DRA ahora en GA, está habilitado por defecto, junto con características que anteriormente estaban en beta. Varias características han pasado a beta, incluyendo el etiquetado de acceso de administrador para restringir que los usuarios autorizados hagan un mal uso de características de dispositivos específicas. Las listas priorizadas permiten a las cargas de trabajo especificar múltiples alternativas de dispositivos aceptables para una planificación más flexible. La API de kubelet se ha actualizado para informar sobre los recursos de Pod asignados por DRA, mejorando la monitorización de nodos. Las nuevas características alfa ofrecen una visión del futuro de DRA. El mapeo de recursos extendidos admite la publicidad de recursos gestionados por DRA como recursos extendidos, simplificando el consumo para las cargas de trabajo existentes. La capacidad consumible introduce el uso compartido flexible de dispositivos, permitiendo que múltiples pods no relacionados compartan un único dispositivo físico basándose en políticas definidas por el administrador. Las condiciones de enlace mejoran la fiabilidad de la planificación al retrasar la vinculación de Pods hasta que se confirmen que los recursos externos están listos. Finalmente, el estado de salud de los recursos para DRA mejora la observabilidad al exponer el estado del dispositivo a través del Estado del Pod. El equipo planea llevar más características alfa y beta a GA en futuras versiones.

Kubernetes 1.34 introduce una característica alfa llamada Política y Reglas de Reinicio de Contenedores. Esta característica permite el control individual sobre los reinicios de contenedores dentro de un Pod, anulando la política de reinicio global del Pod. También habilita reinicios condicionales para contenedores según sus códigos de salida. Anteriormente, todos los contenedores en un Pod compartían una sola política de reinicio. Esta limitación impidió escenarios como tener un contenedor init que se ejecuta solo una vez mientras el contenedor de la aplicación principal siempre se reinicia. La nueva característica, activada por la puerta de características alfa ContainerRestartRules, aborda esto permitiendo políticas y reglas de reinicio por contenedor. Los casos de uso incluyen reinicios en el lugar para trabajos de entrenamiento con códigos de salida específicos, contenedores init que se intentan una vez y Pods con múltiples contenedores que tienen necesidades de reinicio diferentes. Para utilizar esta característica, la puerta de características ContainerRestartRules debe estar habilitada. Los ejemplos demuestran cómo configurar reinicios según códigos de salida específicos, implementar contenedores init que se intentan una vez y asignar políticas de reinicio diferentes a múltiples contenedores. Esta característica alfa agradece la retroalimentación de la comunidad y es desarrollada por SIG Node. Los planes futuros incluyen el soporte para reiniciar Pods completos.

Las preferencias de usuario de kubectl ahora alcanzan la versión beta en Kubernetes v1.34, ofreciendo opciones de personalización. Esta funcionalidad permite a los usuarios definir configuraciones personalizadas para comandos de kubectl. Un archivo de preferencias de usuario, típicamente llamado kuberc, se encuentra en el directorio de configuración de kube predeterminado, $HOME/.kube. Este archivo utiliza una estructura de apiVersion y kind, similar a los manifiestos de Kubernetes. La sección de valores predeterminados permite establecer valores predeterminados para opciones de comandos de kubectl, como siempre utilizar eliminar interactiva. Estos valores predeterminados pueden ser anulados proporcionando opciones diferentes durante la ejecución del comando. Otra opción predeterminada recomendada es habilitar Server-Side Apply para comandos de kubectl apply. La sección de alias permite a los usuarios crear atajos para comandos frecuentemente utilizados, ahorrando tiempo y esfuerzo. Los alias se pueden definir para asignar a comandos de kubectl específicos con argumentos y opciones predefinidos. El mecanismo admite tanto agregar como anexar argumentos al comando de kubectl subyacente. La información de depuración para esta característica se puede acceder con mayor verbosidad, como utilizando -v=5. Se alienta encarecidamente la retroalimentación del usuario mientras la característica madura, y los usuarios pueden contribuir a través de Slack, problemas de GitHub o reuniones comunitarias.

La versión v1.34 de Kubernetes, con el tema "Del Viento y la Voluntad", introduce 58 mejoras, de las cuales 23 alcanzan la estabilidad. La Asignación Dinámica de Recursos (DRA) para la gestión de dispositivos está ahora disponible de forma general, permitiendo una selección y configuración de dispositivos más flexible. Los tokens de Projected ServiceAccount para los proveedores de credenciales de imágenes de kubelet ofrecen una seguridad mejorada al utilizar tokens de corta duración y específicos para la carga de trabajo. Un nuevo formato de salida, KYAML, se introduce como una característica alfa para kubectl, con el objetivo de obtener YAML más seguro y menos ambiguo para Kubernetes. Los controladores de Job ahora cuentan con la creación de Pods de reemplazo retrasada para evitar la ejecución simultánea y la contención de recursos. La recuperación de fallos en la expansión de volúmenes es estable, lo que permite a los usuarios cancelar e intentar nuevamente las expansiones de volúmenes. VolumeAttributesClass también es estable, proporcionando una API nativa de Kubernetes para modificar parámetros de volúmenes. La configuración estructurada de autenticación es ahora estable, mejorando la manejabilidad y la auditabilidad de la autenticación de clientes del servidor de API. La autorización más granular basada en selectores mejora la seguridad y permite reglas de privilegio mínimo. Las solicitudes anónimas se pueden restringir a puntos finales específicos, mejorando la seguridad sin interrumpir las sondas externas. La cola más eficiente para Pods no programables reduce las reintentos innecesarios y mejora el rendimiento de la programación. La eliminación ordenada de namespaces garantiza la eliminación determinista y segura de recursos, mitigando los riesgos de seguridad. Las respuestas de lista en streaming mejoran la escalabilidad al reducir la presión de memoria del servidor de API. La inicialización resiliente de la caché de watch mejora la robustez del plano de control al hacer que el proceso de inicialización de la caché de watch sea más resistente a los fallos.

La característica NodeSwap de Kubernetes, que pronto será estable, permite a los nodos Linux utilizar espacio de intercambio para memoria virtual adicional. Esto busca mejorar la utilización de recursos y reducir las muertes por falta de memoria (OOM) cuando la RAM física se agota. Sin embargo, su efectividad depende de ajustar parámetros específicos del kernel de Linux como vm.swappiness, vm.min_free_kbytes y vm.watermark_scale_factor. El parámetro vm.swappiness controla la preferencia del kernel entre intercambiar memoria anónima y recuperar memoria respaldada por archivos. vm.min_free_kbytes actúa como un buffer de seguridad, influyendo en cuándo comienza la reclusión de páginas agresiva. vm.watermark_scale_factor ajusta la brecha entre las marcas de agua de memoria libre, afectando la ventana de intercambio. Las pruebas revelaron que los parámetros del kernel predeterminados pueden llevar a muertes por falta de memoria y reinicios de nodos bajo presión de memoria. Aumentar vm.min_free_kbytes y vm.watermark_scale_factor resultó crucial para prevenir la expulsión prematura y las muertes por falta de memoria, proporcionando al kernel más tiempo para intercambiar. Un swappiness más alto puede llevar a una espera de E/S significativa, mientras que un swappiness más bajo prioriza la eliminación de la caché de archivos. Ajustar adecuadamente estos parámetros, junto con los umbrales de expulsión de Kubelet, crea una estrategia equilibrada de gestión de presión de memoria. Los riesgos incluyen la degradación del rendimiento debido al acceso lento al espacio de intercambio y la máscara de fugas de memoria.

El programador de Kubernetes es un componente crucial que determina en qué nodo se ejecutará un Pod, y comprender su comportamiento puede ser desafiante debido a la multitud de factores que considera. El kube-scheduler-simulator es una herramienta que permite a los usuarios examinar de cerca el comportamiento y las decisiones del programador, lo que lo hace útil tanto para usuarios casuales como para expertos que extienden el programador con plugins personalizados. El simulador se desarrolló inicialmente como un proyecto de Google Summer of Code 2021 y desde entonces ha recibido numerosas contribuciones. Permite a los usuarios probar sus restricciones de programación, configuraciones del programador y plugins personalizados mientras verifica cada parte detallada de las decisiones de programación. El simulador también permite a los usuarios crear un entorno de clúster simulado, donde pueden probar su programador con los mismos recursos que su clúster de producción sin afectar las cargas de trabajo reales. La característica principal del simulador es su capacidad para exponer las decisiones internas del programador, y proporciona una interfaz web para visualizar los resultados de la programación. Los usuarios pueden integrar sus plugins personalizados o extendores en el programador depurado y visualizar sus resultados. El simulador también puede ejecutarse de forma independiente, lo que lo hace útil para los desarrolladores de plugins personalizados que desean probar sus plugins o examinar su programador personalizado en un clúster real con una mejor depurabilidad. La función de importación del simulador permite a los usuarios simular la implementación de una nueva versión del programador en un entorno similar a la producción sin afectar sus cargas de trabajo en vivo. El simulador tiene varios casos de uso, incluyendo examinar las restricciones de programación, evaluar los cambios en la configuración del programador y probar plugins o extendores del programador personalizados. Para comenzar a utilizar el simulador, los usuarios solo necesitan tener Docker instalado en su máquina, y pueden acceder a la interfaz web del simulador en http://localhost:3000.

El equipo de Kubernetes SIG Network ha anunciado la disponibilidad general de la versión 1.2.0 de Gateway API, que incluye nuevas características, adiciones experimentales y cambios importantes. La versión introduce soporte para tiempos de espera de HTTPRoute, espejo basado en porcentaje y configuración adicional de TLS para backend. También incluye un nuevo proceso de lanzamiento y actualizaciones al propio proyecto, como el traslado de la herramienta CLI gwctl a su propio repositorio y cambios en los mantenedores.