Vous pouvez utiliser un registre de conteneur externe avec des clusters Tanzu Kubernetes. Il s'agit d'une alternative à l'utilisation du Registre Harbor.

Cas d'utilisation du registre privé externe

Les registres de conteneur fournissent une fonction critique pour les déploiements Kubernetes, servant de référentiel centralisé pour le stockage et le partage d'images de conteneur. Le registre de conteneur public le plus couramment utilisé est DockerHub. Il existe de nombreuses offres de registre de conteneurs privés. VMware Harbor est un registre de conteneur privé, cloud natif et open source. vSphere with Tanzu intègre une instance de Harbor que vous pouvez utiliser comme registre de conteneur privé pour les Espaces vSphere et pour les espaces s'exécutant sur les clusters Tanzu Kubernetes. Pour plus d'informations, consultez Activez le Registre Harbor intégré sur le Cluster superviseur.

Le Registre Harbor intégré à vSphere with Tanzu nécessite une mise en réseau NSX-T. Si vous utilisez une mise en réseau vSphere, vous ne pouvez pas l'utiliser. En outre, vous exécutez peut-être déjà votre propre registre de conteneur privé que vous souhaitez intégrer aux clusters Tanzu Kubernetes. Dans ce cas, vous pouvez configurer le Service Tanzu Kubernetes Grid pour approuver les registres privés avec des certificats auto-signés, ce qui permet aux espaces Kubernetes s'exécutant sur des clusters Tanzu Kubernetes d'utiliser le registre externe.

Conditions requises pour le registre privé externe

Pour utiliser un registre privé externe avec des clusters Tanzu Kubernetes, vous devez utiliser vSphere with Tanzu version 7 U2 ou ultérieure.

Vous pouvez uniquement utiliser votre propre registre privé avec des espaces Kubernetes qui s'exécutent sur des clusters Tanzu Kubernetes et des machines virtuelles du nœud Version de Tanzu Kubernetes. Vous ne pouvez pas utiliser votre propre registre privé avec des Espaces vSphere qui s'exécutent en natif sur les hôtes ESXi. Le registre pris en charge pour les Espaces vSphere est le Registre Harbor intégré dans la plate-forme vSphere with Tanzu.

Une fois que vous avez configuré le Service Tanzu Kubernetes Grid pour un registre privé, tout nouveau cluster provisionné prendra en charge le registre privé. Pour que les clusters existants prennent en charge le registre privé, une mise à jour continue est nécessaire pour appliquer TkgServiceConfiguration. Reportez-vous à la section Mettre à jour les clusters Tanzu Kubernetes. En outre, la première fois que vous créez une spécification TkgServiceConfiguration personnalisée, le système déclenche une mise à jour continue.

Configuration du registre privé externe

Pour utiliser votre propre registre privé avec des clusters Tanzu Kubernetes, vous configurez le Service Tanzu Kubernetes Grid avec un ou plusieurs certificats auto-signés pour servir le contenu du registre privé sur HTTPS.

TkgServiceConfiguration est mis à jour pour prendre en charge les certificats auto-signés pour le registre privé. Une nouvelle section trust avec le champ additionalTrustedCAs est notamment ajoutée, ce qui vous permet de définir le nombre de certificats auto-signés que les clusters Tanzu Kubernetes doivent approuver. Cette fonctionnalité vous permet de définir facilement une liste de certificats et de les mettre à jour si une rotation est requise.

Une fois que TkgServiceConfiguration est mis à jour et appliqué, les certificats TLS sont appliqués aux nouveaux clusters lors de leur création. En d'autres termes, l'application d'une mise à jour à TkgServiceConfiguration.trust.additionalTrustedCAs ne déclenche pas une mise à jour continue automatique des clusters Tanzu Kubernetes.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TkgServiceConfiguration
metadata:
  name: tkg-service-configuration
spec:
  defaultCNI: antrea
  trust:
    additionalTrustedCAs:
      - name: first-cert-name
        data: base64-encoded string of a PEM encoded public cert 1
      - name: second-cert-name
        data: base64-encoded string of a PEM encoded public cert 2
