Migrer des nœuds vers containerd 2

Les clusters Google Kubernetes Engine (GKE) utilisent des images de nœud containerd node images avec tous les nœuds de calcul qui exécutent la version 1.24 ou ultérieure. Les nœuds de calcul utilisent une version spécifique de containerd, en fonction du système d'exploitation et de la version mineure de GKE :

  • Nœuds Container-Optimized OS et Ubuntu (Linux):
    • Les nœuds Linux qui exécutent GKE 1.32 ou une version antérieure, avec des images de nœud containerd, utilisent containerd 1.7 ou des versions antérieures.
    • Les nœuds Linux qui exécutent GKE 1.33 utilisent containerd 2.0.
  • Nœuds Windows Server:
    • Les nœuds Windows Server qui exécutent GKE 1.34 ou une version antérieure, avec des images de nœud containerd, utilisent containerd 1.7 ou des versions antérieures.
    • Les nœuds Windows Server qui exécutent GKE 1.35 utilisent containerd 2.0.

Lorsque les nœuds GKE sont mis à niveau vers la version mineure GKE correspondante, ils migrent de containerd 1.7 vers 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.

Transition de GKE vers containerd 2

Consultez la chronologie suivante pour comprendre comment GKE fait passer les clusters existants à containerd 2 :

  • Pour les nœuds Linux avec la version 1.32 et les nœuds Windows Server avec la version 1.34, GKE utilise containerd 1.7. containerd 1.7 a rendu obsolètes 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 antérieures, consultez la section Propriétés de configuration obsolètes.
  • Pour les nœuds Linux avec la version 1.33 et les nœuds Windows Server avec la version 1.35, GKE utilise containerd 2.0, qui supprime la compatibilité avec les images Docker de schéma 1 et 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.4 ou une version ultérieure, avec une version GKE qui n'a pas encore été annoncée : registry.auths, registry.configs, registry.mirrors. Toutefois, registry.configs.tls a déjà été supprimée dans containerd 2.0.

Pour connaître le calendrier approximatif des mises à niveau automatiques vers des versions mineures ultérieures, 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 de différentes manières, en fonction de la version mineure actuelle du cluster et du type de nœuds (Linux ou Windows Server).

Mises à niveau automatiques suspendues pour les nœuds Linux

GKE suspend les mises à niveau automatiques vers la version 1.33 pour les clusters avec des nœuds Linux lorsqu'il détecte que le cluster utilise les fonctionnalités obsolètes. Toutefois, si les nœuds de votre cluster utilisent ces fonctionnalités, nous vous recommandons de créer une exclusion de maintenance pour empêcher les mises à niveau du cluster. L'exclusion de maintenance garantit que votre cluster n'est pas mis à niveau si GKE ne détecte pas d'utilisation.

Une fois que vous avez migré depuis ces fonctionnalités, GKE reprend les mises à niveau mineures automatiques vers la version 1.33 si les conditions suivantes sont remplies :

  • GKE n'a pas détecté d'utilisation de fonctionnalités obsolètes depuis 14 jours, ou 3 jours pour les propriétés registry.configs obsolètes de CRI.
  • La version 1.33 est une cible de mise à niveau automatique pour votre cluster.
  • Il n'existe aucun autre facteur bloquant. Pour en savoir plus, consultez la section Calendrier des mises à niveau automatiques.

Vous pouvez également mettre à niveau le cluster manuellement.

Mises à niveau automatiques suspendues pour les nœuds Windows Server

GKE suspend les mises à niveau automatiques vers la version 1.35 pour tous les clusters avec des nœuds Windows Server, que le cluster utilise ou non les fonctionnalités obsolètes. GKE ne peut pas détecter si les nœuds Windows Server utilisent les fonctionnalités obsolètes.

Pour mettre à niveau votre cluster avec des nœuds Windows Server vers la version 1.35, suivez d'abord les instructions de la section Migrer depuis des fonctionnalités obsolètes. Une fois ces instructions suivies, vous pouvez mettre à niveau manuellement le cluster vers la version 1.35.

Fin de la compatibilité et impact du non-respect de la préparation de la migration

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

