En esta página se proporciona información sobre el tiempo de ejecución de contenedores containerd, la compatibilidad con Docker en Google Kubernetes Engine (GKE) y una descripción general de por qué debes migrar a imágenes de nodo que usen containerd. Para obtener instrucciones sobre cómo migrar a una imagen de nodo de containerd, consulta Migrar de Docker a imágenes de nodo de containerd.
Información general
Los nodos de Kubernetes usan el entorno de ejecución de contenedores para iniciar, gestionar y detener los contenedores que se ejecutan en los pods. El proyecto de Kubernetes va a eliminar la compatibilidad integrada con el tiempo de ejecución de Docker en la versión 1.24 de Kubernetes y en las posteriores. Para ello, Kubernetes va a eliminar un componente llamado dockershim, que permite que Docker se comunique con componentes de Kubernetes como kubelet.
Containerd, el nuevo tiempo de ejecución predeterminado, es un tiempo de ejecución de contenedores estándar del sector compatible con Kubernetes y utilizado en muchos otros proyectos. El tiempo de ejecución de containerd proporciona la abstracción de capas que permite implementar un amplio conjunto de funciones, como gVisor y Image streaming, para ampliar la funcionalidad de GKE. El tiempo de ejecución también se considera más eficiente y seguro que el tiempo de ejecución de Docker.
Debido a este cambio, GKE no admite imágenes de nodo que usen Docker como tiempo de ejecución en la versión 1.24 de GKE y posteriores. Un clúster se ve afectado si alguno de sus grupos de nodos usa imágenes de nodos basadas en Docker o usa el aprovisionamiento automático de nodos con un tipo de imagen de nodo predeterminado basado en Docker.
Antes del 31 de julio del 2023, fecha de finalización del ciclo de vida de la versión 1.23 de GKE, GKE pausará las actualizaciones automáticas e impedirá las actualizaciones manuales a la versión 1.24. Para actualizar el plano de control de tu clúster a la versión 1.24 de GKE o una posterior antes de esa fecha, debes actualizar la configuración de aprovisionamiento automático de nodos y todos los nodos al tiempo de ejecución de containerd. Para actualizar un grupo de nodos, debes migrar a una imagen de nodo que use el tiempo de ejecución de containerd.
Una vez que la versión 1.23 haya llegado al final de su ciclo de vida, GKE desbloqueará las actualizaciones manuales del plano de control a la versión 1.24 para los clústeres que aún no hayan completado la migración y empezará a actualizar los clústeres gradualmente por motivos de seguridad y compatibilidad. Para obtener más información sobre cómo actualiza GKE tus clústeres a la versión 1.24 y qué te recomendamos que hagas para migrar tus clústeres desde imágenes de nodos de Docker, consulta Migración automática cuando la versión 1.23 llegue al final de su ciclo de vida.
Imágenes de nodo de Docker y containerd
Containerd es el tiempo de ejecución predeterminado de todos los nodos de GKE nuevos desde la versión 1.19 en Linux y la 1.21 en Windows. Sin embargo, los clústeres estándar de GKE también seguían admitiendo imágenes de nodos que usaban Docker como tiempo de ejecución. En la siguiente tabla se describen las imágenes de nodo basadas en Docker que no se admitirán en GKE 1.24 y versiones posteriores, así como sus equivalentes de containerd:
| Entorno de ejecución de Docker | Entorno de ejecución de containerd |
|---|---|
Container-Optimized OS con Docker (cos) |
Container-Optimized OS con containerd (cos_containerd) |
Ubuntu con Docker (ubuntu) |
Ubuntu con containerd (ubuntu_containerd) |
Windows Server LTSC con Docker (windows_ltsc) |
Windows Server LTSC con containerd (windows_ltsc_containerd) |
Windows Server SAC con Docker ( |
Windows Server SAC con containerd ( |
Cronología e hitos
En GKE 1.23, ya no puedes hacer lo siguiente:
- Crea clústeres que usen imágenes de nodos basadas en Docker.
- Añadir grupos de nodos con imágenes de nodo basadas en Docker a un clúster.
- Habilita el aprovisionamiento automático de nodos con la marca
--autoprovisioning-image-typedefinida en imágenes de nodo basadas en Docker.
Si actualizas a la versión 1.23 de GKE, puedes seguir usando lo siguiente:
- Grupos de nodos con imágenes de nodos basadas en Docker creados antes de la actualización.
- Adaptación dinámica de clústeres en grupos de nodos con imágenes de nodos de Docker.
- El aprovisionamiento automático de nodos con la marca
--autoprovisioning-image-typedefinida en imágenes de nodos basadas en Docker, si se ha habilitado antes de la actualización.
En la versión 1.24 de GKE, ya no puedes hacer lo siguiente:
- Si el plano de control ejecuta la versión 1.24, no puedes usar el aprovisionamiento automático de nodos con la marca
--autoprovisioning-image-typedefinida en imágenes de nodos basadas en Docker. - Si el grupo de nodos ejecuta la versión 1.24, los nodos no podrán usar imágenes de nodos basadas en Docker.
En la siguiente tabla se resumen los cambios que se producirán cuando interactúes con las próximas versiones de GKE:
| Acción | Versión 1.23 de GKE | GKE 1.24 |
|---|---|---|
| Crear clústeres con Docker | No | No |
| Crear grupos de nodos con Docker | No | No |
| Habilitar el aprovisionamiento automático de nodos con Docker | No | No |
| Actualizar desde la versión anterior con la configuración de aprovisionamiento automático de nodos de Docker | Sí | No |
| Usar imágenes de nodo basadas en Docker | Sí | No |
Migración automática cuando la versión 1.23 llegue al final de su ciclo de vida
Si no actualizas a la versión 1.24 y migras a imágenes de nodo de containerd antes de que la versión 1.23 llegue al final de su ciclo de vida el 31 de julio del 2023, GKE hará lo siguiente con el tiempo:
Si tu clúster tiene aprovisionamiento automático de nodos con un tipo de imagen de nodo predeterminada basado en Docker, GKE actualiza la configuración para usar la imagen de nodo equivalente que usa el tiempo de ejecución de containerd. No puedes bloquear esta operación con una exclusión de mantenimiento. Para verificar que no haya ningún efecto adverso en tus cargas de trabajo, te recomendamos que actualices manualmente el tipo de imagen predeterminado de aprovisionamiento automático de nodos a una imagen basada en containerd antes de que GKE actualice automáticamente la configuración.
GKE actualiza el plano de control de tu clúster a la versión 1.24.
GKE migrará los grupos de nodos que sigan usando Docker a imágenes de nodo de containerd a partir del 1 de septiembre del 2023. Te recomendamos que migres manualmente las imágenes de los nodos antes de esa fecha. También puedes solicitar que GKE inicie una operación para migrar tu clúster y que use imágenes de containerd. Para hacer esta solicitud, ponte en contacto con Cloud Customer Care.
Para bloquear temporalmente la migración automática, actualiza tu clúster a la versión 1.24 o posterior y configura una exclusión de mantenimiento. Para obtener más información sobre esta exclusión de mantenimiento, consulta Retrasar temporalmente la migración automática a imágenes de nodos de containerd.
GKE actualiza los grupos de nodos de la versión 1.23 a la 1.24, como se hace con cualquier versión no compatible, para asegurar que el estado del clúster se ajuste a la política de diferencia de versiones de código abierto. Para obtener más información, consulta el ciclo de vida de las versiones secundarias de GKE. Puedes bloquear temporalmente esta actualización con una exclusión de mantenimiento.
Retrasar temporalmente la migración automática a imágenes de nodo de containerd
Una vez que el plano de control de tu clúster se haya actualizado a la versión 1.24 o posterior, puedes configurar una exclusión de mantenimiento para evitar temporalmente que los nodos se migren hasta el 29 de febrero del 2024, cuando la versión 1.25 deje de recibir asistencia.
Para poder beneficiarte de esta exclusión de mantenimiento, tu clúster debe estar registrado en un canal de lanzamiento.
Configura la exclusión de mantenimiento con el ámbito"No minor or node upgrades" (Sin actualizaciones de versiones secundarias ni de nodos) y define la marca --add-maintenance-exclusion-end en 2024-02-29T00:00:00Z o una versión anterior. Te recomendamos que desbloquees la migración lo antes posible y permitas que los nodos se actualicen a la versión 1.24. Las versiones secundarias que hayan llegado al final de su ciclo de asistencia dejarán de recibir parches de seguridad y correcciones de errores.
Migrar de Docker a imágenes de nodo de containerd
Consulta Migrar de imágenes de nodo de Docker a imágenes de nodo de containerd para identificar los clústeres y los grupos de nodos que usan imágenes de nodo basadas en Docker y migrar esos grupos de nodos a imágenes de nodo de containerd.
Como parte del modelo de responsabilidad compartida de GKE, los clientes tienen la responsabilidad de mantener el buen estado de las cargas de trabajo, y Google tiene la responsabilidad de asegurarse de que el clúster siga funcionando, lo que incluye ejecutar una versión compatible. Te recomendamos encarecidamente que pruebes tus cargas de trabajo y migres tu clúster antes de que GKE lo haga automáticamente.
Antes de que finalice la asistencia para la versión 1.23, GKE impide que se actualicen automáticamente o manualmente a la versión 1.24 los clústeres que tengan grupos de nodos que usen imágenes de nodos de Docker. Una vez que hayas migrado tu clúster para que solo use imágenes de containerd, las actualizaciones automáticas se podrán reanudar en un día (según la programación de lanzamientos de GKE) o podrás actualizar tu clúster manualmente.
Una vez que la versión 1.23 deje de recibir asistencia, GKE desbloqueará las actualizaciones automáticas o manuales a la versión 1.24 y seguirá el proceso de migración automática.
Impacto de la migración
El principal cambio al migrar a imágenes de nodo de containerd es que Docker ya no gestiona el ciclo de vida de tus contenedores (por ejemplo, iniciarlos y detenerlos). Por lo tanto, no puedes usar comandos de Docker ni la API de Docker para ver o interactuar con contenedores de GKE que se ejecuten en nodos que usen imágenes de containerd.
La mayoría de las cargas de trabajo de los usuarios no dependen del tiempo de ejecución del contenedor. El tiempo de ejecución de Docker también implementa containerd, por lo que tus cargas de trabajo se comportan de forma similar en las imágenes de nodo de containerd.
Es posible que te veas afectado si se da alguna de las siguientes situaciones:
- Ejecutas pods con privilegios que ejecutan comandos de Docker.
- Ejecutas secuencias de comandos en nodos desde fuera de la infraestructura de Kubernetes (por ejemplo, para usar SSH y solucionar problemas).
- Ejecutas herramientas de terceros que realizan operaciones con privilegios similares.
- Algunas de tus herramientas responden a los registros específicos de Docker en tu sistema de monitorización.
- Despliega en tu clúster de GKE herramientas de registro, monitorización, seguridad o integración continua proporcionadas por proveedores externos. Póngase en contacto con estos proveedores para confirmar el impacto.
No te verás afectado en las siguientes situaciones:
- Tienes una canalización de compilación fuera del clúster de GKE que usa Docker para compilar y enviar imágenes de contenedor.
- Usas los comandos
docker buildydocker pushen tu clúster de GKE. Las imágenes de nodo de Linux con containerd incluyen el archivo binario de Docker y admiten estos comandos.
Usar pods con privilegios para acceder a Docker
Si tus usuarios acceden a Docker Engine en un nodo mediante un pod con privilegios, debes actualizar esas cargas de trabajo para que no dependan directamente de Docker. Por ejemplo, puedes migrar tu proceso de extracción de registros y monitorización de Docker Engine a los complementos del sistema de GKE.
Crear imágenes de contenedor con containerd
No puedes usar containerd para compilar imágenes de contenedor. Las imágenes de Linux con containerd incluyen el archivo binario de Docker para que puedas usar Docker para compilar y enviar imágenes. Sin embargo, no recomendamos usar contenedores individuales ni nodos locales para ejecutar comandos que compilen imágenes.
Kubernetes no conoce los recursos del sistema que usan los procesos locales fuera del ámbito de Kubernetes, y el plano de control de Kubernetes no puede tener en cuenta esos procesos al asignar recursos. Esto puede provocar que tus cargas de trabajo de GKE se queden sin recursos o que el nodo se vuelva inestable.
Plantéate llevar a cabo estas tareas con otros servicios que no estén incluidos en el contenedor individual, como Cloud Build, o usa una herramienta como kaniko para crear imágenes como carga de trabajo de Kubernetes.
Si ninguna de estas sugerencias te sirve y conoces los riesgos, puedes seguir usando Docker en el nodo local para compilar imágenes. Debes enviar las imágenes a un registro antes de poder usarlas en un clúster de GKE. Kubernetes con containerd no reconoce las imágenes creadas localmente con Docker.
Depurar contenedores en nodos de containerd
Para depurar o solucionar problemas en nodos Linux, puedes interactuar con
containerd mediante la herramienta de línea de comandos portátil creada para los tiempos de ejecución de contenedores de Kubernetes: crictl. crictl admite funcionalidades comunes para ver contenedores e imágenes, leer registros y ejecutar comandos en los contenedores. Consulta la guía de usuario de crictl para ver el conjunto completo de funciones admitidas e información sobre el uso.
En los nodos de Windows Server, el daemon de containerd se ejecuta como un servicio de Windows llamado containerd.
Los registros están disponibles de la siguiente manera:
- Windows:
C:\etc\kubernetes\logs\containerd.log - Linux: ejecuta
journalctl -u containerd
También puedes ver los registros de los nodos de Windows y Linux en el Explorador de registros, en LOG NAME: "container-runtime".
Solución de problemas
Para solucionar problemas, consulta el artículo Solucionar problemas con el tiempo de ejecución de containerd.
Siguientes pasos
- Consulta información sobre la discontinuación de dockershim.
- Comprueba si la retirada te afecta.
- Migrar de imágenes de nodo de Docker a containerd.