Pour appliquer la mise à jour, exécutez la commande suivante. 
kubectl apply -f tkgserviceconfiguration.yaml

Étant donné que la spécification du Service Tanzu Kubernetes Grid est mise à jour avec les certificats de registre privé, vous n'avez pas besoin d'ajouter la clé publique au fichier kubeconfig du cluster Tanzu Kubernetes comme vous le faites lors de l'utilisation du Registre Harbor intégré avec des clusters Tanzu Kubernetes.

Configurer une charge de travail Tanzu Kubernetes pour extraire des images d'un registre de conteneur privé

Pour extraire des images à partir du registre de conteneur intégré pour une charge de travail de cluster Tanzu Kubernetes, configurez le YAML de la charge de travail avec les détails du registre privé.

Cette procédure peut être utilisée pour obtenir des images à partir d'un registre de conteneur privé ou du Registre Harbor. Dans cet exemple, nous créons une spécification d'espace qui utilisera une image stockée dans le Registre Harbor intégré et utilisera le secret d'extraction d'image précédemment configuré.
  1. Créez un exemple de spécification d'espace avec les détails concernant le registre privé.
    apiVersion: v1
kind: Pod
metadata:
  name: <workload-name>
  namespace: <kubernetes-namespace>
spec:
  containers:
  - name: private-reg-container
    image: <Registry-IP-Address>/<vsphere-namespace>/<image-name>:<version>
  imagePullSecrets:
  - name: <registry-secret-name>
    • Remplacez <workload-name> par le nom de la charge de travail de l'espace.
    • Remplacez <kubernetes-namespace> par l'espace de noms Kubernetes dans le cluster où l'espace sera créé. Il doit s'agir du même espace de noms Kubernetes que celui dans lequel le secret d'extraction d'images du service de registre est stocké dans le cluster Tanzu Kubernetes (par exemple, l'espace de noms par défaut).
    • Remplacez <Registry-IP-Address> par l'adresse IP de l'instance de Registre Harbor intégrée exécutée sur le Cluster superviseur.
    • Remplacez <vsphere-namespace> par le Espace de noms vSphere où la Tanzu Kubernetes cible est provisionnée.
    • Remplacez <image-name> par un nom d'image de votre choix.
    • Remplacez <version> par une version appropriée de l'image, telle que « dernière ».
    • Remplacez <registry-secret-name> par le nom du secret d'extraction d'image du service de registre que vous avez créé précédemment.
  2. Créez une charge de travail dans le cluster Tanzu Kubernetes en fonction de la spécification d'espace que vous avez définie.
    kubectl --kubeconfig=<path>/cluster-kubeconfig apply -f <pod.yaml>

    L'espace doit être créé à partir de l'image extraite du registre.

Champs d'approbation pour les registres privés externes