Si vous ne migrez pas depuis ces fonctionnalités, lorsque la version 1.32 (pour les nœuds Linux) ou 1.34 (pour les nœuds Windows Server) arrive en fin de compatibilité et que les nœuds de votre cluster sont automatiquement mis à niveau vers la version 1.33 ou 1.35, vous pouvez rencontrer les problèmes suivants avec vos clusters :

  • Les charges de travail utilisant des images Docker de schéma 1 échouent.
  • Les applications appelant l'API CRI v1alpha2 rencontrent des échecs lors de l'appel de l'API.

Identifier les clusters concernés

GKE surveille vos clusters et utilise le service Recommender pour fournir des conseils via des insights et des recommandations permettant d'identifier les nœuds Linux de votre cluster qui utilisent ces fonctionnalités obsolètes. GKE ne détecte pas l'utilisation à partir des nœuds Windows Server.

Exigences concernant les versions

Les clusters reçoivent ces insights et recommandations s'ils exécutent les versions suivantes ou ultérieures :

  • 1.28.15-gke.1159000
  • 1.29.9-gke.1541000
  • 1.30.5-gke.1355000
  • 1.31.1-gke.1621000

Obtenir des insights et des recommandations

Suivez les instructions pour afficher des insights et des recommandations. Vous pouvez obtenir des insights à l'aide de la Cloud de Confiance console. Vous pouvez également utiliser la Google Cloud CLI ou l'API Recommender en filtrant avec les sous-types suivants :

  • DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: images Docker de schéma 1
  • DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: API CRI v1alpha2
  • DEPRECATION_CONTAINERD_V2_CONFIG_REGISTRY_CONFIGS : propriétés obsolètes de CRI registry.configs, y compris registry.configs.auth et registry.configs.tls

Migrer depuis des fonctionnalités obsolètes

Consultez le contenu suivant pour comprendre comment migrer depuis les fonctionnalités obsolètes avec containerd 2.

Migrer depuis des images Docker de schéma 1

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

gcr.io/google-containers/startup-script est une image fournie par Google qui est concernée par ce problème.

  • gcr.io/google-containers/startup-script:v1: utilise le format de schéma 1 obsolète et ne peut pas être extrait sur GKE 1.33 et versions ultérieures pour les nœuds Linux.
  • gcr.io/google-containers/startup-script:v2: utilise le format de schéma 2 compatible et peut être extrait correctement.

Si vous utilisez gcr.io/google-containers/startup-script:v1 dans l'une de vos charges de travail (telles que des DaemonSets ou des déploiements), vous devez mettre à jour la référence d'image vers gcr.io/google-containers/startup-script:v2.

Identifier les images à migrer

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

Utiliser des insights et des recommandations ou Cloud Logging

Comme expliqué dans la section Identifier les clusters concernés, vous pouvez utiliser des insights et des recommandations pour identifier les clusters avec des nœuds Linux qui utilisent des images Docker de schéma 1 si votre cluster exécute une version minimale ou ultérieure. De plus, vous pouvez utiliser la requête suivante dans Cloud Logging pour vérifier les journaux containerd afin de trouver des images Docker de schéma 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, vous ne verrez peut-être pas les journaux d'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 qui ont été 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 résolvez les problèmes d'un nœud spécifique et que vous ne voyez pas d'entrées de journal dans Cloud Logging, car plus de 30 jours se sont écoulés depuis l'extraction de l'image.

Utiliser l'outil Open Source crane

Vous pouvez également utiliser des outils Open Source tels que crane pour rechercher des 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 OCI (Open Container Initiative). Tenez compte des options de migration suivantes :

  • Rechercher une image de remplacement : vous pourrez peut-être trouver une image Open Source ou fournie par un fournisseur disponible publiquement.
  • 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. Extrayez 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 potentiellement concernées

Vous pouvez utiliser différentes techniques pour identifier les charges de travail qui peuvent nécessiter une migration. Ces techniques peuvent générer des faux positifs que vous devez examiner plus en détail pour déterminer qu'aucune action n'est nécessaire.

Utiliser des insights et des recommandations

Vous pouvez utiliser des insights et des recommandations pour identifier les clusters avec des nœuds Linux qui utilisent l'API v1alpha2 si votre cluster exécute une version minimale ou ultérieure. Pour en savoir plus, consultez la section Identifier les clusters concernés.

