La semana pasada fue anunciado el lanzamiento de la nueva versión de la plataforma de orquestación de contenedores Kubernetes 1.18, versión que incluye 38 cambios y mejoras, de los cuales 15 están en estado estable y 11 están en estado beta, además de que se proponen 12 nuevos cambios en el estado alfa. En la preparación de la nueva versión, los esfuerzos equitativos se dirigieron tanto al refinamiento de varias funciones como a la estabilización de las capacidades experimentales, así como a la incorporación de nuevos desarrollos.

Para quienes desconocen de Kubernetes deben saber que esta es una plataforma de orquestación de contenedores que permite administrar un clúster de contenedores aislados en su conjunto y proporcionar mecanismos para implementar, mantener y escalar aplicaciones que se ejecutan en contenedores.

El proyecto fue creado originalmente por Google, pero luego se transfirió a una plataforma independiente, comisariada por la Fundación Linux. La plataforma se posiciona como una solución universal desarrollada por la comunidad, no vinculada a sistemas individuales y capaz de trabajar con cualquier aplicación en cualquier entorno de nube. El código de Kubernetes está escrito en Go y se distribuye bajo la licencia Apache 2.0.

¿Qué hay de nuevo en Kubernetes 1.18?

Esta nueva versión de Kubernetes llega con diversas mejoras para Kubectl, de las cuales se menciona en el anuncio que se ha agregado una versión alfa del comando “kubectl debug”, que facilita la depuración en pods al ejecutar contenedores con herramientas de depuración.

Mientras que el comando “kubectl diff” se ha declarado estable, lo que permite ver qué cambiará en el clúster si aplica el manifiesto.

También se han eliminado todos los generadores de comandos “kubectl run”, a excepción de la puesta en marcha del generador de un solo pod, además de que el indicador –dry-run fue cambiado, dependiendo de su valor (cliente, servidor y ninguno), la ejecución de prueba del comando se realiza en el lado del cliente o servidor.

El código kubectl se asigna a un repositorio separado. Esto nos permitió separar kubectl de las dependencias internas de kubernetes y facilitó la importación de código en proyectos de terceros.

En cuanto a los cambios en la red, se destaca que el soporte de IPv6 ahora está en beta, se añadió la clonación de PVC, la posibilidad del eso de dispositivos sin formato de bloqueo de red como discos permanentes, soporte para bloquear dispositivos sin formato en CSI, transferencia de información sobre la unidad que solicita conectar un disco al controlador CSI, además de que se ha agregado un nuevo campo “inmutable” a los objetos ConfigMap y Secret.

De los demás cambios que se destacan:

• Finalmente se eliminó la capacidad de usar las aplicaciones/v1beta1 y las extensiones/v1beta1 del grupo API obsoletas.
• ServerSide Apply actualizado al estado beta2. Esta mejora trae la manipulación de objetos de kubectl al servidor API.
• API de CertificateSigningRequest declarada estable.
• Soporte para la plataforma Windows.
• El soporte de nodo de Windows continúa expandiéndose
• Soporte CRI-ContainerD
• Implementación de RuntimeClass
• Proxy CSI
• Soporte transferido ha estado estable
• Cuenta de servicio administrado grupal
• RunAsUserName
• El Administrador de topología ha recibido el estado beta. La función incluye la distribución NUMA, que evita la degradación del rendimiento en sistemas multisocket.
• El estado beta se obtuvo mediante la función PodOverhead, que permite especificar en RuntimeClass la cantidad adicional de recursos necesarios para iniciar el hogar.
• Extended hugepages de apoyo, alfa estado de aislamiento añadido al recipiente y soporte para múltiples niveles hugepages tamaños.
• Se agregó el campo AppProtocol en el que puede especificar qué protocolo usa la aplicación
• Traducido al estado beta y habilitado de forma predeterminada EndpointSlicesAPI, que es un reemplazo más funcional para los Endpoints normales.
• Se ha agregado un objeto IngressClass, que indica el nombre del controlador de ingreso, sus parámetros adicionales y el signo de usarlo de manera predeterminada.
• Se agregó la capacidad de especificar en el manifiesto de HPA el grado de agresividad al cambiar el número de hogares en funcionamiento, es decir, cuando la carga aumenta, comienza inmediatamente N veces más copias.