Configuration d'un registre d'images

Configuration du secret d'extraction d'image par défaut

Généralement, votre cluster IBM Cloud Kubernetes Service est configuré pour extraire des images de tous les domaines IBM Cloud Container Registry icr.io depuis l'espace de noms Kubernetes default uniquement. Consultez la Questions fréquemment posées suivante pour en savoir plus sur la façon d'extraire des images dans d'autres espaces de noms ou comptes Kubernetes, de restreindre l'accès à l'extraction, ou pour savoir pourquoi votre cluster n'a pas les secrets d'extraction d'images par défaut.

Comment mon cluster est-il configuré pour extraire des images de l'espace de noms default Kubernetes?

Lorsque vous créez un cluster, il dispose d'un ID de service IBM Cloud IAM associé à une règle de rôle d'accès au service Lecteur IAM dans IBM Cloud Container Registry. Les données d'identification de l'ID de service sont représentées dans une clé d'API qui n'expire jamais et qui est stockée dans des secrets d'extraction d'image dans votre cluster. Ces secrets sont ajoutés dans l'espace de noms Kubernetes default et la liste de ces secrets dans le compte de service default correspondant à cet espace de noms Kubernetes. En utilisant des secrets d'extraction d'image, vos déploiements peuvent extraire des images (avec accès en lecture seule) depuis votre IBM Cloud Container Registry global et régional pour déployer des conteneurs dans l'espace de noms Kubernetes default.

• Le registre global stocke de manière sécurisée des images publiques fournies par IBM. Vous pouvez vous référer à ces images publiques dans vos déploiements au lieu d'utiliser des références différentes pour les images stockées dans chaque registre régional.
• Le registre régional stocke vos propres images Docker privées de manière sécurisée.

Que se passe-t-il si je n'ai pas de secrets de tirage d'image dans l'espace de noms default Kubernetes?

Vous pouvez rechercher les secrets d'extraction d'image en vous connectant à votre cluster et en exécutant la commande kubectl get secrets -n default | grep "icr-io". Si aucun secret icr n'est répertorié, la personne qui a créé le cluster n'avait peut-être pas les droits requis sur IBM Cloud Container Registry dans IAM. Voir Mise à jour de clusters existants pour utiliser le secret d'extraction d'image de la clé d'API.

Puis-je restreindre l'accès au tirage à un certain registre régional?

Oui, vous pouvez éditer la règle IAM existante de l'ID de service qui limite le rôle d'accès au service Lecteur à ce registre régional ou à une ressource de registre, comme par exemple, un espace de noms. Avant de personnaliser des règles IAM de registre, vous devez activer les règles IBM Cloud IAM pour IBM Cloud Container Registry.

Vous souhaitez renforcer la protection de vos données d'identification de registre ? Demandez à l'administrateur de votre cluster d'activer un fournisseur de service de gestion des clés (KMS) dans votre cluster pour chiffrer les secrets Kubernetes qui s'y trouvent, tels que le secret d'extraction d'image qui stocke les données d'identification de votre registre.

Puis-je extraire des images dans un espace de noms Kubernetes autre que default?

Par défaut, non. Avec la configuration de cluster par défaut, vous pouvez déployer des conteneurs depuis n'importe quelle image qui est stockée dans votre espace de noms IBM Cloud Container Registry dans l'espace de noms Kubernetes default de votre cluster. Pour utiliser ces images dans d'autres espaces de noms Kubernetes ou d'autres comptes IBM Cloud, vous pouvez copier ou créer vos propres secrets d'extraction d'image.

Puis-je extraire des images d'un autre compte IBM Cloud?

Oui, créez une clé d'API dans le compte IBM Cloud que vous souhaitez utiliser. Ensuite, dans chaque espace de noms de chaque cluster dont vous souhaitez extraire des images du compte IBM Cloud, créez un secret qui contient la clé d'API. Pour plus d'informations, suivez cet exemple qui utilise une clé d'API d'ID de service autorisé.

Pour utiliser un registre non IBM Cloud, tel que Docker, voir Accès aux images stockées dans d'autres registres privés.

La clé API doit-elle correspondre à un identifiant de service? Que se passe-t-il si j'atteins la limite d'identifiants de service pour mon compte?