Lorsque vous affichez des insights dans la Cloud de Confiance console, consultez le panneau latéral Migrer vos charges de travail depuis l'API CRI v1alpha2 obsolète. Le tableau Charges de travail à vérifier de ce panneau liste les charges de travail susceptibles d'être concernées. Cette liste inclut toutes les charges de travail qui ne sont pas gérées par GKE et qui comportent des volumes hostPath contenant le chemin d'accès au socket containerd (par exemple, /var/run/containerd/containerd.sock ou /run/containerd/containerd.sock).

Il est important de comprendre les points suivants :

  • La liste des charges de travail à vérifier peut contenir des faux positifs. Utilisez-la uniquement pour l'investigation. Une charge de travail qui apparaît dans cette liste ne signifie pas nécessairement qu'elle utilise l'API obsolète, et la présence d'un faux positif ne suspendra pas les mises à niveau automatiques. La suspension n'est basée que sur l'utilisation réellement observée de l'API obsolète.
  • Cette liste peut être vide ou incomplète. Une liste vide ou incomplète peut se produire si les charges de travail qui utilisent l'API obsolète ont été de courte durée et ne s'exécutaient pas lorsque GKE a effectué sa vérification périodique. La présence de la recommandation elle-même signifie que l'utilisation de l'API CRI v1alpha2 a été détectée sur au moins un nœud de votre cluster. Les mises à niveau automatiques reprennent après que l'utilisation de l'API obsolète n'a pas été détectée pendant 14 jours.

Par conséquent, nous vous recommandons d'effectuer des investigations supplémentaires à l'aide des méthodes suivantes pour confirmer l'utilisation réelle de l'API.

Rechercher les charges de travail tierces concernées

Pour les logiciels tiers déployés sur vos clusters, vérifiez que ces charges de travail n'utilisent pas l'API CRI v1alpha2. Vous devrez peut-être contacter les fournisseurs respectifs pour vérifier les versions de leurs logiciels qui sont compatibles.

Utiliser kubectl

La commande suivante vous aide à identifier les charges de travail potentiellement concernées en recherchant celles qui accèdent au socket containerd. Elle utilise une logique semblable à celle utilisée pour le tableau Charges de travail à vérifier dans la recommandation de la Cloud de Confiance console. Elle renvoie les charges de travail non gérées par GKE qui comportent des volumes hostPath incluant le chemin d'accès au socket. Comme la recommandation, cette requête peut renvoyer des faux positifs ou manquer des charges de travail de courte durée.

Exécutez la commande suivante :

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/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"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'
Utiliser le traçage eBPF pour identifier les appelants d'API

Pour identifier de manière plus définitive les charges de travail qui s'exécutent sur des nœuds Linux et qui appellent l'API CRI v1alpha2, vous pouvez déployer deux DaemonSets spécialisés :

  • Le containerd-socket-tracer enregistre tout processus ouvrant une connexion au containerd socket, ainsi que les détails du pod et du conteneur.
  • cri-v1alpha2-api-deprecation-reporter enregistre la dernière fois que l'API CRI v1alpha2 a été appelée.

Ces outils utilisent eBPF (Extended Berkeley Packet Filter) pour suivre les connexions au containerd socket et les corréler avec les appels d'API obsolètes réels.

Vous ne pouvez pas déployer ces DaemonSets sur des nœuds Windows Server.

En corrélant les codes temporels de ces deux outils, vous pouvez identifier la charge de travail exacte qui effectue l'appel d'API obsolète. Cette méthode offre un degré de confiance plus élevé que la simple vérification des volumes hostPath, car elle observe les connexions de socket réelles et l'utilisation de l'API.

Pour obtenir des instructions détaillées sur le déploiement et l'utilisation de ces outils, ainsi que sur l'interprétation de leurs journaux, consultez la section Suivre les connexions de socket containerd.

Si, après avoir utilisé ces outils, vous ne parvenez toujours pas à identifier la source des appels d'API obsolètes, mais que la recommandation reste active, consultez la section Obtenir de l'aide.

Une fois que vous avez identifié une charge de travail qui utilise l'API CRI v1alpha2, soit par les méthodes précédentes, soit en inspectant votre base de code, vous devez mettre à jour son code pour qu'il utilise l'API v1.

