Configurer les miroirs de registre

Miroir de registre

Les miroirs de registre sont conçus pour mettre en miroir les images de gcr.io et docker.io. Par exemple, si vous essayez d'extraire une image gcr.io/kubernetes-e2e-test-images/nautilus:1.0, cela ne fonctionne que si votre service de registre utilise cette image dans le même chemin d'accès, par exemple 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Toutes les images autres que gcr.io fonctionnent toujours normalement. Par exemple, vous pouvez toujours extraire k8s.gcr.io/pause:3.1.

L'utilisation d'un miroir de registre permet de réduire le trafic et offre une alternative à l'utilisation de gcr.io au cas où vous auriez besoin d'isoler vos clusters des interruptions gcr.io. Cela vous permet également de procéder à votre propre analyse des failles.

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.

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 :

actl images push \
    --private-registry=PRIVATE_REGISTRY \
    --images ~/anthos-baremetal-private-mode

Remplacez les éléments suivants :

  • PRIVATE_REGISTRY par l'adresse de registre privée (et le port) et le sous-projet, par exemple 172.18.0.20:5000/test-namespace.

  • 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 --no-registry-credential.

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

actl images push --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 ce sous-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 :

actl images push \
    --images= ~/anthos-baremetal-private-mode \
    --private-registry=172.18.0.20:5000/test-namespace

Ensuite, dans le fichier YAML du cluster, vous pouvez saisir les éléments suivants pour que containerd extrait le sous-espace de noms :

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

Créer des clusters à partir du miroir de registre

Vous trouverez ci-dessous un exemple de fichier de configuration de cluster utilisant votre propre serveur de miroir de registre au lieu de gcr.io.

Si votre registre ne nécessite pas de certificat TLS privé, vous pouvez laisser le champ caCertPath vide.

Si votre serveur de registre ne nécessite pas de fichier de configuration Docker d'authentification, vous pouvez laisser le champ pullCredentialConfigPath vide.

Pour en savoir plus sur la configuration du cluster, consultez la page Configuration du cluster.

# Sample cluster config with registry mirror:
---
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://172.18.0.20:5000/v2/test-namespace
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin
  namespace: cluster-admin
spec:
  nodeConfig:
    containerRuntime: containerd
...

Tous les nœuds de ce cluster utiliseront le miroir de registre 172.18.0.20:5000 au lieu de gcr.io (et docker.io).

Basculer vers gcr.io

Si votre cluster ne parvient pas à extraire des données du miroir de registre, il bascule automatiquement vers gcr.io. C'est pourquoi nous vous recommandons de fournir une valeur pour privateRegistryConfigPath dans le fichier de configuration du cluster. Si aucune valeur n'est fournie, votre cluster ne peut pas extraire de gcr.io en cas d'échec du miroir de registre.

# Sample cluster config with registry mirror:
---
privateRegistryConfigPath: /root/.docker/config.json
registryMirrors:
  - endpoint: https://172.18.0.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json

Si vous n'avez pas besoin de la fonctionnalité de basculement d'extraction, vous n'avez pas besoin d'ajouter privateRegistryConfigPath ou gcr.io (et docker.io) à votre liste d'autorisation de proxys.

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 et le fichier de certificat CA, puis extrayez le chemin d'accès au fichier de configuration des identifiants.

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

    actl clusters baremetal update cluster admin --kubeconfig=ADMIN_KUBECONFIG

Étapes suivantes