La configuration de cluster par défaut crée un ID de service pour stocker les données d'identification de clé d'API IBM Cloud IAM dans le secret d'extraction d'image. Cependant, vous pouvez également créer une clé d'API pour un utilisateur individuel et stocker ces données d'identification dans un secret d'extraction d'image. Si vous parvenez à la limite IAM pour les ID de service, votre cluster est créé sans l'ID de service et le secret d'extraction de l'image et ne peut pas extraire les images des domaines de registre icr.io par défaut. Vous devez créer votre propre secret d'extraction d'image, mais en utilisant une clé d'API pour un utilisateur individuel, tel qu'un ID fonctionnel, pas un ID de service IBM Cloud IAM.

Je vois des secrets de tirage d'image pour les domaines de registre régionaux et tous les domaines de registre. Lequel dois-je utiliser?

Auparavant, IBM Cloud Kubernetes Service créait des secrets d'extraction d'image distincts pour chaque domaine de registre icr.io public régional. A présent, tous les domaines de registre icr.io publics et privés pour toutes les régions sont stockés dans un seul et même secret d'extraction d'image all-icr-io qui est automatiquement créé dans l'espace de noms Kubernetes default de votre cluster.

Pour que les charges de travail des autres espaces de noms Kubernetes du cluster puissent extraire des images de conteneur à partir d'un registre privé, vous pouvez désormais copier uniquement le secret d'extraction d'image all-icr-io dans cet espace de noms Kubernetes. Indiquez ensuite le secret all-icr-io dans votre déploiement ou votre compte de service. Vous n'avez plus besoin de copier le secret d'image qui correspond au registre régional de votre image. De plus, notez que vous n'avez pas besoin de secrets d'extraction d'images pour les registres publics qui ne nécessitent pas d'authentification.

Une fois que j'ai copié ou créé une image pull secret dans un autre espace de noms Kubernetes, ai-je terminé?

Pas tout à fait. Vos conteneurs doivent être autorisés à extraire des images à l'aide du secret que vous avez créé. Vous pouvez ajouter le secret d'extraction d'image au compte de service pour l'espace de noms ou faire référence au secret dans chaque déploiement. Pour obtenir des instructions, voir Utilisation de secret d'extraction d'image pour déployer des conteneurs.

Connexion de réseau privé à des registres icr.io

Lorsque vous configurez votre compte IBM Cloud pour utiliser des noeuds finaux de service, vous pouvez utiliser une connexion de réseau privé pour envoyer et extraire des images vers et depuis IBM Cloud Container Registry.

Que dois-je faire pour configurer mon cluster afin qu'il utilise la connexion privée pour icr.io registries?

1. Activez une fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud de manière à pouvoir utiliser le noeud final de service cloud privé IBM Cloud Container Registry. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show.
2. Activez votre compte IBM Cloud pour utiliser des noeuds finaux de service.

IBM Cloud Container Registry utilise automatiquement le point de terminaison du service de cloud privé. Vous devez activer le nœud final de service de cloud privé pour vos clusters IBM Cloud Kubernetes Service.

Mise à jour de votre secret d'extraction d'image

Pour mettre à jour le secret d'extraction d'image de votre cluster dans l'espace de noms Kubernetes default Kubernetes.

1. Obtenez l'ID de votre cluster.

   ibmcloud ks cluster ls
   

2. Exécutez la commande ci-après afin de créer un ID de service pour le cluster et affecter à l'ID de service un rôle d'accès au service IAM Lecteur pour IBM Cloud Container Registry. La commande permet également de créer une clé d'API pour représenter les données d'identification de l'ID de service et de stocker la clé d'API dans un secret d'extraction d'image Kubernetes dans le cluster. Ce secret d'extraction d'image se trouve dans l'espace de noms Kubernetes default.

   ibmcloud ks cluster pull-secret apply --cluster <cluster_name_or_ID>
   

   Lorsque vous exécutez cette commande, la création de données d'identification IAM et de secrets d'extraction d'image est initiée et peut durer un certain temps. Vous ne pouvez pas déployer de conteneurs qui extraient une image des domaines IBM Cloud Container Registry icr.io jusqu'à ce que les secrets d'extraction d'image soient créés.

