Images de nœuds containerd


Cette page fournit des informations supplémentaires sur les images de nœuds qui utilisent containerd comme environnement d'exécution de conteneur dans vos nœuds Google Kubernetes Engine (GKE).

À propos de containerd

L'environnement d'exécution des conteneurs est un logiciel qui est chargé d'exécuter des conteneurs et extrait la gestion des conteneurs pour Kubernetes. Il existe plusieurs environnements d'exécution de conteneur. containerd est un environnement d'exécution de conteneur standard, compatible avec Kubernetes et utilisé par de nombreux autres projets. L'environnement d'exécution containerd fournit l'abstraction de la couche qui permet de mettre en œuvre un ensemble riche de fonctionnalités, telles que gVisor, afin d'étendre les fonctionnalités de Kubernetes. Il est considéré comme plus économe en ressources et plus sécurisé que l'environnement d'exécution Docker.

Utiliser les images containerd dans les clusters GKE

Lorsque vous créez un cluster GKE, un nouveau pool de nœuds dans un cluster existant ou lorsque vous mettez à niveau un cluster existant, vous pouvez choisir d'utiliser une image de nœud containerd.

Mode du cluster OS de pools de nœuds Image de nœud
Autopilot Linux cos_containerd
Standard Linux
  • cos_containerd
  • ubuntu_containerd

Ces images nécessitent le nœud GKE version 1.14.3 ou ultérieure.

Standard Windows Server
  • windows_ltsc_containerd
  • windows_sac_containerd

Ces images nécessitent GKE version 1.21.1-gke.2200 ou ultérieure.

Vérifier le type d'image de nœud

Vous pouvez vérifier le type d'image utilisé pour les nœuds existants à l'aide de Google Cloud Console, de l'outil gcloud ou de kubectl. Examinez également l'exemple de script de migration de ce document, qui effectue une itération sur tous les pools de nœuds et renvoie les suggestions de migrations des pools de nœuds.

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez vérifier.

  3. Sélectionnez l'onglet Nœuds.

  4. Dans la section Pools de nœuds, consultez la valeur indiquée dans la colonne Type d'image.

gcloud

Exécutez la commande suivante en remplaçant CLUSTER_NAME par le nom du cluster :

gcloud container node-pools list \
    --cluster CLUSTER_NAME \
    --format="table(name,version,config.imageType)"

Le résultat ressemble à ce qui suit :

NAME          NODE_VERSION    IMAGE_TYPE
default-pool  1.19.6-gke.600  UBUNTU_CONTAINERD

Reportez-vous à la documentation de l'API gcloud container node-pools list pour plus de détails.

kubectl

Exécutez la commande kubectl get nodes suivante :

kubectl get nodes -o wide

Le résultat ressemble à ce qui suit :

# For Docker runtime
NAME         STATUS   VERSION             OS-IMAGE                             CONTAINER-RUNTIME
gke-node-1   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
gke-node-2   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
gke-node-3   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
# For containerd runtime
NAME         STATUS   VERSION           OS-IMAGE                             CONTAINER-RUNTIME
gke-node-1   Ready    v1.19.6-gke.600   Container-Optimized OS from Google   containerd://1.4.1
gke-node-2   Ready    v1.19.6-gke.600   Container-Optimized OS from Google   containerd://1.4.1
gke-node-3   Ready    v1.19.6-gke.600   Container-Optimized OS from Google   containerd://1.4.1

La colonne CONTAINER-RUNTIME génère l'environnement d'exécution et sa version.

Migrer de l'environnement d'exécution Docker vers l'environnement d'exécution containerd

La plupart des charges de travail des utilisateurs n'ont pas de dépendance à l'exécution de conteneur. L'environnement d'exécution du conteneur correspond à ce qui exécute les conteneurs dans vos pods, tandis que l'environnement d'exécution Docker utilise en fait containerd en arrière-plan, de sorte que les deux environnements se comportent de la même manière.

Même si vous utilisez Docker sur votre ordinateur de développement, ou dans un pipeline de compilation qui s'exécute en dehors de votre cluster pour créer et transférer vos images, cela ne constitue pas une dépendance à l'environnement d'exécution Docker (car ces actions ont lieu en dehors du cluster).

