Kubernetes v1.24 y luego lanza el barco sin Dockershim después su desaprobación en la versión v1.20 de diciembre de 2020. Dockershim ya no está disponible como tiempo de ejecución de contenedor integrado. Tienes que usar otro tiempo de ejecución compatible en su lugar, como containerd, CRI-O o Motor acoplable con el cri-dockerd adaptador.
En este artículo, le mostraremos cómo verificar si está afectado y luego le explicaremos cómo puede migrar a un tiempo de ejecución diferente. Debes seguir estos pasos antes de actualiza a Kubernetes v1.24 o una versión posterior para que las cargas de trabajo de su clúster no se vean afectadas.
¿Qué fue Dockershim?
Dockershim se desarrolló como un componente necesario para que Kubernetes pudiera admitir más tiempos de ejecución de contenedores. Al comienzo del proyecto, Kubernetes solo funcionaba con Docker Engine. Esta restricción fue eliminada por la introducción de la estándar IRC. Cualquier tiempo de ejecución compatible con CRI ahora se puede usar con Kubernetes, incluido containerd y CRI-Oun OCI implementación de la norma.
Si bien CRI aportó nueva flexibilidad a Kubernetes, presentó un problema para los clústeres existentes. Docker carecía de soporte para el estándar CRI, por lo que Dockershim se creó para permitir que el equipo de Kubernetes supere la compatibilidad. Dockershim fue una integración directa con Docker Engine que siempre tuvo la intención de ser una medida temporal.
El movimiento de contenedores ahora es mucho más que Docker, como demuestra el impulso original de Kubernetes a CRI. Docker se ha dividido en componentes individuales con su tiempo de ejecución extraído como containerd, un graduado de Cloud Native Computing Foundation (CNCF).
containerd es totalmente compatible con Kubernetes y es más adecuado para el uso independiente en entornos de nube. Kubernetes no requiere la CLI de Docker y su conjunto de características para ejecutar sus Pods; todo lo que necesita es la capacidad de iniciar y ejecutar contenedores a un nivel relativamente bajo. Dockershim se eliminó porque era difícil de mantener. Su uso creó código frágil que estaba estrechamente relacionado con la implementación de Docker Engine.
Comprobar si está utilizando Dockershim
Es muy poco probable que los clústeres creados recientemente en plataformas modernas utilicen Dockershim. Esto incluye clústeres administrados por proveedores de nube populares como Amazon EKS, Azure AKS, Google GKE y DigitalOcean DOKS.
Es muy probable que deba tomar medidas si mantiene su propio clúster y lo configuró por primera vez hace varios años. Puede verificar si está utilizando Dockershim como tiempo de ejecución para cualquiera de sus nodos ejecutando este comando de Kubectl:
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 docker://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
En este ejemplo, uno de los nodos usa containerd y se puede dejar como está. El otro nodo está configurado mediante Docker y podría verse afectado por la eliminación de Dockershim. Puede verificar ejecutando este comando en el nodo:
$ tr \0 ' ' < /proc/"$(pgrep kubelet)"/cmdline | grep "--container-runtime"
Su nodo está utilizando Dockershim para ejecutar contenedores si no se muestra ningún resultado. Si obtiene algún resultado, inspeccione el que se muestra --container-runtime-endpoint valor de la bandera para determinar si Dockershim está activo. Un punto final de tiempo de ejecución de unix:///run/containerd/containerd.sock Se utiliza el contenedor de señales, por lo que no es necesaria la migración.
Cambiar el tiempo de ejecución de un nodo
Los nodos que utilizan Dockershim deben actualizarse para usar un tiempo de ejecución diferente. Primero, drene las cargas de trabajo del nodo con Kubectl, de modo que sus pods se reprogramen para otros nodos en su clúster. También debe acordonar el nodo para evitar que se programen nuevos pods.
$ kubectl cordon node-1 $ kubectl drain node-1 --ignore-daemonsets
A continuación, ejecute los siguientes comandos en el propio Nodo. Comience deteniendo el demonio de Docker y el proceso de trabajo de Kubelet del nodo:
$ systemctl stop kubelet $ systemctl disable docker.service --now
Ahora puede instalar su nuevo tiempo de ejecución.
Usando contenedores
containerd es generalmente la solución preferida para los clústeres actuales. Debería poder migrar a containerd si no confía en características específicas de Docker Engine. Si es así, diríjase a la siguiente sección e instale cri-dockerd en cambio.
Agregue el repositorio de Docker a su sistema si sus listas de paquetes aún no lo incluyen. containerd se distribuye en el repositorio de Docker.
$ sudo apt-get update $ sudo apt-get install ca-certificates curl gnupg lsb-release $ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Instalar contenedor:
$ sudo apt update $ sudo apt install containerd
Ahora actualice el archivo de configuración de Kubelet del nodo para usar el nuevo tiempo de ejecución. Abierto /var/lib/kubelet/kubeadm-flags.env. Busque o añada el --container-runtime y --container-runtime-endpoint banderas con los siguientes valores:
--container-runtime=remote--container-runtime-endpoint=unix:///run/containerd/containerd.sock
A continuación, cambie la anotación de socket guardada en el objeto Nodo en el plano de control de Kubernetes:
$ kubectl edit node node-1
En el archivo que se abre, busque el kubeadm.alpha.kubernetes.io/cri-socket anotación y cámbiela a unix:///run/containerd/containerd.sock. Guarde y cierre el archivo para actualizar el objeto del nodo.
Ahora reinicie Kubelet:
$ systemctl start kubelet
Permita que el nodo se inicie y se conecte al plano de control de Kubernetes durante unos momentos. Debería poder repetir el get nodes comando y ver que containerd ahora se está utilizando.
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 containerd://1.4.13 node-2 Ready v1.22.8 containerd://1.4.13
Finalmente retira el cordón que colocaste alrededor del Nodo para que pueda comenzar a recibir Pods:
$ kubectl uncordon node-1
Usando cri-dockerd
cri-dockerd es un tiempo de ejecución desarrollado conjuntamente por Docker y Mirantis. Es efectivamente una versión independiente de Dockershim que se mantiene de forma independiente. Le permite seguir usando la funcionalidad familiar sin sobrecargar el proyecto de Kubernetes con los requisitos de mantenimiento de Dockershim.
Asegúrese de que ya tiene instalado Docker Engine. Luego instale cri-dockerd descargando el último binario de las versiones de GitHub:
$ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.2.0/cri-dockerd-v0.2.0-linux-amd64.tar.gz $ tar xvf cri-dockerd-v0.2.0-linux-amd64.tar.gz $ mv cri-dockerd /usr/local/bin/
A continuación, descargue, instale y habilite las configuraciones del servicio systemd de cri-dockerd:
wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.service wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.socket sudo mv cri-docker.socket cri-docker.service /etc/systemd/system/ sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service sudo systemctl daemon-reload sudo systemctl enable cri-docker.service sudo systemctl enable --now cri-docker.socket
Ahora puede modificar la configuración de Kubelet de su nodo para usar cri-dockerd. Esto es similar a configurar un Nodo para usar containerd.
Abierto /var/lib/kubelet/kubeadm-flags.env. Busque o añada el --container-runtime y --container-runtime-endpoint banderas con los siguientes valores:
--container-runtime=remote--container-runtime-endpoint=unix:///var/run/cri-dockerd.sock
A continuación, cambie la anotación de socket del objeto Node:
$ kubectl edit node node-1
En el archivo que se abre, busque el kubeadm.alpha.kubernetes.io/cri-socket anotación y cámbiela a unix:///var/run/cri-dockerd.sock. Guarde y cierre el archivo para actualizar el objeto del nodo.
Ahora reinicie Kubelet:
$ systemctl start kubelet
Espere unos momentos y luego use Kubectl para verificar que el Nodo esté activo. Todavía mostrará el tiempo de ejecución de Docker, pero ahora se basa en el cri-dockerd independiente, en lugar del Dockershim que está integrado con Kubernetes.
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 docker://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
Ahora puede quitar el cordón que colocó alrededor del Nodo. Comenzará a aceptar solicitudes de programación de pods nuevamente.
$ kubectl uncordon node-1
Conclusión
Kubernetes v1.24 eliminó el componente Dockershim que anteriormente integraba la compatibilidad CRI para Docker Engine. Si bien los clústeres más recientes no se verán afectados, debe verificar si está utilizando Dockershim antes de actualizar a la nueva versión.
El entorno de ejecución al que cambiar depende de cómo utilice actualmente su clúster. containerd suele ser una buena opción si no está utilizando las funciones de Docker. Puede usar cri-dockerd para recuperar una integración similar a la de Dockershim si necesita mantener la compatibilidad con las herramientas existentes que dependen de Docker Engine. esto también ayuda si estas montando el zócalo del demonio Docker (/var/run/docker.sock) en sus contenedores para potenciar los flujos de trabajo de Docker-in-Docker.
La eliminación de Dockershim no afecta la forma en que creas y usas imágenes de contenedores. Kubernetes todavía puede ejecutar imágenes creadas con docker build y son compatibles con todos los tiempos de ejecución admitidos. Los tiempos de ejecución de CRI funcionan con cualquier imagen en formato OCI, como resultado de Docker y otros creadores de imágenes.
