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

Configurer un registre de conteneurs privé

Cette page explique comment configurer un serveur de registre de conteneurs existant pour Google Distributed Cloud (logiciel uniquement) pour VMware.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui configurent, surveillent et gèrent l'infrastructure technologique. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Présentation

Par défaut, lors de la création ou de la mise à niveau d'un cluster, Google Distributed Cloud extrait les images système de gcr.io/gke-on-prem-release à l'aide du compte de service d'accès aux composants. Vous pouvez également fournir votre propre serveur de registre de conteneurs afin que les images système soient extraites de votre serveur de registre privé.

Google Distributed Cloud n'est pas compatible avec les registres de conteneurs non sécurisés. Lorsque vous démarrez votre serveur de registre de conteneurs, vous devez fournir un certificat et une clé. Le certificat peut être signé par une autorité de certification publique ou il peut être autosigné.

Créer un serveur de registre de conteneurs

Pour savoir comment créer un serveur de registre de conteneurs, consultez la section Run an externally-accessible registry (Exécuter un registre accessible en externe) de la documentation Docker.

Configurer le registre

Pour utiliser un registre de conteneurs privé, vous pouvez utiliser l'outil de ligne de commande gkectl ou Terraform.

`gkectl`

Ajoutez la section privateRegistry au fichier de configuration du cluster d'administrateur avant de créer le cluster.

Lorsque cette section est remplie :

Lorsque vous exécutez la commande gkectl prepare avant la création ou la mise à niveau du cluster, elle extrait les images du fichier tar spécifié dans le champ bundlePath du fichier de configuration de votre cluster d'administrateur et les transfère vers votre serveur de registre privé.
Lors de la création ou de la mise à niveau du cluster, les images système sont extraites de votre serveur de registre privé.

Terraform

Suivez les étapes de l'onglet "Terraform" de la section Créer un cluster d'administrateur pour remplir le fichier de configuration de votre cluster d'administrateur.
Ajoutez les éléments suivants au fichier de configuration du cluster d'administrateur :
```
private_registry_config {
  address = "ADDRESS"
  ca_cert = "CA_CERT"
}
```
Remplacez les éléments suivants :
- "ADDRESS" : adresse IP ou nom de domaine complet de la machine qui exécute votre registre privé.
- "CA_CERT" : clé publique du certificat de l'autorité de certification pour le registre privé.
Suivez les étapes de l'onglet "Terraform" de la section Créer un cluster d'administrateur pour vérifier le fichier de configuration et le plan Terraform, puis créer le cluster d'amorçage.
Lorsque vous exécutez la commande gkectl register bootstrap, gkectl vous invite à saisir le nom d'utilisateur, puis le mot de passe du registre privé.

Lors de la création du cluster, les images système sont extraites de votre serveur de registre privé.

Limites avec les clusters avancés et le bundle complet

Deux bundles Google Distributed Cloud sont disponibles : complet et standard. Pour déterminer le bundle installé sur votre poste de travail administrateur, vérifiez le champ bundlePath dans le fichier de configuration de votre cluster d'administrateur. Si le nom de fichier se termine par -full, le bundle complet se trouve sur votre poste de travail administrateur. Si le nom de fichier ne se termine pas par -full, le bundle standard se trouve sur votre poste de travail administrateur.

Si vous avez créé votre poste de travail administrateur à l'aide de la commande gkeadm, celle-ci crée la VM du poste de travail administrateur avec le bundle complet et configure le champ bundlePath dans le fichier de configuration du cluster d'administrateur.

Si l'option de cluster avancé est activée, l'utilisation du bundle complet avec un registre privé est limitée comme suit :

Version 1.31 : le bundle complet n'est pas compatible avec un registre privé. Pour utiliser un registre privé sur un cluster avancé :
1. Téléchargez le bundle de taille normale sur votre poste de travail administrateur.
2. Mettez à jour le nom de fichier dans le champ bundlePath du fichier de configuration du cluster d'administrateur.
Version 1.32 : l'utilisation du bundle complet est prise en charge, mais la commande gkectl prepare extrait les images de gcr.io/gke-on-prem-release au lieu du fichier tar. Toutefois, la commande transfère les images vers votre registre privé afin que les images système soient extraites de votre registre privé lors de la création ou de la mise à niveau du cluster.

Différences entre les clusters normaux et les clusters avancés

Le cluster avancé présente plusieurs différences clés par rapport aux clusters standards :

Lorsque vous utilisez un registre privé, les images semblent être extraites de gcr.io, et non du nom d'hôte de votre registre privé. Ce changement est normal, même si les images proviennent en fait de votre serveur de registre privé.
Les extractions d'images utilisent les identifiants du fichier /etc/containerd/config.toml de chaque machine qui se connecte au registre privé, au lieu du secret private-registry-creds à l'intérieur du cluster.
Pour toutes les images gcr.io, le cluster tente d'abord d'effectuer l'extraction à partir du registre privé. Si l'image ne se trouve pas dans le registre privé, le système l'extrait de gcr.io sur Internet. Pour arrêter ce basculement, configurez noProxy ou utilisez des règles de pare-feu pour bloquer le trafic gcr.io.

Pour vérifier que les images sont extraites de la source appropriée, consultez Vérifier que les images sont extraites de votre serveur de registre.

Vérifier que les images sont extraites de votre serveur de registre

La façon dont vous vérifiez que les images sont extraites de votre serveur de registre dépend de l'activation ou non du cluster avancé.

Si le cluster avancé n'est pas activé, exécutez la commande suivante :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}"
```
ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

La sortie de cette commande affiche toutes les images de votre cluster. Vous pouvez vérifier que toutes les images Google Distributed Cloud proviennent de votre propre serveur de registre.
Si le cluster avancé est activé, procédez comme suit :

Vous pouvez déterminer si containerd extrait des images à partir de votre registre local en examinant le contenu d'un fichier appelé config.toml, comme indiqué dans les étapes suivantes :
1. Connectez-vous à un nœud et examinez le contenu du fichier /etc/containerd/config.toml.
2. Examinez le champ plugins."io.containerd.grpc.v1.cri".registry.mirrors du 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.
```
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"]
...
```
3. 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'Artifact Registry.

Configurer un registre de conteneurs privé Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.