Il existe quelques instances dans lesquelles vous pouvez disposer d'une dépendance à Docker : exécuter des pods privilégiés exécutant des commandes Docker, exécuter des scripts sur des nœuds en dehors de l'infrastructure Kubernetes (par exemple, utiliser SSH pour résoudre les problèmes) ou via des outils tiers qui réalisent ces opérations privilégiées. Vous pouvez également disposer d'une dépendance indirecte sur Docker si certains de vos outils ont été configurés pour répondre aux messages de journaux spécifiques à Docker dans votre système de surveillance.

Vous pouvez trouver des informations sur les dépendances potentielles dans l'environnement d'exécution Docker sur la page Migrer depuis dockershim. Pour confirmer la compatibilité avec containerd, vous pouvez également consulter les fournisseurs qui fournissent des outils de journalisation et de surveillance, de sécurité ou d'intégration continue que vous déployez dans votre cluster.

Nous vous recommandons de commencer par déployer votre charge de travail sur un pool de nœuds de test avec containerd afin de vérifier que tout fonctionne comme prévu. Si vous disposez d'un cluster Canary ou de préproduction, nous vous recommandons d'effectuer la migration en premier. Vous pouvez également migrer les nœuds par étapes en suivant l'approche expliquée dans la section Migrer des charges de travail vers différents types de machines.

Mettre à jour vos images de nœuds

Vous pouvez migrer les nœuds d'une image d'exécution Docker vers une image containerd en mettant à jour le pool de nœuds et en définissant une autre image. Cette migration peut être effectuée à l'aide de Google Cloud Console ou de l'outil gcloud.

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.

  4. Sous Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez modifier.

  5. Sur la page Détails du pool de nœuds, cliquez sur Modifier.

  6. Dans la section Nœuds, sous Type d'image, cliquez sur Modifier.

  7. Sélectionnez l'une des variantes d'images containerd correspondant à votre système d'exploitation.

  8. Cliquez sur Modifier.

gcloud

Dans l'outil gcloud, vous pouvez mettre à jour un pool de nœuds à l'aide de la commande gcloud container clusters upgrade et en spécifiant le paramètre --image-type.

Par exemple, pour remplacer l'image d'un pool de nœuds par Container-Optimized OS avec containerd, exécutez la commande suivante :

gcloud container clusters upgrade CLUSTER_NAME --image-type COS_CONTAINERD \
    --node-pool POOL_NAME

Si, après avoir mis à jour votre image de nœud, vous remarquez un problème et devez revenir aux variantes de l'image Docker, vous pouvez exécuter cette même commande, mais sélectionner une variante d'image Docker.

Reportez-vous à la documentation de l'API gcloud container clusters upgrade pour plus de détails.

Exécuter les commandes Docker sur des nœuds containerd

Bien que le binaire Docker soit actuellement disponible sur les nœuds Linux qui utilisent containerd en tant qu'environnement d'exécution, nous ne vous recommandons pas de l'utiliser après la migration vers containerd. Docker ne gère pas les conteneurs exécutés par Kubernetes sur les nœuds containerd. Par conséquent, vous ne pouvez ni l'utiliser pour afficher des conteneurs Kubernetes, ni pour interagir avec eux à l'aide des commandes Docker ou de l'API Docker.

Le binaire Docker n'est pas disponible sur les nœuds Windows Server.

Résoudre les problèmes de conteneurs sur des nœuds containerd

Pour déboguer les nœuds Linux ou résoudre les problèmes associés, vous pouvez interagir avec containerd à l'aide de l'outil de ligne de commande portable crictl conçu pour les environnements d'exécution de conteneurs Kubernetes. crictl offre des fonctionnalités courantes telles que l'affichage des conteneurs et des images, la consultation des journaux et l'exécution de commandes dans les conteneurs. Reportez-vous au guide de l'utilisateur de crictl pour accéder à la liste complète des fonctionnalités compatibles et aux informations d'utilisation.

Pour les nœuds Windows Server, le daemon containerd s'exécute en tant que service Windows nommé containerd. Les journaux sont disponibles dans le répertoire des journaux suivant : C:\etc\kubernetes\logs\containerd.log. Ils s'affichent dans l'explorateur de journaux sous LOG NAME: "container-runtime".

