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 la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Présentation

Par défaut, lors de la création ou de la mise à niveau d'un cluster, Google Distributed Cloud extrait des images système à partir de gcr.io/gke-on-prem-release à l'aide du compte de service d'accès aux composants. Vous pouvez éventuellement 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) dans la documentation Docker.

Configurer le Registre

Pour utiliser un registre de conteneurs privé, remplissez la section privateRegistry du fichier de configuration du cluster d'administrateur avant de créer le cluster. Lorsque cette section est renseignée:

  • 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 de votre fichier de configuration du cluster d'administrateur, puis 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é.

Limites concernant les clusters avancés et le bundle complet

Deux bundles Google Distributed Cloud sont disponibles: le bundle complet et le bundle standard. Pour déterminer le bundle qui se trouve sur votre poste de travail administrateur, vérifiez le champ bundlePath dans le fichier de configuration du cluster d'administrateur. Si le nom de fichier se termine par -full, le groupe 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, elle crée la VM de 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 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.

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

La procédure de vérification 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. Vérifiez dans le champ plugins."io.containerd.grpc.v1.cri".registry.mirrors du fichier config.toml 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 qu'à partir d'Artifact Registry.