Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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, consultez Rôles utilisateur et tâches courantes de GKE. Google Cloud

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 dans 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 privateRegistry section au fichier de configuration du cluster d'administrateur avant de créer le cluster.

Lorsque cette section est remplie :
- Lorsque vous exécutez la gkectl prepare commande avant la création ou la mise à niveau du cluster, la commande extrait les images du fichier tar spécifié dans le champ bundlePath du fichier de configuration de votre cluster d'administrateur et les envoie à 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é.
Si votre réseau est protégé par un serveur proxy, remplissez la proxy section.

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: données du certificat CA de la clé publique, mais avec tous les sauts de ligne remplacés par la chaîne \n.
1. Exécutez la commande suivante pour remplacer les sauts de ligne par \n :
```
awk 'ORS="\\n" {print}' PUBLIC_KEY_PATH
```
  Remplacez PUBLIC_KEY_PATH par le chemin d'accès à la clé publique.
2. Copiez le résultat de la commande précédente et collez-le dans la variable d'espace réservé CA_CERT.
Si votre réseau est protégé par un serveur proxy, ajoutez les éléments suivants :
```
proxy {
  url: "PROXY_SERVER_ADDRESS"
  no_proxy: "BYPASS_LIST"
}
```
Remplacez les éléments suivants :
- PROXY_SERVER_ADDRESS: adresse HTTP de votre serveur proxy. Incluez le numéro de port même s'il est identique au port par défaut du schéma.
- BYPASS_LIST: liste d'adresses IP, de plages d'adresses IP, de noms d'hôte et de noms de domaine séparés par une virgule qui ne doivent pas passer par le serveur proxy.
Exemple :
```
url: "http://my-proxy.example.local:80"
no_proxy: "192.0.2.0/24,my-host.example.local,198.51.100.0"
```
Lorsque Google Distributed Cloud envoie une requête à l'un de ces hôtes, domaines ou adresses, la requête contourne le serveur proxy et est envoyée directement à la destination.

Poursuivez 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éez 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é.

Limitations liées aux clusters avancés et au bundle complet

Deux bundles Google Distributed Cloud sont disponibles : complet et standard. Pour déterminer quel bundle se trouve sur votre poste de travail administrateur, consultez 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, la commande 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 le cluster avancé est activé, 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 standard 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 compatible, mais la commande gkectl prepare extrait les images de gcr.io/gke-on-prem-release au lieu du fichier tar. Toutefois, la commande envoie les images à 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 sont en fait extraites de votre serveur de registre privé.
Les extractions d'images utilisent les identifiants du fichier /etc/containerd/config.toml sur chaque machine qui se connecte au registre privé, au lieu du secret private-registry-creds dans le 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 via 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}"
```
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

Le résultat 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 de votre registre local en examinant le contenu d'un fichier nommé 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. Vérifiez le champ plugins."io.containerd.grpc.v1.cri".registry.mirrors du config.toml fichier pour voir si votre serveur de registre est listé dans le endpoint champ.
  
  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.