3. Vérifiez que les secrets d'extraction d'image sont créés dans votre cluster.

   kubectl get secrets | grep icr-io
   

   Exemple de sortie

   all-icr-io           kubernetes.io/dockerconfigjson        1         16d
   

4. Mettez à jour vos déploiements de conteneur pour extraire des images à partir du nom de domaine icr.io.

5. Facultatif : Si vous disposez d'un pare-feu, assurez-vous que vous autorisez le trafic réseau sortant vers les sous-réseaux du registre pour les domaines que vous utilisez.

6. Effectuez la configuration à l'aide de l'une des options suivantes.

   • Pour extraire des images dans d'autres espaces de noms Kubernetes que default ou à partir d'autres comptes IBM Cloud, copiez ou créez un autre secret d'extraction d'image.
   • Pour limiter l'accès du secret d'extraction d'image à des ressources de registre particulières, par exemple des espaces de noms ou des régions :
     1. Vérifiez que les règles IBM Cloud IAM pour IBM Cloud Container Registry sont activées.
     2. Editez les règles IBM Cloud IAM pour l'ID de service, ou créez un autre secret d'extraction d'image.

Copie d'un secret d'extraction d'image

Vous pouvez copier un secret d'extraction d'image, tel que celui qui est créé automatiquement pour l'espace de noms Kubernetes default dans d'autres espaces de noms de votre cluster. Si vous souhaitez utiliser d'autres données d'identification de clé d'API IBM Cloud IAM pour cet espace de noms, par exemple, pour limiter l'accès à certains espaces de noms ou pour extraire des images d'autres comptes IBM Cloud, créez un secret d'extraction d'image à la place.

1. Répertoriez les espaces de noms Kubernetes disponibles dans votre cluster ou créez un espace de noms à utiliser.

   kubectl get namespaces
   

   Exemple de sortie

   default          Active    79d
   ibm-cert-store   Active    79d
   ibm-system       Active    79d
   kube-public      Active    79d
   kube-system      Active    79d
   

   Pour créer un espace de noms :

   kubectl create namespace <namespace_name>
   

2. Répertoriez les secrets d'extraction d'image dans les espaces de noms Kubernetes default pour IBM Cloud Container Registry.

   kubectl get secrets -n default | grep icr-io
   

   Exemple de sortie

   all-icr-io          kubernetes.io/dockerconfigjson        1         16d
   

3. Copiez le secret d'extraction d'image all-icr-io depuis l'espace de noms default vers l'espace de noms de votre choix. Les nouveaux secrets d'extraction d'image sont nommés <namespace_name>-icr-<region>-io.

   kubectl get secret all-icr-io -n default -o yaml | sed 's/default/<new-namespace>/g' | kubectl create -n <new-namespace> -f -   
   

4. Vérifiez que la création des secrets a abouti.

   kubectl get secrets -n <namespace_name> | grep icr-io
   

5. Pour déployer des conteneurs, ajoutez le secret d'exraction d'image à chaque déploiement ou au compte de service de l'espace de noms de sorte que n'importe quel déploiement de l'espace de noms puisse extraire des images du registre.

Création d'un secret d'extraction d'image avec des données d'identification de clé d'API IAM différentes

Vous pouvez affecter des règles d'accès IBM Cloud IAM à des utilisateurs ou à un ID de service pour limiter les droits à des espaces de noms d'images de registre ou des actions (telles que push ou pull) spécifiques. Ensuite, créez une clé d'API et stockez ces données d'identification de registre dans un secret d'extraction d'image pour votre cluster.

Par exemple, pour accéder à des images dans d'autres comptes IBM Cloud, créez une clé d'API qui stocke les données d'identification IBM Cloud Container Registry d'un utilisateur ou d'un ID de service dans ce compte. Ensuite, dans le compte de votre cluster, sauvegardez les données d'identification de la clé d'API dans un secret d'extraction d'image pour chaque cluster et espace de noms de cluster.

