El equipo de desarrollo de Kubernetes ha dado a conocer hace poco mediante un anuncio la liberación de la nueva versión “Kubernetes 1.18” en la cual el equipo de desarrollo menciona que es una versión ‘en forma y acabado’.

En esta nueva versión se ha realizado un trabajo significativo para mejorar la funcionalidad beta y estable para garantizar una mejor experiencia del usuario. Se ha hecho un esfuerzo igual para agregar nuevos desarrollos y nuevas características emocionantes que prometen mejorar aún más la experiencia del usuario.

Para quienes desconocen de Kubernetes, deben saber que es un sistema de código abierto para automatizar la implementación, el escalado y la administración de aplicaciones en contenedores.

Fue originalmente diseñado por Google, aunque posteriormente su desarrollo ha sido confiado a la Fundación de Computación en la Nube de Código Abierto (CNCF), que hoy ha permitido que la tecnología de orquestación de contenedores madure rápidamente, gracias a las contribuciones de gigantes de la tecnología.

¿Qué hay de nuevo en Kubernetes 1.18?

Esta nueva versión se destaca por tener la posibilidad de usar tokens de cuenta de servicio como método de autenticación general. Por ejemplo, si desea que un pod administre otros recursos de Kubernetes, como una implementación o un servicio, este puede ser asociado con una cuenta de servicio y crear los roles y enlaces de roles necesarios.

Las cuentas de servicio de Kubernetes (KSA) envían tokens web JSON (JWT) al servidor API para autenticarse. Esto hace que el servidor API sea la única fuente de autenticación para las cuentas de servicio.

Kubernetes 1.18 proporciona una funcionalidad que permite al servidor API proporcionar un documento de descubrimiento de OpenID Connect que contiene las claves públicas del token además de otros metadatos.

Otro de los cambios que se destaca de Kubernetes 1.81 es la capacidad de configurar HPA Velocity para pods específicos. Horizontal Pod Autoscaler (HPA) se utiliza para permitir un clúster Kubernetes responda automáticamente al tráfico alto/ bajo. Con HPA, el usuario puede pedirle al controlador que cree más módulos en respuesta a picos de CPU, otras mediciones o mediciones proporcionadas por la aplicación.

Kubernetes 1.18 cuenta con una descripción general de perfiles para ejecutar múltiples configuraciones de planificador. En general, hay dos tipos de cargas de trabajo en Kubernetes: servicios a largo plazo (por ejemplo, servidores web, API, etc.) y tareas que se ejecutan hasta su finalización (mejor conocido como el nombre de Jobs).

Debido a las diferencias obvias entre los tipos de carga de trabajo, algunos usuarios recurren a la creación de clústeres completos para diferentes necesidades. Por ejemplo, un clúster para administrar la minería de datos y otro para servir las API de la aplicación.

La razón es que necesitan que el proceso de decisión difiera. Por ejemplo, la configuración del planificador predeterminado promueve la alta disponibilidad.

Por otro lado, también podremos encontrar la capacidad de definir una regla de difusión de pod en el nivel de clúster, lo que ha permitido asegurarse de que los pods se programarán en zonas de disponibilidad (siempre que esté utilizando un clúster multizona) para garantizar la máxima disponibilidad y la utilización de recursos.

La funcionalidad permite la especificación topologySpreadConstraints, que identifica áreas buscando nodos con la misma etiqueta topologyKey. Los nodos con la misma etiqueta TopologyKey pertenecen a la misma área. La configuración fue distribuir las vainas de manera uniforme en las diferentes zonas. Sin embargo, la desventaja es que esta configuración debe aplicarse a nivel de pod. Los pods que no tienen la configuración no se distribuirán uniformemente entre los dominios de falla.

Finalmente y no menos importante, también podremos encontrar la capacidad de ignorar el cambio en la propiedad del volumen. De manera predeterminada, cuando un volumen se monta en un contenedor en un clúster de Kubernetes, todos los archivos y directorios dentro de este volumen tienen su propiedad cambiada al valor proporcionado a través del fsGroup.

Todo esto para permitir que fsGroup pueda leer y escribir el volumen. Sin embargo, se ha demostrado que este comportamiento no es deseable en algunos casos.

Esta nueva versión de Kubernetes llega con diversos cambios y solo hemos mencionado algunos de los más importantes. Si quieres conocer la lista completa puedes hacerlo visitando el siguiente enlace.