Cómo afecta la próxima desaprobación de Dockershim a sus Kubernetes
La plataforma de orquestación de contenedores Kubernetes anunció en diciembre de 2020 que su tercer y último lanzamiento, Kubernetes v1.20, dejaría de usar dockershim y, posteriormente, Docker como tiempo de ejecución de contenedores. Esta desaprobación ha traído múltiples cambios que los administradores deben conocer y responder en consecuencia.
Para comprender mejor estos cambios y cómo la desaprobación de dockershim afecta a los administradores y su trabajo, analicemos rápidamente qué es dockershim, su relevancia para la seguridad de los contenedores y las razones detrás de la decisión de Kubernetes de desaprobarlo.
¿Qué es Dockershim?
El módulo dockershim es parte de la solución de Kubernetes para usar múltiples tiempos de ejecución de contenedores en un solo kubelet sin obligarlo a recompilar. Esta solución se conoce, más específicamente, como el complemento Container Runtime Interface (CRI) y se introdujo después de que Kubernetes desarrollara dockershim.
El complemento CRI fue un éxito porque les dio a los operadores de clústeres de Kubernetes la libertad de interactuar con múltiples tiempos de ejecución de contenedores, pero también requirió que Kubernetes eventualmente creara una forma para que el kubelet reconociera el tiempo de ejecución del contenedor Docker como uno compatible con CRI. Dockershim es el componente adaptador que surge como respuesta a esta inevitable necesidad.
¿Por qué Kubernetes desaprueba Dockershim?
En sus primeros años, la plataforma Kubernetes ofrecía compatibilidad solo con el tiempo de ejecución del contenedor Docker. El surgimiento de Dockershim como una solución de intermediario presagió los problemas que causaría con los tiempos de ejecución de contenedores de Docker en general. El módulo dockershim se transformó de una solución temporal a una permanente y finalmente se volvió demasiado difícil de mantener.
El módulo dockershim, en particular, ejerció una gran presión sobre los operadores responsables del mantenimiento de la plataforma Kubernetes. Según la experta en DevOps Barbara Ericson, Kubernetes proporciona un entorno autónomo “donde cada aplicación tiene su código fuente, tiempo de ejecución, archivos de soporte, archivos de configuración, etc., lo que permite que las aplicaciones se ejecuten en entornos remotos”.
El hecho de que la compatibilidad de Kubernetes con Docker sea anterior a la compatibilidad con el complemento CRI dificulta el mantenimiento de este tipo de entorno autónomo con dockershim y ha resultado en una situación complicada para los administradores.
¿Qué tan preocupado debería estar?
El uso de contenedores para crear aplicaciones desde cero o la migración de aplicaciones existentes a un entorno en contenedores puede ser estresante y consumir mucho tiempo. Es comprensible que algunos administradores estén preocupados por la desaprobación de dockershim y si los dejará con dependencias vestigiales en Docker como tiempo de ejecución de contenedores o incluso representará riesgos de seguridad durante la comunicación entre el software compatible con Kubernetes responsable de los contenedores durante los próximos meses.
Afortunadamente, Kubernetes ha declarado que, si bien Dockershim se eliminará de Kubelet desde su lanzamiento v1.23, los administradores no deben entrar en pánico todavía. Los administradores solo necesitan cambiar el tiempo de ejecución de su contenedor de Docker a un tiempo de ejecución de contenedor independiente compatible con Kubernetes para acomodar el incumplimiento de Docker con CRI y la subsiguiente desaprobación de dockershim.
Los administradores también deben ser conscientes de que si utilizan el servicio o la distribución de Kubernetes administrados, es probable que puedan ponerse en contacto con su proveedor para confirmar que no habrá ningún impacto en su entorno una vez que apaguen el tiempo de ejecución de Docker para siempre. Los administradores que usan Kubernetes de código abierto en sus clústeres deben aplicar los cambios ellos mismos.
¿Se verán afectados los administradores?
La plataforma de orquestación de contenedores ha confirmado que no dejará de usar dockershim antes del lanzamiento de Kubernetes v1.22 y ha aclarado que la versión 1.23 es probablemente la primera versión que no contará con soporte para dockershim. Lo que esto significa en el futuro es que las futuras versiones de Kubernetes, de hecho, no contarán con soporte para el módulo dockershim; Sin embargo, los administradores aún podrán usar Docker en general.
Kubernetes ha señalado que los administradores deben intentar ejecutar comandos de Docker fuera del alcance de sus herramientas de terceros, así como scripts y aplicaciones que se ejecutan en notas fuera del clúster de Kubernetes. Según Kubernetes, esto ayudará a los administradores a ubicar las dependencias en Docker como tiempo de ejecución del contenedor una vez que se haya implementado la desaprobación. Los administradores deben continuar monitoreando las dependencias indirectas de dockershim que pueden afectar las aplicaciones y considerar sus limitaciones de recursos de tiempo de ejecución y otros elementos que aún pueden requerir acceso a Docker.
¿Cómo sé si me afectará la depreciación?
Los administradores deben investigar si su clúster de Kubernetes todavía usa Docker como tiempo de ejecución del contenedor, así como las cargas de trabajo que pueden verse afectadas. Dockershim juega un papel cuando se usa como tiempo de ejecución de contenedor. Esto puede potencialmente causar complicaciones con las cargas de trabajo y evitar que los comandos de Docker se ejecuten o produzcan resultados inesperados.
Kubernetes ha recomendado que los administradores sigan varios pasos para averiguar si una aplicación que están usando depende de Docker. Agentes de seguridad y monitoreo populares que se instalan en nodos fuera del kubelet pueden ser culpables comunes ocultando las dependencias de Docker.
Las herramientas de terceros que realizan operaciones de supervisión privilegiadas no dependen directamente de los contenedores de alojamiento en tiempo de ejecución. Sin embargo, todavía hay muchos agentes de telemetría y seguridad que dependen de Docker para recopilar metadatos, registros y métricas de contenedores. Los registros de dispositivos de red pueden ofrecer información crítica sobre cómo funcionan los dispositivos y cómo se utilizan los recursos de la red.
Resumen
No se puede negar que las próximas versiones de Kubernetes no ofrecerán soporte para el módulo dockershim. Para que la plataforma de orquestación de contenedores use correctamente el kubelet para admitir CRI para Docker, es necesario desaprobar la solución dockershim que alguna vez fue temporal y darle el reconocimiento que merece. Dicho esto, los administradores deberían considerar investigar sus entornos en busca de dependencias en Docker como tiempo de ejecución de contenedores.
Una vez que comprendan y hayan abordado sus dependencias de dockershim, los administradores pueden comenzar el proceso de pasar a un tiempo de ejecución de contenedor compatible. Kubernetes recomienda que los administradores continúen monitoreando sus recursos de tiempo de ejecución y configuraciones de registro. Dependiendo de su infraestructura, es posible que necesiten realizar ciertos cambios y usar herramientas complementarias para que un nuevo tiempo de ejecución de contenedor funcione para ellos.
