Cette page a été traduite par l'API Cloud Translation.

Migrer des nœuds vers containerd 2

Les clusters Google Kubernetes Engine (GKE) utilisent des images de nœuds conteneurisées avec tous les nœuds de calcul exécutant la version 1.24 ou ultérieure. Les nœuds de calcul utilisent une version spécifique de containerd, en fonction de la version de GKE:

Les nœuds exécutant GKE 1.32 ou version antérieure, avec des images de nœuds containerd, utilisent containerd 1.7 ou une version antérieure.
Les nœuds qui exécutent GKE 1.33 utilisent containerd 2.0.

Lorsque les nœuds GKE passent de la version 1.32 à la version 1.33, ils passent de containerd 1.7 à la nouvelle version majeure, containerd 2.0. Vous ne pouvez pas modifier la version de containerd utilisée par une version de GKE.

Vous pouvez ignorer cette page si vous savez que vos charges de travail s'exécutent comme prévu sur containerd 2.

Comment GKE passe à containerd 2

Consultez le calendrier suivant pour comprendre comment GKE fait passer les clusters existants à containerd 2:

À partir de la version mineure 1.32, GKE utilise containerd 1.7. containerd 1.7 a abandonné à la fois les images Docker de schéma 1 et l'API CRI (Container Runtime Interface) v1alpha2. Pour en savoir plus sur les autres fonctionnalités obsolètes dans les versions précédentes, consultez la section Propriétés de configuration obsolètes.
Avec la version mineure 1.33, GKE utilise containerd 2.0, qui supprime la prise en charge des images Docker de schéma 1 et de l'API CRI v1alpha2.
Les propriétés de configuration containerd suivantes du plug-in CRI sont obsolètes et seront supprimées dans containerd 2.1, avec une version GKE à annoncer: registry.auths, registry.configs, registry.mirrors.

Pour connaître la date approximative des mises à niveau automatiques vers des versions mineures ultérieures telles que la version 1.33, consultez le calendrier estimé des canaux de publication.

Impact de la transition vers containerd 2

Lisez la section suivante pour comprendre l'impact de cette transition vers containerd 2.

Mises à niveau automatiques suspendues

GKE suspend les mises à niveau automatiques vers la version 1.33 lorsqu'il détecte qu'un cluster utilise les fonctionnalités obsolètes. Toutefois, si vos nœuds de cluster utilisent ces fonctionnalités, nous vous recommandons de créer une exclusion de maintenance pour éviter les mises à niveau des nœuds. L'exclusion de maintenance garantit que vos nœuds ne sont pas mis à niveau si GKE ne détecte pas d'utilisation.

Une fois que vous avez cessé d'utiliser ces fonctionnalités, si la version 1.33 est une cible de mise à niveau automatique pour les nœuds de votre cluster et qu'aucun autre facteur ne bloque les mises à niveau automatiques, GKE reprend les mises à niveau mineures automatiques vers la version 1.33. Pour les pools de nœuds de cluster standards, vous pouvez également mettre à niveau manuellement le pool de nœuds.

Fin de la période de compatibilité et conséquences de l'absence de préparation à la migration

GKE suspend les mises à niveau automatiques jusqu'à la fin de la période d'assistance standard. Si votre cluster est inscrit au canal Extended, vos nœuds peuvent rester sur une version jusqu'à la fin de l'assistance étendue. Pour en savoir plus sur les mises à niveau automatiques des nœuds à la fin de la période de compatibilité, consultez la section Mises à niveau automatiques à la fin de la période d'assistance.

Si vous ne migrez pas de ces fonctionnalités, lorsque la version 1.32 atteindra la fin de sa période de compatibilité et que les nœuds de votre cluster seront automatiquement mis à niveau vers la version 1.33, vous risquez de rencontrer les problèmes suivants avec vos clusters:

Les charges de travail utilisant des images Docker de schéma 1 échouent.
Les applications qui appellent l'API CRI v1alpha2 rencontrent des erreurs lors de l'appel de l'API.

Migrer depuis des fonctionnalités obsolètes