Mettre à jour le code de l'application

Pour mettre à jour votre application, supprimez l'endroit où l'application importe la k8s.io/cri-api/pkg/apis/runtime/v1alpha2 bibliothèque cliente et modifiez le code pour qu'il utilise la v1 version de l'API. Cette étape implique de modifier le chemin d'importation et la façon dont votre code appelle l'API.

Par exemple, consultez le code golang suivant, qui utilise la bibliothèque obsolète :

  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.

Procédez comme suit pour rechercher et mettre à jour le code de votre application :

  1. 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 le résultat de cette commande indique que la bibliothèque v1alpha2 est utilisée dans le fichier, vous devez mettre à jour le fichier.

    Par exemple, remplacez le code d'application suivant :

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

  2. Mettez à jour le code pour qu'il utilise la version v1 :

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"

Migrer depuis des propriétés de configuration containerd obsolètes

Les propriétés de configuration containerd registry.auths, registry.configs et registry.mirrors du plug-in CRI sont obsolètes et seront supprimées dans containerd 2.4 ou une version ultérieure, avec une version GKE qui n'a pas encore été annoncée. Toutefois, registry.configs.tls a déjà été supprimée dans containerd 2.0.

Identifier les charges de travail

Vous pouvez utiliser différentes techniques pour identifier les charges de travail qui doivent être migrées.

Utiliser des insights et des recommandations

Dans une première approche, vous pouvez utiliser des insights et des recommandations pour identifier les clusters avec des nœuds Linux qui utilisent les propriétés de configuration containerd obsolètes. Cela nécessite une version minimale de GKE. Pour en savoir plus sur cette approche, consultez la section Identifier les clusters concernés.

Lorsque vous affichez des insights dans la Cloud de Confiance console, consultez le panneau latéral Migrer votre configuration containerd depuis le champ des authentifications obsolète du registre CRI ou Migrer votre configuration containerd depuis le champ des duplications obsolète du registre CRI. Pour identifier les charges de travail susceptibles d'accéder à la configuration containerd, consultez la section Charges de travail à vérifier.

Utiliser kubectl

Vous pouvez également utiliser kubectl pour identifier les charges de travail.

Recherchez les charges de travail qui modifient la configuration containerd en vérifiant les charges de travail présentant les attributs suivants :

  • Charges de travail contenant un volume hostPath incluant la configuration containerd
  • Charges de travail comportant un conteneur avec un accès privilégié (spec.containers.securityContext.privileged: true) et utilisant l'espace de noms de l'ID de processus (PID) de l'hôte (spec.hostPID: true)

Cette commande peut renvoyer des faux positifs, car la charge de travail peut accéder à d'autres fichiers de ces répertoires qui ne sont pas la configuration containerd. Cette commande peut également ne pas renvoyer les charges de travail qui accèdent au fichier de configuration containerd d'autres manières moins courantes.

Exécutez la commande suivante pour vérifier les DaemonSets :

kubectl get daemonsets --all-namespaces -o json | \
jq -r '
  [
    "/", "/etc", "/etc/",
    "/etc/containerd", "/etc/containerd/",
    "/etc/containerd/config.toml"
  ] as $host_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
    and
    (
      (any(.spec.template.spec.volumes[]?.hostPath.path; IN($host_paths[])))
      or
      (
        .spec.template.spec.hostPID == true and
        any(.spec.template.spec.containers[]; .securityContext?.privileged == true)
      )
    )
  ) |
  .metadata.namespace + "/" + .metadata.name
'

Migrer depuis les propriétés auths ou configs.auth du registre CRI

Si vos charges de travail utilisent les propriétés auths ou configs.auth dans la configuration containerd pour s'authentifier auprès d'un registre privé afin d'extraire des images de conteneurs, vous devez migrer les charges de travail qui utilisent ces images vers le champ imagePullSecrets. Pour en savoir plus, consultez la section Extraire une image d'un registre privé.

Pour identifier et migrer les charges de travail qui utilisent les propriétés auths ou configs.auth obsolètes, consultez les instructions suivantes.

Identifier les informations d'authentification de votre registre