Accéder à Docker Engine à partir de pods privilégiés

Certains utilisateurs accèdent actuellement à Docker Engine sur un nœud à partir de pods privilégiés. Il est recommandé de mettre à jour vos charges de travail afin qu'elles ne dépendent pas directement de Docker. Par exemple, si vous extrayez actuellement les journaux d'applications ou les données de surveillance de Docker Engine, envisagez plutôt d'utiliser des modules complémentaires du système GKE pour la journalisation et la surveillance.

Compiler des images

L'environnement d'exécution containerd n'est pas compatible avec la fonctionnalité de création d'images, car Kubernetes ne l'est pas non plus.

Kubernetes ne connaît pas les ressources système utilisées par les processus locaux en dehors de son champ d'application, et le plan de contrôle de Kubernetes ne peut pas prendre en compte ces processus lors de l'allocation de ressources. Cela peut priver vos charges de travail GKE de ressources ou provoquer une instabilité sur le nœud. C'est pourquoi il n'est pas recommandé d'exécuter des commandes sur les nœuds locaux. Nous vous conseillons plutôt d'effectuer ces tâches à l'aide d'un service extérieur au champ d'application du conteneur individuel, comme Cloud Build, ou d'utiliser un outil tel que kaniko pour compiler des images en tant que charge de travail Kubernetes.

Si aucune de ces suggestions ne vous convient et que vous comprenez les risques, vous pouvez continuer à utiliser Docker pour compiler des images. Vous devez envoyer les images à un registre avant d'essayer de les utiliser dans un cluster GKE. Kubernetes n'a pas connaissance des images compilées localement.

Problèmes connus

Les pods dotés de conteneurs d'initialisation sont bloqués à l'état "En attente" lors de l'initialisation sur les pools de nœuds Windows

Les clusters GKE exécutant des pools de nœuds Windows Server qui utilisent l'environnement d'exécution containerd (version 1.5.2) peuvent rencontrer des problèmes avec les pods contenant initContainers. Le bac à sable se ferme lorsqu'aucun conteneur n'est détecté. Le pod reste donc à l'état Pending.

Versions de GKE concernées : 1.21.4-gke.1801

Les pods affichent le message d'erreur failed to allocate for range 0: no IP addresses available in range set

Versions de GKE concernées: 1.18, 1.19.0 à 1.19.14-gke.1400, 1.20.0 à 1.20.10-gke.1400, 1.21.0 à 1.21.4-gke.1500

Les clusters GKE exécutant des pools de nœuds qui utilisent containerd peuvent rencontrer des problèmes de fuite d'adresses IP et épuiser toutes les adresses IP de pods sur un nœud. Un pod planifié sur un nœud affecté affiche un message d'erreur semblable à celui-ci :

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Pour en savoir plus sur le problème, consultez le problème #5438 et le problème #5768 containerd.

Solutions

Vous pouvez atténuer ce problème à l'aide des solutions suivantes :

  • Utilisez des pools de nœuds basés sur Docker au lieu de containerd.
  • Nettoyez la plage d'adresses IP du pod sur le nœud concerné.

Pour nettoyer la plage d'adresses IP, connectez-vous au nœud concerné et procédez comme suit :

  1. Arrêtez kubelet et containerd :

    systemctl stop kubelet
    systemctl stop containerd
    
  2. Renommez le répertoire /var/lib/cni/networks pour supprimer l'ancienne plage :

    mv /var/lib/cni/networks /var/lib/cni/networks.backups
    
  3. Recréez le répertoire /var/libs/cni/networks :

    mkdir /var/lib/cni/networks
    
  4. Redémarrez containerd et kubelet :

    systemctl start containerd
    systemctl start kubelet
    

Différence de comportement de la vérification d'exécution en cas d'expiration du délai avant expiration

Versions de GKE concernées : toutes

Le comportement de la vérification d'exécution sur les images containerd est différent du comportement sur les images dockershim. Lorsqu'une vérification d'exécution définie pour le pod dépasse le seuil déclaré timeoutSeconds sur les images dockershim, elle est traitée comme un échec de vérification. Sur les images containerd, les résultats de vérification renvoyés après le seuil timeoutSeconds déclaré sont ignorés.

Incohérences dans les métriques d'image

