Utiliser un miroir de registre pour les images de conteneur

Cette page explique comment créer et mettre à jour des clusters à l'aide d'images extraites d'un miroir de registre, plutôt que d'un registre public, tel que gcr.io. Cette fonctionnalité peut être activée ou désactivée à tout moment du cycle de vie du cluster.

Cette page est destinée aux opérateurs et aux spécialistes du stockage qui configurent et gèrent les performances, l'utilisation et les dépenses liées au stockage. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Un miroir de registre est une copie locale d'un registre public, qui copie ou reflète la structure de fichiers du registre public. Supposons par exemple que le chemin d'accès à votre miroir de registre local soit 172.18.0.20:5000. Lorsque containerd rencontre une requête d'extraction d'image telle que gcr.io/kubernetes-e2e-test-images/nautilus:1.0, containerd tente d'extraire cette image, non pas à partir de gcr.io, mais de votre registre local, au chemin d'accès suivant : 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Si l'image ne figure pas à cet emplacement de registre local, elle est extraite automatiquement du registre public gcr.io.

L'utilisation d'un miroir de registre offre les avantages suivants :

  • Protection contre les indisponibilités de registre public.
  • Accélération de la création de pods.
  • Permet d'effectuer votre propre analyse des failles
  • Évite les limites imposées par les registres publics concernant la fréquence à laquelle vous pouvez leur envoyer des commandes

Avant de commencer

  • Vous devez avoir configuré un serveur de registre de conteneurs sur votre réseau.
  • Si votre serveur de registre exécute un certificat TLS privé, vous devez disposer du fichier de l'autorité de certification.
  • Si votre serveur de registre requiert une authentification, vous devez disposer des identifiants de connexion appropriés ou du fichier de configuration Docker.
  • Pour utiliser un miroir de registre, vous devez définir l'environnement d'exécution du conteneur sur containerd.

Télécharger toutes les images requises pour Google Distributed Cloud

Téléchargez la dernière version de l'outil bmctl et du package d'images depuis la page Télécharger.

Importer des images de conteneurs sur votre serveur de registre

Importez les images du package images sur votre serveur de registre en exécutant la commande suivante :