Vous pouvez identifier les informations d'authentification de votre registre de l'une des manières suivantes :

  • Examinez les sections auths et configs.auth du registre CRI dans le fichier /etc/containerd/config.toml en vous connectant à un nœud GKE.
  • Recherchez la charge de travail qui modifie votre fichier de configuration containerd et consultez les informations d'authentification incluses à l'aide des méthodes décrites précédemment pour identifier les charges de travail. GKE n'utilise pas ces paramètres pour ses charges de travail système.

Si vous utilisez la propriété registry.configs.auth, les informations d'authentification peuvent se présenter comme suit :

  [plugins."io.containerd.grpc.v1.cri".registry.configs."$REGISTRY_DOMAIN".auth]
    username = "example-user"
    password = "example-password"

Collectez ces informations d'authentification pour chaque domaine de registre spécifié dans votre configuration.

Mettre à jour votre charge de travail pour qu'elle utilise le champ imagePullSecrets
  1. Créez un secret avec vos informations d'authentification de la section précédente en suivant les instructions pour extraire une image d'un registre privé.

  2. Identifiez les charges de travail qui doivent être migrées vers le champ imagePullSecrets en exécutant la commande suivante :

    kubectl get pods -A -o json |
jq -r ".items[] |
  select(.spec.containers[] |
        .image | startswith(\"$REGISTRY_DOMAIN\")) |
  .metadata.namespace + \"/\" + .metadata.name"

    Vous devez créer un secret pour chaque espace de noms utilisé par les charges de travail avec des images provenant de ce domaine de registre.

  3. Mettez à jour vos charges de travail pour qu'elles utilisent le champ imagePullSecrets avec les secrets que vous avez créés à l'étape précédente.

    Si vous devez migrer un grand nombre de charges de travail, vous pouvez également implémenter un MutatingAdmissionWebhook pour ajouter le champ imagePullSecrets.

Mettre à jour votre configuration containerd pour arrêter de définir les authentifications de registre

Une fois que vous avez migré vos charges de travail pour qu'elles utilisent le champ imagePullSecrets, vous devez mettre à jour les charges de travail qui modifient votre configuration containerd pour arrêter de définir les authentifications de registre. Pour toutes les charges de travail que vous avez identifiées comme modifiant la configuration, modifiez-les pour qu'elles arrêtent de définir les authentifications de registre.

Tester avec un nouveau pool de nœuds et migrer les charges de travail vers le nouveau pool de nœuds

Pour réduire le risque de problèmes avec vos charges de travail, procédez comme suit :

  1. Créer un pool de nœuds.
  2. Planifiez la charge de travail mise à jour qui modifie votre configuration containerd sur les nœuds du nouveau pool de nœuds.
  3. Migrez vos charges de travail restantes vers le nouveau pool de nœuds en suivant les instructions de la section Migrer des charges de travail entre des pools de nœuds.

Migrer depuis la propriété configs.tls du registre CRI

Si vos charges de travail utilisent la propriété registry.configs.tls, vous devez les migrer pour accéder aux registres privés avec des certificats CA privés.

Suivez les instructions pour migrer depuis des DaemonSets de configuration. Ce processus se déroule en plusieurs étapes :

  1. Mettez à jour vos charges de travail qui modifient la configuration containerd pour arrêter de définir les détails TLS.
  2. Stockez les certificats dans Secret Manager.
  3. Créez un fichier de configuration d'exécution qui pointe vers vos certificats.
  4. Créez un pool de nœuds et vérifiez que vos charges de travail qui utilisent des images hébergées à partir du registre privé fonctionnent comme prévu.
  5. Appliquez la configuration à un nouveau cluster et commencez à exécuter les charges de travail sur ce cluster, ou appliquez la configuration au cluster existant. L'application de la configuration au cluster existant peut potentiellement perturber d'autres charges de travail existantes. Pour en savoir plus sur ces deux approches, consultez la section Créer un fichier de configuration d'exécution.

Une fois la migration effectuée, assurez-vous d'arrêter d'appliquer des modifications à votre champ registry.configs, sinon vous risquez de rencontrer des problèmes avec containerd.

Obtenir de l'aide

Si vous ne parvenez toujours pas à déterminer la source des appels d'API obsolètes et que les recommandations restent actives, envisagez l'étape suivante :