Versions de GKE concernées : toutes

Les métriques d'image container_fs_usage_bytes et container_tasks_state n'affichent pas de libellés tels que image, container_name et namespace. En outre, certaines métriques d'image (avec le préfixe container_fs) sont manquantes lors de l'utilisation de containerd.

containerd ignore tous les mappages d'appareils pour les pods privilégiés

Versions de GKE concernées : toutes

Pour les pods privilégiés, l'environnement d'exécution du conteneur ignore les mappages d'appareils que volumeDevices.devicePath lui a transmis et place tous les appareils de l'hôte à la disposition du conteneur sous /dev.

La famille d'adresses IPv6 est activée sur les pods exécutant containerd

Versions de GKE concernées : 1.18, 1.19, 1.20.0 à 1.20.9

La famille d'images IPv6 est activée pour les pods exécutés avec containerd. L'image dockershim désactive IPv6 sur tous les pods, contrairement à l'image containerd. Par exemple, localhost résout d'abord l'adresse IPv6 ::1. Cela ne pose généralement pas de problème, mais peut cependant entraîner un comportement inattendu.

Actuellement, la solution consiste à utiliser explicitement une adresse IPv4 telle que 127.0.0.1, ou à configurer une application s'exécutant dans le pod pour qu'elle fonctionne sur les deux familles d'adresses.

Le provisionnement automatique des nœuds ne provisionne que des pools de nœuds Docker sur Container-Optimized OS.

Versions de GKE concernées : 1.18, 1.19, 1.20.0 à 1.20.6-gke.1800

Le provisionnement automatique des nœuds permet d'effectuer l'autoscaling des pools de nœuds avec n'importe quel type d'image accepté. Cependant, vous ne pouvez créer de nouveaux pools de nœuds qu'avec le type d'image Container-Optimized OS avec Docker.

À partir de la version de GKE 1.20.6-gke.1800 et ultérieure, le type d'image par défaut peut être défini pour le cluster.

Conflit avec la plage d'adresses IP 172.17/16

Versions de GKE concernées : 1.18.0, à 1.18.14

La plage d'adresses IP 172.17/16 est occupée par l'interface docker0 de la VM de nœud compatible avec containerd. Le trafic en provenance ou à destination de cette plage peut ne pas être correctement routé (par exemple, un pod peut ne pas être en mesure de se connecter à un hôte connecté VPN avec une adresse IP comprise dans la plage 172.17/16).

Métriques du GPU non collectées

Versions de GKE concernées : 1.18.0 à 1.18.18

Les métriques d'utilisation du GPU ne sont pas collectées lors de l'utilisation de containerd comme environnement d'exécution sur des versions de GKE antérieures à 1.18.18.

Impossible d'utiliser des images dont le paramètre config.mediaType est défini sur application/octet-stream sur des conteneurs

Versions de nœuds GKE concernées : toutes

Impossible d'utiliser des images dont le paramètre config.mediaType est défini sur "application/octet-stream" sur des conteneurs Consultez la page https://github.com/containerd/containerd/issues/4756. Ces images ne sont pas compatibles avec la spécification Open Container Initiative et sont considérées comme incorrectes. Ces images fonctionnent avec Docker pour assurer la rétrocompatibilité, tandis qu'elles ne sont pas compatibles avec containerd.

Problème constaté et diagnostics

Exemple d'erreur dans les journaux de nœuds :

Error syncing pod <pod-uid> ("<pod-name>_<namespace>(<pod-uid>)"), skipping: failed to "StartContainer" for "<container-name>" with CreateContainerError: "failed to create containerd container: error unpacking image: failed to extract layer sha256:<some id>: failed to get reader from content store: content digest sha256:<some id>: not found"

Le fichier manifeste de l'image se trouve généralement dans le registre où il est hébergé. Une fois que vous disposez du fichier manifeste, examinez config.mediaType pour déterminer si vous rencontrez ce problème :

"mediaType": "application/octet-stream",

Corriger

Comme la communauté de containerd a décidé de ne pas accepter de telles images, toutes les versions de containerd sont affectées et il n'existe pas de correctif. L'image du conteneur doit être recréée avec Docker version 1.11 ou ultérieure et vous devez vous assurer que le champ config.mediaType n'est pas défini sur "application/octet-stream".