Consultez le contenu suivant pour comprendre comment migrer à partir de fonctionnalités obsolètes avec containerd 2.

Migrer depuis les images Docker de schéma 1

Identifiez les charges de travail utilisant des images à migrer, puis migrez-les.

Rechercher des images à migrer

Vous pouvez utiliser différents outils pour trouver les images à migrer.

Utiliser Cloud Logging

Vous pouvez utiliser la requête suivante dans Cloud Logging pour vérifier les journaux containerd afin de trouver les images Docker Schema 1 dans votre cluster:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

Si plus de 30 jours se sont écoulés depuis l'extraction de l'image, il est possible que vous ne voyiez pas de journaux pour une image.

Utiliser la commande `ctr` directement sur un nœud

Pour interroger un nœud spécifique afin de renvoyer toutes les images non supprimées extraites en tant que schéma 1, exécutez la commande suivante sur un nœud:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Cette commande peut être utile si, par exemple, vous corrigez un nœud spécifique et que vous ne voyez pas d'entrées de journal dans Cloud Logging, car cela fait plus de 30 jours que l'image a été extraite.

Utiliser l'outil Open Source `crane`

Vous pouvez également utiliser des outils Open Source tels que crane pour vérifier les images.

Exécutez la commande crane suivante pour vérifier la version du schéma d'une image:

crane manifest $tagged_image | jq .schemaVersion

Préparer les charges de travail

Pour préparer les charges de travail qui exécutent des images Docker de schéma 1, vous devez les migrer vers des images Docker de schéma 2 ou des images Open Container Initiative (OCI). Vous pouvez envisager les options de migration suivantes:

Trouver une image de remplacement:vous pouvez peut-être trouver une image Open Source ou fournie par le fournisseur accessible au public.
Convertir l'image existante:si vous ne trouvez pas d'image de remplacement, vous pouvez convertir les images Docker de schéma 1 existantes en images OCI en procédant comme suit :
1. Importez l'image Docker dans containerd, qui la convertit automatiquement en image OCI.
2. Transférez la nouvelle image OCI vers votre registre.

Migrer depuis l'API CRI v1alpha2

L'API CRI v1alpha2 a été supprimée dans Kubernetes 1.26. Vous devez identifier les charges de travail qui accèdent au socket containerd et mettre à jour ces applications pour qu'elles utilisent l'API v1.

Identifier les charges de travail

Vous pouvez utiliser différentes techniques pour identifier les charges de travail à migrer.

Utiliser kubectl

La commande suivante vous aide à trouver les charges de travail qui accèdent au socket containerd. Cette commande renvoie les charges de travail qui montent des répertoires hostPath qui incluent le socket. Cette requête peut générer des faux positifs, car certaines charges de travail installent ces répertoires ou d'autres répertoires enfants, mais n'accèdent pas au socket conteneurisé.

Exécutez la commande suivante :

kubectl get pods --all-namespaces -o json | jq -r '.items[] |
select(.spec.volumes[]? | select(.hostPath.path? and (.hostPath.path |
startswith("/run") or startswith("/var/run") or . == "/"))) |
.metadata.namespace + "/" + .metadata.name'

Vérifier le code de l'application

Vous pouvez vérifier le code de votre application pour voir s'il importe des bibliothèques clientes de l'API CRI v1alpha2.

Par exemple, consultez le code Golang suivant:

  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{})

    ...
  }

Ici, l'application importe la bibliothèque v1alpha2 et l'utilise pour émettre des RPC. Si les RPC utilisent la connexion au socket containerd, cette application entraîne la suspension des mises à niveau automatiques du cluster par GKE.

Pour rechercher et mettre à jour le code de votre application, procédez comme suit:

Identifiez les applications golang problématiques en exécutant la commande suivante pour rechercher le chemin d'importation v1alpha2:
```
  grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
Si la sortie de cette commande indique que la bibliothèque v1alpha2 est utilisée dans le fichier, vous devez le mettre à jour.

Par exemple, remplacez le code d'application suivant:
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
Mettez à jour le code pour qu'il utilise la version 1:
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"
```