Llegamos a ustedes gracias a:



Noticias

La compatibilidad de Kubernetes con dockershim finalizará el 3 de mayo

[26/04/2022] La próxima versión 1.24 de Kubernetes, que se lanzará con retraso el 3 de mayo, marca un cambio significativo para el popular sistema de orquestación de contenedores de código abierto, ya que se eliminará de una vez por todas el soporte integrado para Docker.

Docker fue el primer tiempo de ejecución de contenedores utilizado por Kubernetes. Pero a medida que el proyecto Kubernetes se orientaba hacia su propia Iniciativa de Contenedores Abiertos (OCI, por sus siglas en inglés), necesitaba un parche para permitir la portabilidad con otros tiempos de ejecución de contenedores. Ese parche fue dockershim.

Esencialmente, dockershim fue pensado originalmente como una solución temporal para permitir que el popular tiempo de ejecución de contenedores Docker Engine convirtiera las llamadas OCI en llamadas Docker dentro de la propia interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes. Con el tiempo, dockershim se afianzó en los despliegues de Kubernetes, pero ralentizó los despliegues y supuso una carga para los mantenedores. Tenía que desaparecer.

Cómo prepararse para la eliminación de dockershim

El lanzamiento de Kubernetes v1.24, que se espera para el 3 de mayo, requerirá que los usuarios que quieran estar en la última versión del software migren de dockershim a otro tiempo de ejecución que sea compatible con el propio de Kubernetes, o utilicen el reemplazo externo de dockershim desarrollado por Mirantis, conocido como cri-dockerd.

Aunque los nodos de Kubernetes ya no utilizarán por defecto el tiempo de ejecución de Docker, muchos desarrolladores y administradores ya habrán cambiado a otros tiempos de ejecución compatibles con CRI, como containerd -que el propio Docker donó al CNCF en 2017- y el CRI-O nativo. Esto normalmente implica asegurarse de que el agente kubelet que se ejecuta en cada nodo de un clúster está configurado para llamar a los sockets containerd o CRI-O.

Varios proveedores de Kubernetes gestionados ya han avanzado, como Red Hat OpenShift, que adoptó CRI-O en el 2019. Elastic Kubernetes Service (EKS) de Amazon, Azure Kubernetes Service (AKS) de Microsoft y Kubernetes Engine (GKE) de Google ya utilizan containerd por defecto. Microsoft también adoptó containerd para los grupos de nodos Linux de Azure Kubernetes creados con la versión 1.19 o posterior de Kubernetes.

Cambie a un tiempo de ejecución compatible con IRC o se arruinará

Los desarrolladores que no sustituyan dockershim por un tiempo de ejecución compatible con IRC se arriesgan a romper sus clústeres y a quedarse atrás en los parches de seguridad, al tiempo que se pierden las nuevas características.

"En este momento, creemos que el valor que usted (y Kubernetes) obtiene de la eliminación de dockershim compensa el esfuerzo de migración que tendrá", escribió el equipo de lanzamiento de Kubernetes en una publicación del blog de enero.

Los desarrolladores pueden seguir utilizando Docker localmente para desarrollar o probar sus contenedores, independientemente del tiempo de ejecución de contenedores que utilicen para los clústeres de Kubernetes. Las imágenes producidas por Docker seguirán funcionando en los clústeres con todos los tiempos de ejecución compatibles con IRC, pero no seguirán recibiendo soporte.