Ajoutez une entrée de certificat (chaîne codée en base64 d'un certificat public codé en PEM) à la section additionalTrustedCAs dans TkgServiceConfiguration. Les données sont des certificats publics stockés en texte clair dans TkgServiceConfiguration.

Tableau 1. Champs d'approbation pour les registres privés
Champ Description
trust Marqueur de section. N'accepte aucune donnée.
additionalTrustedCAs Marqueur de section. Inclut un tableau de certificats avec un nom et des données pour chacun d'eux.
name Nom du certificat TLS.
data Chaîne codée en base64 d'un certificat public codé en PEM.

Suppression de certificats de registre privé externes

Supprimez un certificat de la liste des certificats dans la section additionalTrustedCAs de TkgServiceConfiguration et appliquez le certificat TkgServiceConfiguration au Service Tanzu Kubernetes Grid.

Rotation des certificats de registre privé externes

Pour effectuer une rotation d'un certificat, l'administrateur VI ou l'ingénieur DevOps modifie le contenu du certificat dans TkgServiceConfiguration ou dans la spécification du cluster Tanzu Kubernetes et applique cette configuration pour déclencher une mise à jour continue de cette configuration TKC.

Dépannage des certificats de registre privé externes

Si vous configurez le Service Tanzu Kubernetes Grid avec les certificats approuvés et que vous ajoutez le certificat auto-signé au fichier kubeconfig du cluster, vous devez pouvoir réussir extraire une image de conteneur à partir d'un registre privé qui utilise ce certificat auto-signé.

La commande suivante peut vous aider à déterminer si l'image de conteneur a été correctement issue d'une charge de travail d'un groupe :

kubectl describe pod PODNAME

Cette commande affiche l'état détaillé et les messages d'erreur d'un espace donné. Exemple de tentative d'utilisation d'une image avant d'ajouter des certificats personnalisés au cluster : 

Events:
  Type     Reason                        Age               From               Message
  ----     ------                        ----              ----               -------
  Normal   Scheduled                     33s               default-scheduler  ...
  Normal   Image                         32s               image-controller   ...
  Normal   Image                         15s               image-controller   ...
  Normal   SuccessfulRealizeNSXResource  7s (x4 over 31s)  nsx-container-ncp  ...
  Normal   Pulling                       7s                kubelet            Waiting test-gc-e2e-demo-ns/testimage-8862e32f68d66f727d1baf13f7eddef5a5e64bbd-v10612
  Warning  Failed                        4s                kubelet            failed to get images: ... Error: ... x509: certificate signed by unknown authority
Lors de l'exécution de la commande suivante : 
kubectl get pods
L'erreur ErrImagePull est également visible dans la vue globale de l'état de l'espace : 
NAME                                         READY   STATUS         RESTARTS   AGE
testimage-nginx-deployment-89d4fcff8-2d9pz   0/1     Pending        0          17s
testimage-nginx-deployment-89d4fcff8-7kp9d   0/1     ErrImagePull   0          79s
testimage-nginx-deployment-89d4fcff8-7mpkj   0/1     Pending        0          21s
testimage-nginx-deployment-89d4fcff8-fszth   0/1     ErrImagePull   0          50s
testimage-nginx-deployment-89d4fcff8-sjnjw   0/1     ErrImagePull   0          48s
testimage-nginx-deployment-89d4fcff8-xr5kg   0/1     ErrImagePull   0          79s
Les erreurs « x509 : certificat signé par une autorité inconnue » et « ErrImagePull » indiquent que le cluster n'est pas configuré avec le certificat correct pour se connecter au registre du conteneur privé. Le certificat est manquant ou mal configuré.

Si vous rencontrez des erreurs de connexion à un registre privé après avoir configuré les certificats, vous pouvez vérifier si les certificats appliqués dans la configuration sont appliqués au cluster. Vous pouvez vérifier si les certificats ont été correctement appliqués dans leur configuration à l'aide de SSH.

Deux étapes d'investigation peuvent être réalisées en se connectant à un nœud worker via SSH.
  1. Recherchez dans le dossier /etc/ssl/certs/ les fichiers nommés tkg-<cert_name>.pem, où <cert_name> correspond à la propriété « name » du certificat ajouté dans TkgServiceConfiguration. Si les certificats correspondent à ce qui se trouve dans TkgServiceConfiguration, et si l'utilisation d'un registre privé ne fonctionne toujours pas, effectuez un diagnostic supplémentaire en réalisant l'étape suivante.
  2. Exécutez le test de connexion openssl suivant sur le serveur cible à l'aide de certificats auto-signés en exécutant la commande openssl s_client -connect hostname:port_num, où hostname correspond au nom d'hôte/nom DNS du registre privé qui utilise des certificats auto-signés et port_num correspond au numéro de port sur lequel le service s'exécute (en général, 443 pour HTTPS). Vous pouvez vérifier exactement quelle erreur est renvoyée par openssl lors d'une tentative de connexion au point de terminaison qui utilise des certificats auto-signés, et corriger la situation, par exemple, en ajoutant les certificats appropriés à TkgServiceConfiguration. Si le cluster Tanzu Kubernetes est intégré à un certificat incorrect, vous devrez mettre à jour la configuration du Service Tanzu Kubernetes Grid avec les certificats corrects, supprimer le cluster Tanzu Kubernetes, puis le recréer à l'aide de la configuration qui contient les certificats corrects.