La procédure suivante permet de créer une clé d'API qui stocke les données d'identification d'un ID de service IBM Cloud IAM. Au lieu d'utiliser un ID de service, vous envisagerez peut-être de créer une clé d'API pour un ID utilisateur disposant d'une règle d'accès au service IBM Cloud IAM pour IBM Cloud Container Registry. Cependant, assurez-vous que l'utilisateur correspond à un ID fonctionnel ou dispose d'un plan au cas où il partirait, afin que le cluster puisse toujours accéder au registre.

1. Répertoriez les espaces de noms Kubernetes disponibles dans votre cluster ou créez un espace de noms à utiliser pour y déployer les conteneurs à partir de vos images de registre.

   kubectl get namespaces
   

   Exemple de sortie

   default          Active    79d
   ibm-cert-store   Active    79d
   ibm-system       Active    79d
   kube-public      Active    79d
   kube-system      Active    79d
   

   Pour créer un espace de noms :

   kubectl create namespace <namespace_name>
   

2. Créez un ID de service IBM Cloud IAM pour votre cluster qui sera utilisé pour les règles IAM et les données d'identification de clé d'API dans le secret d'extraction d'image. Veillez à attribuer à l'ID de service une description vous permettant de le retrouver par la suite, par exemple en y incluant le nom du cluster et de l'espace de noms.

   ibmcloud iam service-id-create <cluster_name>-<namespace>-id --description "Service ID for IBM Cloud Container Registry in Kubernetes cluster <cluster_name> namespace <namespace>"
   

3. Créez une règle IBM Cloud IAM personnalisée pour l'ID de service de votre cluster qui autorise l'accès à IBM Cloud Container Registry.

   ibmcloud iam service-policy-create <cluster_service_ID> --roles <service_access_role> --service-name container-registry [--region <IAM_region>] [--resource-type namespace --resource <registry_namespace>]
   

   cluster_service_ID

   Obligatoire. Remplacez par l'ID service <cluster_name>-<kube_namespace>-id que vous avez créé précédemment pour votre cluster Kubernetes.

   --service-name container-registry

   Obligatoire. Entrez container-registry pour que la règle IAM s'applique à IBM Cloud Container Registry.

   --roles <service_access_role>

   Obligatoire. Entrez le rôle d'accès au service pour IBM Cloud Container Registry auquel vous souhaitez définir la portée d'accès de l'ID de service. Les valeurs possibles sont Reader, Writer et Manager.

   --region <IAM_region>

   Optionnel. Pour définir la portée de la règle d'accès à certaines régions IAM, entrez les régions dans une liste en les séparant par des virgules. Les valeurs possibles sont global et les régions de registre local.

   --resource-type namespace --resource <registry_namespace>

   Optionnel. Si vous souhaitez limiter l'accès aux seules images dans certains espaces de nom IBM Cloud Container Registry, entrez namespace pour le type de ressource et indiquez <registry_namespace>. Pour répertorier les espaces de noms du registre, exécutez la commande ibmcloud cr namespaces.

4. Créez une clé d'API pour l'ID de service. Nommez la clé API de la même manière que votre identifiant de service et incluez l'identifiant de service que vous avez créé précédemment, <cluster_name>-<kube_namespace>-id. Veillez à indiquer une description pour la clé d'API pour vous aider à la retrouver par la suite.

   ibmcloud iam service-api-key-create <cluster_name>-<namespace>-key <cluster_name>-<namespace>-id --description "API key for service ID <service_id> in Kubernetes cluster <cluster_name> namespace <namespace>"
   

5. Récupérez la valeur de votre clé d'API dans la sortie de la commande précédente.

   Please preserve the API key! It can't be retrieved after it's created.
   
   Name          <cluster_name>-<kube_namespace>-key   
   Description   key_for_registry_for_serviceid_for_kubernetes_cluster_multizone_namespace_test   
   Bound To      crn:v1:bluemix:public:iam-identity::a/1bb222bb2b33333ddd3d3333ee4ee444::serviceid:ServiceId-ff55555f-5fff-6666-g6g6-777777h7h7hh   
   Created At    2019-02-01T19:06+0000   
   API Key       i-8i88ii8jjjj9jjj99kkkkkkkkk_k9-llllll11mmm1   
   Locked        false   
   UUID          ApiKey-222nn2n2-o3o3-3o3o-4p44-oo444o44o4o4   
   

