Los clústeres de Google Kubernetes Engine (GKE) usan imágenes de nodos de containerd con todos los nodos de trabajo que ejecutan la versión 1.24 y versiones posteriores. Los nodos de trabajo usan una versión específica de containerd, según la versión de GKE:
- Los nodos que ejecutan GKE 1.32 o versiones anteriores, con imágenes de nodos de containerd, usan containerd 1.7 o versiones anteriores.
- Los nodos que ejecutan GKE 1.33 usan containerd 2.0.
Cuando los nodos de GKE se actualizan de la versión 1.32 a la 1.33, los nodos migran de usar containerd 1.7 a la nueva versión principal, containerd 2.0. No puedes cambiar la versión de containerd que usa una versión de GKE.
Puedes omitir la lectura de esta página si sabes que tus cargas de trabajo se ejecutan como se espera en containerd 2.
Cómo GKE realiza la transición a containerd 2
Revisa el siguiente cronograma para comprender cómo GKE está realizando la transición de los clústeres existentes para usar containerd 2:
- Con la versión menor 1.32, GKE usa containerd 1.7. containerd 1.7 dejó de admitir las imágenes de Docker de esquema 1 y la API de v1alpha2 de Container Runtime Interface (CRI). Para obtener información sobre otras funciones que dejaron de estar disponibles en versiones anteriores, consulta Propiedades de configuración obsoletas.
- Con la versión menor 1.33, GKE usa containerd 2.0, que quita la compatibilidad con las imágenes de Docker de esquema 1 y la API de CRI v1alpha2.
- Las siguientes propiedades de configuración de containerd en el complemento CRI dejaron de estar disponibles y se quitarán en containerd 2.1, con una versión de GKE que aún no se anuncia:
registry.auths,registry.configs,registry.mirrors..
Para conocer los plazos aproximados de las actualizaciones automáticas a versiones secundarias posteriores, como la 1.33, consulta el Programa estimado para los canales de lanzamiento.
Impacto de la transición a containerd 2
Lee la siguiente sección para comprender el impacto de esta transición a containerd 2.
Se pausaron las actualizaciones automáticas
GKE pausa las actualizaciones automáticas a la versión 1.33 cuando detecta que un clúster usa las funciones obsoletas. Sin embargo, si los nodos de tu clúster usan estas funciones, te recomendamos que crees una exclusión de mantenimiento para evitar las actualizaciones de nodos. La exclusión de mantenimiento garantiza que tus nodos no se actualicen si GKE no detecta el uso.
Después de migrar del uso de estas funciones, si la versión 1.33 es un objetivo de actualización automática para los nodos de tu clúster y no hay otros factores que bloqueen las actualizaciones automáticas, GKE reanuda las actualizaciones menores automáticas a la versión 1.33. En el caso de los grupos de nodos de clústeres estándar, también puedes actualizar el grupo de nodos de forma manual.
Fin de la asistencia y el impacto de no prepararse para la migración
GKE pausa las actualizaciones automáticas hasta el final de la asistencia estándar. Si tu clúster está inscrito en el canal extendido, tus nodos pueden permanecer en una versión hasta el final de la compatibilidad extendida. Para obtener más detalles sobre las actualizaciones automáticas de nodos al final de la compatibilidad, consulta Actualizaciones automáticas al final de la compatibilidad.
Si no migras desde estas funciones, cuando la versión 1.32 llegue al fin de la asistencia y los nodos de tu clúster se actualicen automáticamente a la versión 1.33, es posible que experimentes los siguientes problemas con tus clústeres:
- Las cargas de trabajo que usan imágenes de Docker de esquema 1 fallan.
- Las aplicaciones que llaman a la API de CRI v1alpha2 experimentan fallas cuando llaman a la API.
Identifica los clústeres afectados
GKE supervisa tus clústeres y usa el servicio de Recommender para proporcionar orientación a través de estadísticas y recomendaciones que identifican los nodos de clúster que usan estas funciones obsoletas.
Requisitos de la versión
Los clústeres reciben estas estadísticas y recomendaciones si ejecutan las siguientes versiones o versiones posteriores:
- 1.28.15-gke.1159000
- 1.29.9-gke.1541000
- 1.30.5-gke.1355000
- 1.31.1-gke.1621000
Obtén estadísticas y recomendaciones
Sigue las instrucciones para ver estadísticas y recomendaciones. Puedes obtener estadísticas con la consola de Google Cloud. También puedes usar Google Cloud CLI o la API de Recommender. Para ello, filtra con los siguientes subtipos:
DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES:Imágenes de Docker de esquema 1- API de
DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API:CRI v1alpha2
Cómo migrar desde funciones obsoletas
Revisa el siguiente contenido para comprender cómo migrar desde funciones que dejaron de estar disponibles con containerd 2.
Migra de las imágenes de Docker de esquema 1
Identifica las cargas de trabajo que usan imágenes que se deben migrar y, luego, mígralas.
Busca las imágenes que se migrarán
Puedes usar diferentes herramientas para encontrar las imágenes que se deben migrar.
Usa estadísticas y recomendaciones o Cloud Logging
Como se explica en la sección Cómo identificar los clústeres afectados, puedes usar estadísticas y recomendaciones para encontrar clústeres que usen imágenes de Docker Schema 1 si tu clúster ejecuta una versión mínima o posterior. Además, puedes usar la siguiente consulta en Cloud Logging para verificar los registros de containerd y encontrar imágenes del esquema 1 de Docker en tu clúster:
jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"
Si transcurrieron más de 30 días desde que se extrajo la imagen, es posible que no veas los registros de una imagen.
Usa el comando ctr directamente en un nodo
Para consultar un nodo específico y que muestre todas las imágenes no borradas que se extrajeron como esquema 1, ejecuta el siguiente comando en un nodo:
ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'
Este comando puede ser útil si, por ejemplo, estás solucionando un problema de un nodo específico y no ves entradas de registro en Cloud Logging porque transcurrieron más de 30 días desde que se extrajo la imagen.
Usa la herramienta de código abierto crane
También puedes usar herramientas de código abierto, como crane, para buscar imágenes.
Ejecuta el siguiente comando crane para verificar la versión del esquema de una imagen:
crane manifest $tagged_image | jq .schemaVersion
Prepara las cargas de trabajo
Para preparar las cargas de trabajo que ejecutan imágenes de Docker de esquema 1, debes migrar esas cargas de trabajo a imágenes de Docker de esquema 2 o de Open Container Initiative (OCI). Considera las siguientes opciones para la migración:
- Busca una imagen de reemplazo: Es posible que encuentres una imagen de código abierto o proporcionada por el proveedor disponible públicamente.
- Convierte la imagen existente: Si no encuentras una imagen de reemplazo, puedes convertir las imágenes existentes de Docker de esquema 1 a imágenes de OCI con los siguientes pasos:
- Extrae la imagen de Docker a containerd, que la convierte automáticamente en una imagen de OCI.
- Envía la nueva imagen OCI a tu registro.
Migra desde la API de CRI v1alpha2
La API de CRI v1alpha2 se quitó en Kubernetes 1.26. Debes identificar las cargas de trabajo que acceden al socket de containerd y actualizar estas aplicaciones para que usen la API de v1.
Identifica las cargas de trabajo
Puedes usar diferentes técnicas para identificar las cargas de trabajo que se deben migrar.
Usa estadísticas y recomendaciones
Puedes usar las estadísticas y recomendaciones para encontrar clústeres que usen la API de v1alpha2 si tu clúster ejecuta una versión mínima o posterior. Para obtener más detalles, consulta Cómo identificar los clústeres afectados.
Cuando veas las estadísticas en la consola de Google Cloud, consulta el panel de la barra lateral Cómo migrar tus cargas de trabajo de la API de v1alpha2 de CRI obsoleta. Para encontrar cargas de trabajo que acceden al socket de contenedor, consulta la sección Cargas de trabajo que se deben verificar.
Usa kubectl
El siguiente comando te ayuda a encontrar cargas de trabajo que acceden al socket de containerd. Este comando muestra las cargas de trabajo que activan directorios hostPath que incluyen el socket. Esta consulta puede generar falsos positivos porque algunas cargas de trabajo activan estos directorios o otros directorios secundarios, pero no acceden al socket de containerd.
Ejecuta el siguiente comando:
kubectl get pods --all-namespaces -o json |
jq -r '.items[] |
select(.spec.volumes[]?.hostPath.path as $p |
["/", "/var", "/var/","/var/run", "/var/run/",
"/var/run/containerd", "/var/run/containerd/",
"/var/run/containerd/containerd.sock",
"/run", "/run/", "/run/containerd", "/run/containerd/",
"/run/containerd/containerd.sock"] | index($p)) |
.metadata.namespace + "/" + .metadata.name'
Verifica el código de la aplicación
Puedes verificar el código de tu aplicación para ver si importa bibliotecas cliente de la API de v1alpha2 de CRI.
Por ejemplo, consulta el siguiente código de Golang:
package main
import (
...
runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
)
func foo() {
...
client := runtimeapi.NewRuntimeServiceClient(conn)
version, err := client.Version(ctx, &runtimeapi.VersionRequest{})
...
}
Aquí, la aplicación importa la biblioteca v1alpha2 y la usa para emitir RPC. Si las RPC usan la conexión al socket de containerd, esta aplicación hace que GKE detenga las actualizaciones automáticas del clúster.
Sigue estos pasos para buscar y actualizar el código de tu aplicación:
Ejecuta el siguiente comando para identificar las aplicaciones de Golang problemáticas y buscar la ruta de importación v1alpha2:
grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"Si el resultado de este comando muestra que se usa la biblioteca v1alpha2 en el archivo, debes actualizarlo.
Por ejemplo, reemplaza el siguiente código de la aplicación:
runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"Actualiza el código para usar la versión 1:
runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"