Créer des instances de registre Harbor

Utilisez le service Managed Harbor Service (MHS) de Google Distributed Cloud (GDC) avec isolation physique pour créer une instance de registre Harbor dans chaque projet. Une instance de registre Harbor sert de dépôt central pour stocker et gérer des images de conteneurs dans un environnement cloud natif. Il étend les capacités de la distribution Docker Open Source. Les restrictions suivantes s'appliquent :

  • Vous pouvez créer au maximum une instance par projet.
  • Les instances sont isolées et ne partagent aucune donnée ni ressource de calcul.

Avant de commencer

Si vous êtes chargé de créer des instances de registre Harbor, contactez l'administrateur de projet IAM pour demander le rôle Administrateur d'instance Harbor (harbor-instance-admin), qui vous permet d'obtenir, de lister, de surveiller, de créer, de mettre à jour, de corriger et de supprimer des instances Harbor, des dépôts de sauvegarde, des plans de sauvegarde, des sauvegardes et des restaurations dans un espace de noms de projet. Ce rôle inclut les autorisations requises pour provisionner de nouvelles instances Harbor.

Créer une instance de registre Harbor

Créez une instance de registre Harbor dans la console GDC ou la CLI gdcloud.

Console

Dans la console GDC, procédez comme suit :

  1. Dans le menu de navigation, dans la section CI/CD, cliquez sur Harbor Container Registry.
  2. Cliquez sur Créer une instance.
  3. Dans le champ Nom de l'instance, saisissez un nom pour l'instance.
  4. Facultatif : Dans la section Projets, pour créer un projet par défaut pour cette instance Harbor, activez l'option Créer un projet par défaut lors de la création de cette instance, puis procédez comme suit :
    1. Dans le champ Project Name (Nom du projet), saisissez le nom du projet.
  5. Lisez les Conditions d'utilisation de Harbor Managed, puis cochez la case si vous acceptez les conditions.
  6. Cliquez sur Créer. La colonne État indique En cours, et la colonne Nom affiche un lien externe contenant le nom de l'instance Harbor que vous venez de créer.
  7. Une fois l'instance créée et lorsque l'état indique Prêt, cliquez sur le lien externe de la page pour accéder à l'UI Web de l'instance Harbor.

gdcloud

Créez l'instance de registre Harbor :

gdcloud harbor instances create INSTANCE \
  --project=PROJECT

Remplacez les éléments suivants :

  • INSTANCE : nom de l'instance
  • PROJECT : nom du projet GDC dans lequel créer l'instance.

Confiance des nœuds de cluster pour les instances de registre Harbor

Lorsqu'une instance de registre Harbor est prête, GDC configure automatiquement les nœuds des clusters Kubernetes partagés et standards de votre organisation pour qu'ils fassent confiance au certificat TLS de l'instance, qui est émis par l'autorité de certification racine de confiance de votre organisation. Pour extraire des images de l'instance, vous n'avez pas besoin d'installer l'autorité de certification racine ni de modifier la configuration de l'environnement d'exécution du conteneur sur les nœuds du cluster.

La configuration automatique se comporte comme suit :

  • Calendrier de mise à jour des nœuds : GDC ajoute l'instance à la configuration du registre privé de chaque cluster, puis met à jour chaque nœud du cluster. Un nœud ne peut extraire des images de l'instance qu'une fois la mise à jour terminée sur ce nœud, ce qui peut prendre jusqu'à 60 minutes sur tous les nœuds.
  • Clusters nouveaux et interzones : GDC configure également les clusters que vous créez une fois que l'instance est prête, ainsi que les clusters situés dans d'autres zones de votre organisation.
  • Nom d'hôte de confiance : les nœuds ne font confiance qu'au nom d'hôte de l'instance, qui correspond à l'URL de l'instance sans le préfixe https://, par exemple harbor-1-my-project.org-1.zone1.google.gdc.test. Vous trouverez l'URL de l'instance dans le lien de l'instance de la console GDC ou dans le champ status.url du résultat de la commande gdcloud harbor instances describe. Utilisez le nom d'hôte de l'instance dans vos références d'image, par exemple INSTANCE_HOSTNAME/HARBOR_PROJECT/IMAGE:TAG, où HARBOR_PROJECT est le projet Harbor qui stocke l'image.
  • Client Docker de la station de travail : la confiance automatique ne s'applique qu'aux nœuds du cluster. Pour transférer ou extraire des images avec Docker depuis votre poste de travail, vous devez configurer votre client Docker local pour qu'il approuve l'autorité de certification racine. Pour en savoir plus, consultez Configurer Docker pour qu'il fasse confiance à l'autorité de certification racine Harbor.

Si les nœuds du cluster ne font pas confiance à votre instance, consultez Résoudre les erreurs de certificat lors de l'extraction d'images.

Résoudre les erreurs de certificat lors de l'extraction d'images

Si les nœuds du cluster ne font pas confiance au certificat du nom d'hôte dans une référence d'image, les pods ne peuvent pas extraire l'image. Les pods affichent l'état ErrImagePull ou ImagePullBackOff, et les événements de pod affichent une erreur semblable à celle-ci :

failed to pull and unpack image "INSTANCE_HOSTNAME/HARBOR_PROJECT/IMAGE:TAG": ... x509: certificate signed by unknown authority