6. Créez un secret d'extraction d'image pour stocker les données d'identification de la clé d'API dans l'espace de noms du cluster. Répétez cette étape pour chaque espace de noms de chaque cluster pour chaque domaine icr.io duquel vous souhaitez extraire des images.

   kubectl --namespace <namespace> create secret docker-registry <secret_name> --docker-server=<registry_URL> --docker-username=iamapikey --docker-password=<api_key_value> --docker-email=<docker_email>
   

   --namespace <namespace>

   Obligatoire. Spécifiez l'espace de noms Kubernetes de votre cluster que vous avez utilisé pour le nom d'ID de service.

   <secret_name>

   Obligatoire. Entrez le nom de votre secret d'extraction d'image.

   --docker-server <registry_URL>

   Obligatoire. Définissez l'URL d'accès au registre d'images dans lequel est configuré votre espace de noms de registre. Pour les domaines disponibles, voir Régions locales.

   --docker-username iamapikey

   Obligatoire. Entrez le nom d'utilisateur pour vous connecter à votre registre privé. Si vous utilisez IBM Cloud Container Registry, entrez iamapikey.

   --docker-password <token_value>

   Obligatoire. Entrez la valeur de votre API Key que vous avez récupérée précédemment.

   --docker-email <docker-email>

   Obligatoire. Si vous en avez une, entrez votre adresse e-mail Docker. Dans le cas contraire, entrez une adresse e-mail fictive, telle que a@b.c. Cette adresse e-mail est obligatoire pour créer un secret Kubernetes, mais n'est plus utilisée une fois la valeur créée.

7. Vérifiez que la création du secret a abouti. Remplacez<namespace> par le fichiernamespace où vous avez créé le secret d'extraction de l'image.

   kubectl get secrets --namespace <namespace>
   

8. Ajoutez un secret d'extraction d'image à un compte de service Kubernetes pour qu'un pod de l'espace de noms puisse utiliser ce secret lorsque vous déployez un conteneur.

Accès aux images stockées dans d'autres registres privés

Si vous disposez déjà d'un registre privé, vous devez stocker les données d'identification du registre dans un secret d'extraction d'image Kubernetes et référencez ce secret dans votre fichier de configuration.

Avant de commencer :

1. Créez un cluster.
2. Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Pour créer un secret d'extraction d'image :

1. Créez le secret Kubernetes pour stocker vos données d'identification de registre privé.

   kubectl --namespace <namespace> create secret docker-registry <secret_name>  --docker-server=<registry_URL> --docker-username=<docker_username> --docker-password=<docker_password> --docker-email=<docker_email>
   

   --namespace <namespace>

   Obligatoire. Espace de noms Kubernetes de votre cluster dans lequel vous désirez utiliser le secret et déployer des conteneurs. Pour afficher la liste des espaces de noms disponibles dans votre cluster, exécutez la commande kubectl get namespaces.

   <secret_name>

   Obligatoire. Nom que vous désirez utiliser comme secret d'extraction d'image.

   --docker-server <registry_URL>

   Obligatoire. URL du registre dans lequel sont stockées vos images privées.

   --docker-username <docker_username>

   Obligatoire. Nom d'utilisateur pour vous connecter à votre registre privé.

   --docker-password <token_value>

   Obligatoire. Mot de passe pour vous connecter à votre registre privé, par exemple, une valeur de jeton.

   --docker-email <docker-email>

   Obligatoire. Si vous en avez une, entrez votre adresse e-mail Docker. Si vous n'en avez pas, entrez une adresse e-mail fictive, telle que a@b.c. Cette adresse e-mail est obligatoire pour créer un secret Kubernetes, mais n'est plus utilisée une fois la valeur créée.

2. Vérifiez que la création du secret a abouti. Remplacez <namespace> par le nom de l'espace de nom dans lequel vous avez créé le secret d'extraction d'image.

   kubectl get secrets --namespace <namespace>
   

3. Créez un pod faisant référence au secret d'extraction d'image.

Stocker un secret d'extraction d'image dans le compte de service Kubernetes pour l'espace de noms sélectionné

