Kubernetes pasa a la versión 1.20, que marca la llegada a la versión beta de Kubectl Debug

El equipo de desarrollo de Kubernetes dio a conocer hace poco la liberación de la nueva versión 1.20, versión que continúa con el trabajo de limpieza que comenzó con la versión 1.19 y presenta más de 40 características nuevas, incluidas 16 funciones mejoradas y 11 que finalmente se clasifican como estables.

El equipo prestó especial atención al desarrollo posterior de funciones importantes como los trabajos cron y el soporte CRI de Kubelet, que han permanecido en la fase alfa durante mucho tiempo. Las funciones que no muestran un progreso continuo hacia la estabilidad se marcarán como obsoletas más rápidamente en el futuro.

Principales novedades de Kubernetes 1.20

Uno de los principales cambios de Kubernetes 1.20 es el desuso de Docker, ya que como se menciona en el registro de cambios, la primera versión beta de 1.20 Kubernetes anunció que la compatibilidad con Docker se aplica en Kubelet en desuso y debería omitirse por completo en una de las próximas versiones.

En opinión del equipo de desarrollo, la integración de Container Runtime Interface (CRI) como interfaz de complemento para Kubelet ahora ha alcanzado el nivel de madurez requerido para poder cambiar a entornos de tiempo de ejecución de contenedores compatibles con CRI que se pueden usar sin volver a compilar.

Con ello Kubectl Debug pasa a beta, con él, los usuarios pueden inspeccionar un Pod en ejecución sin tener que reiniciarlo. Además, los usuarios ya no tienen que ingresar al contenedor para verificar los sistemas o iniciar operaciones como depurar utilidades o solicitudes de red iniciales desde el espacio de nombres de red del pod. Esta mejora elimina la dependencia de SSH para mantener y depurar nodos.

Esta función admite flujos de trabajo de depuración comunes directamente desde kubectl. Los escenarios de resolución de problemas admitidos en esta versión de kubectl:

• Resolver problemas con cargas de trabajo que se cuelgan al inicio mediante la creación de una copia del pod que usa una imagen o comando de contenedor diferente.
• Resolver problemas de contenedores sin distracciones agregando un nuevo contenedor con herramientas de depuración, ya sea en una nueva copia de pod o usando un contenedor efímero.
• Resuelver problemas en un nodo creando un contenedor que se ejecute en los espacios de nombres del host y con acceso al sistema de archivos del host.

Otro cambio importante de esta nueva versión, son las operaciones de instantáneas de volumen estable. Esta función proporciona una forma estándar de activar operaciones de instantáneas de volumen y permite a los usuarios incorporar operaciones de instantáneas de forma portátil en cualquier entorno de Kubernetes y proveedores de almacenamiento soportado.

Además, estas primitivas de instantánea de Kubernetes actúan como bloques de construcción básicos para desarrollar una funcionalidad avanzada de administración de almacenamiento a nivel empresarial para Kubernetes, incluidas las soluciones de respaldo a nivel de aplicaciones o de clúster.

Por otra parte, se destaca la limitación de PID de proceso para la estabilidad, ya que las ID de proceso son un recurso fundamental en los hosts de Linux. Es trivial alcanzar el límite de tareas sin alcanzar ningún otro límite de recursos y causar inestabilidad en una máquina host.

Los administradores necesitan mecanismos para garantizar que los pods de usuario no puedan inducir el agotamiento del pid que evite que los demonios del host se ejecuten.

Además, es importante asegurarse de que los pids estén limitados entre los pods para garantizar que tengan un impacto limitado en otras cargas de trabajo en el nodo. Después de estar habilitado de forma predeterminada durante un año, el nodo SIG cambia los límites de PID a GA enSupportNodePidsLimit  y SupportPodPidsLimit.

Además en Kubernetes 1.20 la pila dual IPv4/IPv6 se ha vuelto a implementar para admitir servicios de pila dual basados ​​en los comentarios de los usuarios y la comunidad. Esto permite que las direcciones IP del clúster de servicios IPv4 e IPv6 se asignen a un solo servicio, y también permite que un servicio pase de una pila de IP única a una pila de IP doble y viceversa.

Finalmente, si quieres conocer más al respecto sobre esta nueva versión, puedes consultar los detalles en el siguiente enlace.