Pour résoudre les erreurs de certificat, vous avez besoin des éléments suivants :

  • Le rôle Lecteur d'instances Harbor (harbor-instance-viewer) ou Administrateur d'instances Harbor (harbor-instance-admin) dans le projet GDC qui contient l'instance.
  • Un rôle qui vous permet d'afficher les événements de pod et de supprimer des pods sur le cluster concerné :
    • Pour un cluster partagé, le rôle Administrateur d'espace de noms (namespace-admin) dans l'espace de noms du projet de la charge de travail.
    • Pour un cluster standard, le rôle Développeur de cluster (cluster-developer) dans le projet contenant le cluster.
  • Un fichier kubeconfig pour le cluster Kubernetes concerné :

Pour résoudre ce problème, procédez comme suit :

  1. Affichez les événements du pod et le nœud qui l'exécute :

    kubectl --kubeconfig CLUSTER_KUBECONFIG \
  -n NAMESPACE describe pod POD_NAME

    Remplacez les éléments suivants :

    • CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster Kubernetes concerné.
    • NAMESPACE : espace de noms du pod. Pour un cluster partagé, il s'agit d'un espace de noms de projet.
    • POD_NAME : nom du pod.

    Dans le résultat, le champ Node indique le nœud qui exécute le pod, et la section Events affiche le message d'erreur et la référence de l'image.

  2. Vérifiez que l'instance est prête et qu'elle ne comporte aucun code d'erreur :

    • Dans la console GDC, vérifiez que l'état de l'instance est Prêt. Même si l'état indique Prêt, utilisez la CLI gdcloud pour rechercher les codes d'erreur.

    • Utilisez la CLI gdcloud pour vérifier l'état de l'instance et les éventuels codes d'erreur :

      gdcloud harbor instances describe INSTANCE \
  --project=PROJECT

      Remplacez les éléments suivants :

      • INSTANCE : nom de l'instance de registre Harbor.
      • PROJECT : nom du projet GDC contenant l'instance.

      Dans le résultat, vérifiez que la condition avec type: Ready dans la liste status.conditions est définie sur status: "True". Le résultat ressemble à ce qui suit :

      # Several lines of code are omitted here.
status:
  conditions:
  - message: HarborInstance reconciled
    reason: Reconciled
    status: "True"
    type: Ready
  # Several lines of code are omitted here.
  url: https://harbor-1-my-project.org-1.zone1.google.gdc.test

    Si l'état reste En cours ou affiche Inconnu ou Erreur, ou si la condition Ready n'a pas la valeur status: "True", contactez votre opérateur d'infrastructure (IO). Si la section status de la sortie gdcloud harbor instances describe contient un champ errorStatus avec des codes d'erreur, tels que HAAS0008, contactez votre IO même si la condition Ready est True. Incluez les codes et messages d'erreur.

  3. Vérifiez que la référence d'image dans votre charge de travail utilise le nom d'hôte de l'instance exactement tel qu'il apparaît dans l'URL de l'instance, sans le préfixe https://. Les nœuds ne font pas confiance aux autres noms de l'instance, tels qu'une adresse IP. Si la référence d'image utilise un nom différent, mettez à jour la référence pour utiliser le nom d'hôte de l'instance, puis redéployez la charge de travail.

  4. Si moins de 60 minutes se sont écoulées depuis que l'instance a affiché l'état Prêt ou depuis que vous avez créé le cluster (selon l'événement le plus récent), attendez que GDC ait fini de mettre à jour les nœuds du cluster :

    • Mises à jour partielles des nœuds : si l'extraction d'images réussit sur certains nœuds et échoue sur d'autres, la mise à jour est toujours en cours.
    • Sauvegardes et restaurations : les mises à jour des nœuds sont mises en attente pendant qu'une sauvegarde ou une restauration de l'instance est en cours. Démarrez la période de 60 minutes après la fin de la sauvegarde ou de la restauration.
    • Clusters nouveaux ou interzones : pour les clusters que vous créez une fois que l'instance est prête et pour les clusters situés dans une zone différente de l'instance, l'état Prêt de l'instance n'indique pas si les nœuds du cluster sont mis à jour.

  5. Une fois la mise à jour du nœud terminée, vérifiez que votre charge de travail peut extraire l'image. Kubernetes relance automatiquement les extractions d'images ayant échoué. Pour réessayer immédiatement, supprimez le pod défaillant afin que son contrôleur, tel qu'un Deployment, le recrée :

    kubectl --kubeconfig CLUSTER_KUBECONFIG \
  -n NAMESPACE delete pod POD_NAME

    Si aucun contrôleur ne gère le pod, recréez-le. Pour confirmer que le problème est résolu, vérifiez que le nouveau pod affiche l'état Running au lieu de ErrImagePull ou ImagePullBackOff :

    kubectl --kubeconfig CLUSTER_KUBECONFIG \
  -n NAMESPACE get pods

  6. Si l'erreur persiste pendant plus de 60 minutes après que l'instance a affiché l'état Prêt ou après la création du cluster (selon l'événement le plus tardif), contactez votre IO. Fournissez les informations suivantes :

    • L'organisation et la zone de l'instance et du cluster concerné
    • Le nom de l'instance et le projet GDC qui contient l'instance
    • Le nom du cluster Kubernetes concerné, qu'il s'agisse d'un cluster partagé ou standard, et, pour un cluster standard, le projet qui contient le cluster
    • La référence d'image complète et le message d'erreur complet des événements du pod
    • Les noms des nœuds sur lesquels l'extraction d'images échoue, et si l'extraction d'images réussit sur d'autres nœuds
    • Quand l'instance a affiché l'état Prêt, quand vous avez créé le cluster et si une sauvegarde ou une restauration de l'instance était en cours
    • La section status de la sortie gdcloud harbor instances describe, y compris les codes d'erreur errorStatus

Étapes suivantes

Une fois votre instance de registre Harbor prête, vous pouvez créer des projets pour héberger vos collections d'images ou gérer vos instances existantes :