Les clusters Anthos sur bare metal sont désormais appelés Google Distributed Cloud (logiciel uniquement) pour bare metal. Pour en savoir plus, consultez la présentation du produit.

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

Utiliser un miroir de registre pour créer des clusters

Cette page explique comment créer des clusters à l'aide d'images extraites d'un miroir de registre, plutôt que d'un registre public, tel que gcr.io.

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

Créer des clusters à partir du 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 (pull) à 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 les 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 d'aucun 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 le poste de travail administrateur, celui 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 exécutant les commandes bmctl.

Créer un cluster d'utilisateur depuis le miroir de registre

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 Créer 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 :

Dans le fichier de configuration du cluster, mettez à jour le point de terminaison et le fichier de certificat CA, puis extrayez le chemin d'accès au fichier de configuration des identifiants.
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 au fichier de configuration de son 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.

Connectez-vous à un nœud de cluster via SSH.
Choisissez une image dont vous souhaitez valider l'origine.
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.
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.
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 pourrait ressembler à ceci :
```
 "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"
 ],
```
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 :

Connectez-vous à un nœud et examinez le contenu du fichier suivant : /etc/containerd/config.toml
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.