Revisión de las notas de la versión para las versiones de Kubernetes con soporte extendido

El campo .status.kubeProxyVersion para los objetos de nodo ahora está en desuso y el proyecto de Kubernetes propone eliminarlo en una versión futura. El campo obsoleto no es preciso e históricamente ha sido administrado por kubelet, el cual, en realidad, no conoce la versión kube-proxy ni si se ejecuta kube-proxy. Si utilizó este campo en un software cliente, deje de hacerlo; la información no es fiable y el campo está en desuso.

En Kubernetes 1.29, para reducir la posible superficie expuesta a ataques, la característica LegacyServiceAccountTokenCleanUp etiqueta los tokens heredados basados en secretos generados automáticamente como no válidos si no se utilizaron durante mucho tiempo (1 año de forma predeterminada) y los elimina automáticamente si no se intenta usarlos por mucho tiempo después de marcarlos como no válidos (1 año adicional de forma predeterminada). Para identificar estos tokens, puede ejecutar lo siguiente:

kubectl get cm kube-apiserver-legacy-service-account-token-tracking -n kube-system

Kubernetes v1.28 amplió el sesgo admitido entre los componentes del nodo principal y el plano de control en una versión secundaria, de n-2 a n-3, de modo que los componentes del nodo (kubelet y kube-proxy) de la versión secundaria compatible más antigua puedan funcionar con los componentes del plano de control (kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager) para la versión secundaria compatible más reciente.

Las métricas force_delete_pods_total y force_delete_pod_errors_total de Pod GC Controller se han mejorado para que tengan en cuenta todas las eliminaciones forzosas de pods. Se ha agregado un motivo a la métrica para indicar si el pod se ha eliminado forzosamente porque se ha finalizado, ha quedado huérfano, va a finalizar con la taint fuera de servicio, o va a finalizar y quedar sin programar.

El controlador PersistentVolume (PV) se ha modificado para que asigne automáticamente un valor predeterminado de StorageClass a cualquier PersistentVolumeClaim que no tenga definido un valor para storageClassName. Además, el mecanismo de validación de admisión de PersistentVolumeClaim del servidor de API se ha ajustado para que permita cambiar los valores de un estado no establecido a un nombre de StorageClass real.

El kubelet en Kubernetes 1.27 aumentó el valor predeterminado de kubeAPIQPS a 50 y de kubeAPIBurst a 100. Estas mejoras permiten que kubelet gestione un mayor volumen de consultas de API, lo que mejora los tiempos de respuesta y el rendimiento. Cuando las demandas de Pods aumentan, debido a los requisitos de escalamiento, los valores predeterminados revisados garantizan que kubelet pueda administrar de manera eficiente el aumento de la carga de trabajo. Como resultado, los lanzamientos de Pod son más rápidos y las operaciones del clúster son más eficaces.

Puede utilizar una topología de Pod más detallada para difundir políticas como minDomain. Este parámetro le permite especificar el número mínimo de dominios en los que los Pods deben estar repartidos. nodeAffinityPolicy y nodeTaintPolicy permiten un nivel adicional de granularidad en la regulación de la distribución de Pod. Esto se realiza de acuerdo con las afinidades de los nodos, taints y el campo matchLabelKeys en el topologySpreadConstraints de su especificación de Pod’s. Esto permite seleccionar los Pods para la dispersión de los cálculos tras una actualización progresiva.

Kubernetes 1.27 promovió al estado beta un nuevo mecanismo de políticas para StatefulSets que controla la vida útil de sus PersistentVolumeClaims (PVCs). La nueva política de retención de PVC le permite especificar si los PVCs generados a partir de la plantilla de especificaciones de StatefulSet se eliminará o retendrá automáticamente cuando se elimine StatefulSet o si se reducen verticalmente las réplicas que contiene StatefulSet.

La opción goaway-chance del servidor de API de Kubernetes ayuda a evitar que las conexiones de los clientes HTTP/2 se bloqueen en una única instancia del servidor de API, al cerrar una conexión de forma aleatoria. Cuando se cierre la conexión, el cliente intentará volver a conectarse y es probable que aterrice en un servidor de API diferente como resultado del equilibrador de carga. La versión 1.27 de Amazon EKS tiene el indicador goaway-chance activado. Si su carga de trabajo que se ejecuta en el clúster de Amazon EKS utiliza un cliente que no es compatible con HTTP GOAWAY, le recomendamos que actualice su cliente para manejar GOAWAY volviendo a conectarse al finalizar la conexión.