Exemple de script de migration

L'exemple de script suivant parcourt tous les pools de nœuds de l'ensemble des projets disponibles et, pour chaque pool de nœuds, génère une suggestion indiquant si le pool de nœuds doit être migré vers containerd. Ce script génère également la version du pool de nœuds et la commande de migration suggérée, comme indiqué dans la section Mettre à jour vos images de nœud. Assurez-vous d'examiner les problèmes connus d'une version de pool de nœuds.

Exemple de script : itération sur tous les pools de nœuds pour la migration containerd

for project in  $(gcloud projects list --format="value(projectId)")
do
  echo "ProjectId:  $project"
  for clusters in $( \
    gcloud container clusters list \
      --project $project \
      --format="csv[no-heading](name,location,autopilot.enabled,currentMasterVersion,autoscaling.enableNodeAutoprovisioning,autoscaling.autoprovisioningNodePoolDefaults.imageType)")
  do
    IFS=',' read -r -a clustersArray <<< "$clusters"
    cluster_name="${clustersArray[0]}"
    cluster_zone="${clustersArray[1]}"
    cluster_isAutopilot="${clustersArray[2]}"
    cluster_version="${clustersArray[3]}"
    cluster_minorVersion=${cluster_version:0:4}
    cluster_autoprovisioning="${clustersArray[4]}"
    cluster_autoprovisioningImageType="${clustersArray[5]}"

    if [ "$cluster_isAutopilot" = "True" ]; then
      echo "  Cluster: $cluster_name (autopilot) (zone: $cluster_zone)"
      echo "    Autopilot clusters are running Containerd."
    else
      echo "  Cluster: $cluster_name (zone: $cluster_zone)"

      if [ "$cluster_autoprovisioning" = "True" ]; then
        if [ "$cluster_minorVersion"  \< "1.20" ]; then
          echo "    Node autoprovisioning is enabled, and new node pools will have image type 'COS'."
          echo "    This settings is not configurable on the current version of a cluster."
          echo "    Please upgrade you cluster and configure the default node autoprovisioning image type."
          echo "    "
        else
          if [ "$cluster_autoprovisioningImageType" = "COS" ]; then
            echo "    Node autoprovisioning is configured to create new node pools of type 'COS'."
            echo "    Run the following command to update:"
            echo "    gcloud container clusters update '$cluster_name' --project '$project' --zone '$cluster_zone' --enable-autoprovisioning --autoprovisioning-image-type='COS_CONTAINERD'"
            echo "    "
          fi

          if [ "$cluster_autoprovisioningImageType" = "UBUNTU" ]; then
            echo "    Node autoprovisioning is configured to create new node pools of type 'UBUNTU'."
            echo "    Run the following command to update:"
            echo "    gcloud container clusters update '$cluster_name' --project '$project' --zone '$cluster_zone' --enable-autoprovisioning --autoprovisioning-image-type='UBUNTU_CONTAINERD'"
            echo "    "
          fi
        fi
      fi

      for nodepools in $( \
        gcloud container node-pools list \
          --project $project \
          --cluster $cluster_name \
          --zone $cluster_zone \
          --format="csv[no-heading](name,version,config.imageType)")
      do
        IFS=',' read -r -a nodepoolsArray <<< "$nodepools"
        nodepool_name="${nodepoolsArray[0]}"
        nodepool_version="${nodepoolsArray[1]}"
        nodepool_imageType="${nodepoolsArray[2]}"

        nodepool_minorVersion=${nodepool_version:0:4}

        echo "    Nodepool: $nodepool_name, version: $nodepool_version ($nodepool_minorVersion), image: $nodepool_imageType"

        minorVersionWithRev="${nodepool_version/-gke./.}"
        linuxGkeMinVersion="1.14"
        windowsGkeMinVersion="1.21.1.2200"

        suggestedImageType="COS_CONTAINERD"

        if [ "$nodepool_imageType" = "UBUNTU" ]; then
          suggestedImageType="UBUNTU_CONTAINERD"
        elif [ "$nodepool_imageType" = "WINDOWS_LTSC" ]; then
          suggestedImageType="WINDOWS_LTSC_CONTAINERD"
        elif [ "$nodepool_imageType" = "WINDOWS_SAC" ]; then
          suggestedImageType="WINDOWS_SAC_CONTAINERD"
        fi

        tab=$'\n      ';
        nodepool_message="$tab Please update the nodepool to use Containerd."
        nodepool_message+="$tab Make sure to consult with the list of known issues https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd#known_issues."
        nodepool_message+="$tab Run the following command to upgrade:"
        nodepool_message+="$tab "
        nodepool_message+="$tab gcloud container clusters upgrade '$cluster_name' --project '$project' --zone '$cluster_zone' --image-type '$suggestedImageType' --node-pool '$nodepool_name'"
        nodepool_message+="$tab "

        # see https://cloud.google.com/kubernetes-engine/docs/concepts/node-images
        if [ "$nodepool_imageType" = "COS_CONTAINERD" ] || [ "$nodepool_imageType" = "UBUNTU_CONTAINERD" ] ||
           [ "$nodepool_imageType" = "WINDOWS_LTSC_CONTAINERD" ] || [ "$nodepool_imageType" = "WINDOWS_SAC_CONTAINERD" ]; then
          nodepool_message="$tab Nodepool is using Containerd already"
        elif ( [ "$nodepool_imageType" = "WINDOWS_LTSC" ] || [ "$nodepool_imageType" = "WINDOWS_SAC" ] ) &&
               !( [ "$(printf '%s\n' "$windowsGkeMinVersion" "$minorVersionWithRev" | sort -V | head -n1)" = "$windowsGkeMinVersion" ] ); then
          nodepool_message="$tab Upgrade nodepool to the version that supports Containerd for Windows"
        elif !( [ "$(printf '%s\n' "$linuxGkeMinVersion" "$minorVersionWithRev" | sort -V | head -n1)" = "$linuxGkeMinVersion" ] ); then
          nodepool_message="$tab Upgrade nodepool to the version that supports Containerd"
        fi
        echo "$nodepool_message"
      done
    fi # not autopilot
  done
