Installer des clusters Anthos sur Bare Metal à l'aide d'un miroir de registre

Cette page explique comment installer des clusters Anthos sur Bare Metal à l'aide d'un miroir de registre plutôt que d'utiliser gcr.io. Pour utiliser un miroir de registre, vous devez définir l'environnement d'exécution du conteneur sur containerd.

Les miroirs de registre sont conçus pour mettre en miroir l'intégralité de gcr.io et pas seulement gcr.io/anthos-baremetal-release/, où dess des images des clusters Anthos sur bare metal sont généralement stockées.

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.

Télécharger toutes les images requises pour les clusters Anthos sur solution Bare Metal

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_1.8.0.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.
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 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 :

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

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 création des clusters, consultez la page Créer des clusters.

# 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
---
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
...

Tous les nœuds de ce cluster utiliseront ce miroir de registre 172.18.0.20:5000 au lieu de gcr.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 gcrKeyPath 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.

Si vous n'avez pas besoin de la fonctionnalité de basculement d'extraction, vous n'avez pas besoin d'ajouter gcrKeyPath ni gcr.io à votre liste d'autorisation de proxy.

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

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, le fichier de certificat CA, extrayez le chemin du 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.