[HTTPS_PROXY=http://PROXY_IP:PORT] ./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=REGISTRY_IP:PORT \
    [--cacert=CERT_PATH] \
    [--need-credential=false]

Remplacez les éléments suivants :

  • PROXY_IP:PORT par l'adresse IP et le port du proxy si vous avez besoin d'un proxy pour importer les images de votre station de travail vers le serveur de registre.
  • VERSION par la version du package d'images que vous avez téléchargé à la page Téléchargements.
  • REGISTRY_IP:PORT par l'adresse IP et le port du serveur de registre privé.
  • CERT_PATH par le chemin d'accès du fichier de certificat CA si votre serveur de registre utilise un certificat TLS privé.

Saisissez votre nom d'utilisateur et votre mot de passe lorsque vous y êtes invité, ou sélectionnez un fichier de configuration Docker. Si votre serveur de registre ne requiert pas d'identifiants, spécifiez --need-credential=false.

Pour en savoir plus sur la commande bmctl push images, exécutez la commande suivante :

bmctl push images --help

Utiliser votre propre espace de noms

Si vous souhaitez utiliser votre propre espace de noms sur votre serveur de registre au lieu de l'espace de noms racine, containerd peut extraire de cet espace de noms si vous fournissez le point de terminaison de l'API pour votre registre privé dans registryMirrors.endpoint. Le point de terminaison est généralement au format <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Pour en savoir plus, consultez le guide de l'utilisateur de votre registre privé.

Par exemple, si vous n'avez accès qu'à 172.18.0.20:5000/test-namespace/, vous pouvez exécuter la commande suivante pour importer toutes les images sous l'espace de noms test-namespace :

./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace \
    --username=<USERNAME> \
    --password=<PASSWORD> \
    --cacert <path/to/cert.crt>

Ensuite, dans le fichier de configuration du cluster, vous pouvez ajouter ce qui suit pour que containerd effectue l'extraction à partir de l'espace de noms :

registryMirrors:
  - endpoint: https://172.18.0.20:5000/v2/test-namespace

Configurer des clusters pour qu'ils utilisent un miroir de registre

L'exemple de fichier de configuration de cluster suivant spécifie que les images doivent être extraites d'un miroir de registre local dont le point de terminaison est https://172.18.0.20:5000. Certains champs figurant au début de ce fichier de configuration sont décrits dans les sections suivantes.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://172.18.0.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

Champ hosts

containerd vérifie la section hosts du fichier de configuration du cluster pour détecter les hôtes mis en miroir localement. Dans l'exemple de fichier de configuration, les registres publics listés dans la section hosts sont somehost.io et otherhost.io. Étant donné que ces registres publics apparaissent dans la section hosts, containerd vérifie d'abord le miroir de registre privé, lorsqu'il reçoit des demandes d'extraction d'images à partir de somehost.io ou otherhost.io.

Par exemple, supposons que containerd reçoit une commande d'extraction à somehost.io/kubernetes-e2e-test-images/nautilus:1.0. Comme somehost.io est listé comme l'un des hôtes dans la section hosts du fichier de configuration du cluster, containerd recherche l'image kubernetes-e2e-test-images/nautilus:1.0 dans le miroir de registre local. Si somehost.io n'est pas listé dans la section hosts, containerd ne sait pas qu'il existe un miroir local de somehost.io. Dans ce cas, containerd ne recherche pas l'image dans le miroir et l'extrait simplement du registre public somehost.io.

Notez que, par défaut, Google Distributed Cloud met automatiquement en miroir les images de gcr.io. Vous n'avez donc pas besoin de répertorier gcr.io en tant qu'hôte dans la section hosts.

Champ gcrKeyPath

Si vous souhaitez que Google Distributed Cloud utilise automatiquement Container Registry (gcr.io) pour extraire des images qui n'apparaissent pas dans votre registre local, vous devez spécifier le chemin d'accès à la clé du compte de service Container Registry. Google Distributed Cloud ne dispose pas d'un mécanisme permettant de fournir des clés pour d'autres registres publics.

Si vous ne prévoyez pas d'utiliser la fonctionnalité dans laquelle les images sont extraites de gcr.io lorsqu'elles n'apparaissent pas dans votre registre local, vous n'avez pas besoin d'ajouter un élément gcrKeyPath au fichier de configuration du cluster.

Champ caCertPath

Si votre registre nécessite un certificat TLS (Transport Layer Security) privé, ce champ indique le chemin d'accès au fichier de certificat CA racine du serveur. Ce fichier de certificat doit se trouver sur la station de travail de l'administrateur, c'est-à-dire la machine qui exécute les commandes bmctl. Si votre registre ne nécessite pas de certificat TLS privé, vous pouvez laisser le champ caCertPath vide.

Champ pullCredentialConfigPath

Si votre serveur de registre ne nécessite pas de fichier de configuration Docker d'authentification, vous pouvez laisser le champ pullCredentialConfigPath vide. Notez qu'il s'agit du chemin d'accès au fichier de configuration sur la machine qui exécute les commandes bmctl.

Utiliser un miroir de registre avec des clusters d'utilisateurs

Les clusters d'utilisateur n'extraient pas automatiquement les images d'un miroir de registre si leur cluster d'administrateur a été configuré dans cette optique. Pour que les clusters d'utilisateur procèdent à une extraction depuis un miroir de registre, vous devez les configurer individuellement, comme décrit dans la section Configurer des clusters à partir du miroir de registre.

Mettre à jour les points de terminaison, les certificats et les identifiants d'extraction du miroir de registre

Pour mettre à jour les points de terminaison, les certificats ou les identifiants d'extraction du miroir de registre, procédez comme suit :

  1. Dans le fichier de configuration du cluster, mettez à jour le point de terminaison, le fichier de certificat CA et le chemin d'accès au fichier de configuration des identifiants à extraire.

  2. Appliquez les modifications en exécutant la commande suivante :

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Remplacez les éléments suivants :

    • CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.

    • ADMIN_KUBECONFIG par le chemin d'accès de votre fichier de configuration de cluster d'administrateur.

Vérifier que les images sont extraites du miroir de registre

Cette section décrit deux méthodes permettant de vérifier si containerd extrait les images depuis votre miroir de registre local plutôt qu'un registre public.

Méthode 1 : comparer les condensés des dépôts

Cette méthode implique de comparer les condensés des dépôts pour déterminer si une image a été extraite de votre miroir de registre.

N'oubliez pas qu'un registre possède un identifiant unique appelé condensé du dépôt, et qu'une image possède un identifiant unique appelé condensé d'image de conteneur. Deux images identiques ont le même condensé d'image de conteneur, même si elles proviennent de registres différents. Toutefois, si les images proviennent de différents registres, elles vont présenter des condensés de dépôt différents.

  1. Connectez-vous à un nœud de cluster via SSH.

  2. Choisissez une image dont vous souhaitez valider l'origine.

  3. Extrayez l'image du registre public que vous utilisez en exécutant la commande suivante :

    crictl pull PUBLIC_ENDPOINT

    Remplacez PUBLIC_ENDPOINT par le chemin d'accès à l'image dans le registre public. Exemple : gcr.io/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.

  4. Extrayez la même image depuis votre miroir de registre en exécutant la commande suivante :

    crictl pull MIRROR_ENDPOINT

    Remplacez MIRROR_ENDPOINT par le chemin d'accès à l'image dans votre miroir de registre. Exemple : 10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.

  5. Exécutez la commande suivante pour afficher le condensé de dépôt de chacune des deux images que vous avez extraites lors des étapes précédentes :

    crictl inspecti PUBLIC_OR_MIRROR_ENDPOINT | grep -A 3 repoDigests

    Remplacez PUBLIC_OR_MIRROR_ENDPOINT par le point de terminaison public de l'image ou par le point de terminaison du miroir de registre de l'image. L'un ou l'autre est suffisant, car la commande crictl inspecti examine le condensé de l'image de conteneur figurant dans l'argument que vous lui transmettez. Comme l'image du registre public est identique à celle du miroir de registre, elles possèdent le même condensé d'image de conteneur.

    Le résultat de la commande peut se présenter comme suit :

    "repoDigests": [
  "gcr.io/anthos-baremetal-release/kube-rbac-proxy@sha256:
  27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3",
  "10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy@sha256:
  27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3"
],

  6. Comparez les condensés de dépôt qui apparaissent en gras dans le résultat de l'étape précédente. Si ces condensés sont identiques, cela signifie que les nœuds de votre cluster procèdent à une extraction à partir de votre miroir de registre. Sinon, vos nœuds de cluster procèdent à une extraction à partir d'un registre public.

Méthode 2 : examiner le fichier config.toml

Vous pouvez déterminer si containerd extrait des images à partir de votre registre local en examinant le contenu d'un fichier config.toml, comme indiqué dans les étapes suivantes :

  1. Connectez-vous à un nœud et examinez le contenu du fichier suivant : /etc/containerd/config.toml

  2. Examinez la section plugins."io.containerd.grpc.v1.cri".registry.mirrors de ce fichier config.toml pour voir si votre serveur de registre est listé dans le champ endpoint. Voici un extrait d'un exemple de fichier config.toml dans lequel le champ endpoint apparaît en gras :

    version = 2
root = "/var/lib/containerd"
state = "/run/containerd"
...
[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.configs]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
      [plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
        ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
      endpoint = ["http://privateregistry.io", "http://privateregistry2.io"]
...

    Si votre miroir de registre s'affiche dans le champ endpoint, cela signifie que le nœud extrait des images à partir de votre miroir de registre plutôt que d'un registre public.