Tous les espaces de noms Kubernetes ont un compte de service Kubernetes nommé default. Dans l'espace de noms, vous pouvez ajouter le secret d'extraction d'image à ce compte de service pour octroyer l'accès aux pods afin d'extraire des images de votre registre. Les déploiements qui ne spécifient pas de compte de service utilisent automatiquement le compte de service default pour cet espace de nom Kubernetes.

1. Vérifiez s'il existe déjà un secret d'extraction d'image pour le compte de service default.

   kubectl describe serviceaccount default -n <namespace_name>
   

   Lorsque <none> est affiché dans l'entrée des secrets d'extraction d'image, aucun secret d'extraction d'image n'existe.

2. Ajoutez le secret d'extraction d'image dans le compte de service default.

   • Exemple de commande permettant d'ajouter le secret d'extraction d'image lorsqu'aucun secret d'extraction d'image n'est défini.

     kubectl patch -n <namespace_name> serviceaccount/default -p '{"imagePullSecrets":[{"name": "<image_pull_secret_name>"}]}'
     

   • Exemple de commande permettant d'ajouter le secret d'extraction d'image lorsqu'un secret d'extraction d'image est déjà défini.

     kubectl patch -n <namespace_name> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"<image_pull_secret_name>"}}]'
     

3. Assurez-vous que le secret d'extraction d'image a été ajouté dans le compte de service default.

   kubectl describe serviceaccount default -n <namespace_name>
   

   Exemple de sortie

   Name:                default
   Namespace:           <namespace_name>
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  <image_pull_secret_name>
   Mountable secrets:   default-token-sh2dx
   Tokens:              default-token-sh2dx
   Events:              <none>
   

   Si les secrets d'extraction d'image dit <secret> (not found), vérifiez que le secret d'extraction d'image existe dans le même espace de nom que votre compte de service en exécutant kubectl get secrets -n namespace.

4. Créez un fichier de configuration de pod nommé mypod.yaml pour déployer un conteneur à partir d'une image dans votre registre.

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
       - name: mypod-container
         image: <region>.icr.io/<namespace>/<image>:<tag>
   

5. Créez le pod dans le cluster en appliquant le fichier de configuration mypod.yaml.

   kubectl apply -f mypod.yaml
   

Exemple de définition de démon pour mettre à jour une configuration de registre personnalisé conteneurisée

Utilisez l'exemple de fichier YAML pour définir une définition de démon qui s'exécute sur tous les nœuds worker pour définir ou mettre à jour une configuration d'hôte de registre conteneurisée et monter sur le chemin de registre conteneurisé correspondant.

L'exemple définit la configuration d'hôte de registre suivante pour dockerhub. Cette configuration d'hôte de registre est déjà fournie et configurée automatiquement lors de la phase d'application des accès des nœuds worker. Le conteneur init initialise hosts.toml sur chaque nœud de travail après le déploiement et après le rechargement ou le redémarrage des nœuds de travail.

server = "https://docker.io"
[host."https://registry-1.docker.io"]
capabilities = ["pull", "resolve"]

Exemple de fichier YAML:

apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
    name: containerd-dockerhub-registry-config
name: containerd-dockerhub-registry-config
namespace: kube-system
spec:
selector:
    matchLabels:
    name: containerd-dockerhub-registry-config
template:
    metadata:
    labels:
        name: containerd-dockerhub-registry-config
    spec:
    initContainers:
    - image: alpine:3.13.6
        name: containerd-dockerhub-registry-config
        command:
        - /bin/sh
        - -c
        - |
            #!/bin/sh
            set -uo pipefail
            cat << EOF > /etc/containerd/certs.d/docker.io/hosts.toml
            server = "https://docker.io"
            [host."https://registry-1.docker.io"]
            capabilities = ["pull", "resolve"]
            EOF
        volumeMounts:
        - mountPath: /etc/containerd/certs.d/docker.io/
        name: dockerhub-registry-config
    containers:
    - name: pause
        image: "us.icr.io/armada-master/pause:3.5"
        imagePullPolicy: IfNotPresent
    volumes:
    - name: dockerhub-registry-config
        hostPath:
        path: /etc/containerd/certs.d/docker.io/

Pour plus d'informations sur la mise à jour d'une configuration d'hôte de registre containerd, voir la documentation containerd.