En esta página, se proporciona información sobre el entorno de ejecución de contenedor de 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 usan containerd. Para obtener instrucciones sobre cómo migrar a una imagen de nodo de containerd, consulta Migra desde Docker a imágenes de nodo de containerd.
Descripción general
Los nodos de Kubernetes usan el entorno de ejecución de contenedor para iniciar, administrar y detener contenedores que se ejecutan en Pods. El proyecto de Kubernetes está quitando la compatibilidad integrada para el entorno de ejecución de Docker en la versión 1.24 y posteriores de Kubernetes. Para lograrlo, Kubernetes quita un componente llamado dockershim, que permite que Docker se comunique con los componentes de Kubernetes, como el kubelet.
Containerd, el nuevo entorno de ejecución predeterminado, es un entorno de ejecución del contenedor estándar de la industria que es compatible con Kubernetes y que usan muchos otros proyectos. El entorno de ejecución de containerd proporciona la abstracción por capas que permite la implementación de un amplio conjunto de funciones comogVisor y Transmisión de imágenes para extender la funcionalidad de GKE. El entorno de ejecución también se considera el recurso más eficiente y seguro que el entorno de ejecución de Docker.
Debido a este cambio, GKE no admite imágenes de nodo que usan Docker como el entorno 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 nodo basadas en Docker o usa aprovisionamiento automático de nodos con un tipo de imagen de nodo predeterminado basado en Docker.
Antes del 31 de julio de 2023, la fecha de final del ciclo de vida de la versión 1.23 de GKE, GKE pausa las actualizaciones automáticas y evita las manuales las actualizaciones a la versión 1.24. Para actualizar el plano de control de tu clúster a la versión 1.24 de GKE y posteriores antes de esta fecha, debes actualizar tu configuración de aprovisionamiento automático de nodos y todos los nodos en el entorno de ejecución de containerd. Para actualizar un grupo de nodos, debes migrar a una imagen de nodo que use el entorno de ejecución de containerd.
Después de que la versión 1.23 llega al final del ciclo de vida, GKE desbloquea las actualizaciones manuales del plano de control a la versión 1.24 para los clústeres que aun no completaron la migración y comienza a actualizar de manera gradual los clústeres por seguridad y compatibilidad. Para obtener más información sobre cómo GKE actualiza tus clústeres a la versión 1.24 y qué recomendamos para migrarlos de imágenes de nodos de Docker, consulta Migración automática cuando la versión 1.23 alcanza el final del ciclo de vida.
Imágenes de nodos de Docker y containerd
Containerd es el entorno de ejecución predeterminado para todos los nodos nuevos de GKE 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 nodo que usaban Docker como entorno de ejecución. En la siguiente tabla, se describen imágenes de nodo basadas en Docker que no serán compatibles con GKE versión 1.24 y posteriores, y los 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 ( |
Cronograma y eventos importantes
En la versión 1.23 de GKE, ya no puedes hacer lo siguiente:
- Crear clústeres nuevos que usen imágenes de nodo basadas en Docker.
- Agregar grupos de nodos nuevos con imágenes de nodo basadas en Docker a un clúster existente.
- Habilitar el aprovisionamiento automático de nodos con la marca
--autoprovisioning-image-typeconfigurada en imágenes de nodo basadas en Docker.
Si actualizas a la versión 1.23 de GKE, puedes continuar con lo siguiente:
- Grupos de nodos existentes con imágenes de nodo basadas en Docker creadas antes de la actualización.
- Escalador automático de clústeres en grupos de nodos con imágenes de nodo de Docker.
- Aprovisionamiento automático de nodos con la marca
--autoprovisioning-image-typeconfigurada como imágenes de nodo basadas en Docker, si está habilitada 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-typeconfigurada como imágenes de nodo basadas en Docker. - Si el grupo de nodos ejecuta la versión 1.24, los nodos no pueden usar imágenes de nodo basadas en Docker.
En la siguiente tabla, se proporciona un resumen de los cambios esperables cuando interactúes con las próximas versiones de GKE:
| Acción | Versión 1.23 de GKE | Versión 1.24 de GKE |
|---|---|---|
| Crear clústeres nuevos con Docker | No | No |
| Crear grupos de nodos nuevos con Docker | No | No |
| Habilita el aprovisionamiento automático de nodos con Docker | No | No |
| Actualizar desde una versión anterior con la configuración existente de aprovisionamiento automático de nodos de Docker | Sí | No |
| Usa imágenes de nodo basadas en Docker | Sí | No |
Migración automática cuando la versión 1.23 llega al final del ciclo de vida
Si no actualizas a la versión 1.24 y migras a las imágenes de nodo de containerd antes de que la versión 1.23 alcance el final del ciclo de vida el 31 de julio de 2023, GKE hace lo siguiente con el tiempo:
Si el clúster tiene aprovisionamiento automático de nodos con un tipo de imagen de nodo predeterminado basado en Docker, GKE actualiza la configuración para usar la imagen de nodo equivalente que usa el entorno de ejecución de containerd. No se puede bloquear esta operación con una exclusión de mantenimiento. Para verificar que no haya un efecto adverso en tus cargas de trabajo, recomendamos que actualices de forma manual el tipo de imagen predeterminado de aprovisionamiento automático de nodos a una imagen basada en contenedores antes de que GKE actualice la configuración de forma automática.
GKE actualiza el plano de control de tu clúster a la versión 1.24.
GKE migra cualquier grupo de nodos que aún use Docker a imágenes de nodo de containerd a partir del 1 de septiembre de 2023. Te recomendamos que migres las imágenes de nodo de forma manual antes de esta fecha. Como alternativa, puedes solicitar que GKE inicie una operación para migrar el clúster y usar imágenes de containerd. Para realizar esta solicitud, comunícate con Atención al cliente de Cloud.
Para bloquear de forma temporal 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 la migración automática a imágenes de nodo de containerd de forma temporal.
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 garantizar la alineación del estado del clúster con la política de sesgo de la versión de código abierto. Para obtener más información, consulta el ciclo de vida de la versión secundaria de GKE. Puedes bloquear esta actualización de forma temporal con una exclusión de mantenimiento.
Retrasa la migración automática a imágenes de nodo de containerd de forma temporal
Después de 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 que los nodos se migren de forma temporal hasta el 29 de febrero de 2024, cuandola versión 1.25 llega al final de la compatibilidad.
Si quieres ser apto para esta exclusión de mantenimiento, tu clúster debe estar inscrito en un canal de versiones.
Configura la exclusión de mantenimiento con el alcance “Sin actualizaciones menores o de nodo” y establece la marca --add-maintenance-exclusion-end en 2024-02-29T00:00:00Z o 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 alcanzaron el final de la compatibilidad ya no recibirán parches de seguridad ni correcciones de errores.
Migra de Docker a imágenes de nodo containerd
Consulta Migra de Docker a imágenes de nodo containerd para identificar clústeres y grupos de nodos mediante imágenes de nodo basadas en Docker y migrar esos grupos de nodos a imágenes de nodo containerd.
Como parte del modelo de responsabilidad compartida de GKE, es parte de las responsabilidades del cliente para mantener el estado de las cargas de trabajo y es parte de las responsabilidades de Google para garantizar que el clúster siga funcionando, lo que incluye ejecutar una versión compatible. Te recomendamos probar las cargas de trabajo y migrar el clúster antes de que GKE lo haga de forma automática.
Antes de que la versión 1.23 llegue al final de la compatibilidad, GKE evita las actualizaciones automáticas o manuales a la versión 1.24 para los clústeres que tienen grupos de nodos que usan imágenes de nodo de Docker. Después de migrar tu clúster para usar solo imágenes de containerd, las actualizaciones automáticas pueden reanudarse en un día, según el programa de lanzamientos de GKE, o puedes actualizar tu clúster de forma manual.
Después de que la versión 1.23 llega al final de la compatibilidad, GKE desbloquea las actualizaciones automáticas o manuales a la versión 1.24 y sigue el proceso de migración automática.
Impacto de la migración
El cambio principal cuando migras a imágenes de nodo de containerd es que Docker ya no administra el ciclo de vida de tus contenedores (como 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 ejecutan en nodos que usan imágenes en containerd.
La mayoría de las cargas de trabajo de usuarios no tienen una dependencia del entorno de ejecución del contenedor. El entorno de ejecución de Docker también implementa containerd, por lo que las cargas de trabajo se comportan de manera similar en las imágenes de nodo de containerd.
Es posible que te veas afectado si se aplican las siguientes situaciones:
- Ejecutas Pods con privilegios que ejecutan comandos de Docker.
- Debes ejecutar secuencias de comandos en nodos desde fuera de la infraestructura de Kubernetes (por ejemplo, para usar SSH a fin de 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 supervisión.
- Implementas herramientas de integración continua, seguridad, supervisión o registro proporcionadas por proveedores externos en el clúster de GKE. Comunícate 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 el clúster de GKE. Las imágenes de nodo de Linux con containerd incluyen el objeto binario de Docker y admiten estos comandos.
Usa Pods privilegiados para acceder a Docker
Si tus usuarios acceden a Docker Engine en un nodo mediante un Pod privilegiado, debes actualizar esas cargas de trabajo para que no dependan directamente de Docker. Por ejemplo, considera migrar el proceso de extracción de registros y supervisión de Docker Engine a complementos del sistema de GKE.
Compila imágenes de contenedores con containerd
No puedes usar containerd para compilar imágenes de contenedor. Las imágenes de Linux con containerd incluyen el objeto binario de Docker para que puedas usar Docker a fin de compilar y enviar imágenes. Sin embargo, no recomendamos el uso de contenedores individuales y nodos locales a fin de ejecutar comandos para compilar imágenes.
Kubernetes no tiene conocimiento de los recursos del sistema usados por los procesos locales fuera del alcance de Kubernetes, y el plano de control de Kubernetes no puede dar cuenta de esos procesos cuando se asignan recursos. Esto puede privar a tus cargas de trabajo de recursos de GKE o causar inestabilidad en el nodo.
Considera cumplir estas tareas mediante otros servicios fuera del alcance del contenedor individual, como Cloud Build, o usa una herramienta como kaniko para compilar imágenes como una carga de trabajo de Kubernetes.
Si ninguna de estas sugerencias te funciona y comprendes los riesgos, puedes seguir usando Docker en el nodo local para compilar imágenes. Debes enviar las imágenes a un registro para poder usarlas en un clúster de GKE. Kubernetes con containerd no conoce las imágenes compiladas de forma local mediante Docker.
Depura contenedores en nodos de containerd
Para depurar o solucionar problemas en el nodo de Linux, puedes interactuar con containerd mediante la herramienta de línea de comandos portátil creada para entornos de ejecución de contenedor de Kubernetes: crictl. crictl admite funcionalidades comunes para ver imágenes y contenedores, leer registros y ejecutar comandos en los contenedores. Consulta la guía del usuario de crictl para ver el conjunto completo de características admitidas y la información de uso.
Para los nodos de Windows Server, el daemon 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".
Soluciona problemas
Para solucionar problemas, ve a Soluciona problemas con el entorno de ejecución de containerd.
¿Qué sigue?
- Lee sobre la baja de dockershim.
- Verifica si la baja te afecta.
- Migra de Docker a imágenes de nodo containerd.