done

# Sample output:
#
# ProjectId:  my-project-id
#  Cluster: autopilot-cluster-1 (autopilot) (zone: us-central1)
#    Autopilot clusters are running Containerd.
#  Cluster: cluster-1 (zone: us-central1-c)
#    Nodepool: default-pool, version: 1.18.12-gke.1210 (1.18), image: COS
#
#       Please update the nodepool to use Containerd.
#       Make sure to consult with the list of known issues https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd#known_issues.
#       Run the following command to upgrade:
#
#       gcloud container clusters upgrade 'cluster-1' --project 'my-project-id' --zone 'us-central1-c' --image-type 'COS_CONTAINERD' --node-pool 'default-pool'
#
#    Nodepool: pool-1, version: 1.18.12-gke.1210 (1.18), image: COS
#
#       Please update the nodepool to use Containerd.
#       Make sure to consult with the list of known issues https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd#known_issues.
#       Run the following command to upgrade:
#
#       gcloud container clusters upgrade 'cluster-1' --project 'my-project-id' --zone 'us-central1-c' --image-type 'COS_CONTAINERD' --node-pool 'pool-1'
#
#    Nodepool: winpool, version: 1.18.12-gke.1210 (1.18), image: WINDOWS_SAC
#
#       Upgrade nodepool to the version that supports Containerd for Windows
#
#  Cluster: another-test-cluster (zone: us-central1-c)
#    Nodepool: default-pool, version: 1.20.4-gke.400 (1.20), image: COS_CONTAINERD
#
#      Nodepool is using Containerd already
#

Étapes suivantes

  • Pour en savoir plus sur l'intégration de containerd, consultez l'annonce concernant Kubernetes 1.11. Pour des explications encore plus détaillées, consultez la documentation concernant containerd et les plug-ins CRI.
  • Examinez la migration à partir des informations de Dockershim sur kubernetes.io.
  • Documentez-vous sur l'abandon de DockerShim par Kubernetes.
  • Découvrez comment sécuriser vos applications avec gVisor sur containerd.
  • Découvrez les avantages de l'utilisation de Cloud Build pour créer des images de manière sécurisée et fiable sur Google Cloud en vue de remplacer une solution personnalisée nécessitant l'utilisation de Docker.