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 à partir 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, la machine exécutant 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 commandecrictl 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 fichierconfig.toml
pour voir si votre serveur de registre est listé dans le champendpoint
. Voici un extrait d'un exemple de fichierconfig.toml
dans lequel le champendpoint
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.