Reportez-vous à cette rubrique pour intégrer des clusters de Service TKG avec un registre de conteneur privé.

Cas d'utilisation du registre de conteneur privé

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 Docker Hub. Il existe de nombreuses offres de registre de conteneurs privés. VMware Harbor est un registre de conteneur privé, natif cloud et open source fourni avec Superviseur.

Intégration du registre de conteneur privé

Pour intégrer un registre privé avec un cluster de Service TKG, configurez le cluster avec un ou plusieurs certificats d'autorité de certification autosignés pour servir le contenu du registre privé sur HTTPS. Pour ce faire, dans la spécification de cluster, vous incluez un champ trust avec la valeur additionalTrustedCAs. Vous pouvez définir n'importe quel nombre de certificats d'autorité de certification autosignés que le cluster TKGS doit approuver. Cette fonctionnalité vous permet de définir facilement une liste de certificats et de les mettre à jour si une rotation est requise.

Vous pouvez configurer le certificat de registre privé lorsque vous créez initialement le cluster, ou vous pouvez mettre à jour un cluster existant et fournir le certificat de registre privé. Pour modifier un cluster existant et ajouter le certificat de registre privé, utilisez la méthode kubectl edit. Reportez-vous à la section Configurer un éditeur de texte pour Kubectl.

Sachez que l'implémentation du champ trust.additionalTrustedCAs diffère légèrement entre les API prises en charge pour le provisionnement des clusters TKGS. Reportez-vous aux tableaux Champs d'approbation de l'API v1alpha3 et Variable d'approbation de l'API v1beta1 pour plus de détails.

Exemple d'API v1alpha3

L'exemple suivant montre comment intégrer un cluster de Service TKG provisionné à l'aide de l'API v1alpha3 à un registre de conteneur privé utilisant son certificat d'autorité de certification.

Avec la TanzuKubernetesCluster v1alpha3 API, le champ trust.additionalTrustedCAs inclut une ou plusieurs paires nom-données, chacune d'elles pouvant inclure un certificat TLS pour un registre privé.
Tableau 1. Champs d'approbation de l'API v1alpha3
Champ Description
trust Marqueur de section. N'accepte aucune donnée.
additionalTrustedCAs Marqueur de section. Inclut un tableau de certificats avec des champs name et data pour chacun d'eux.
name Nom du certificat d'autorité de certification défini par l'utilisateur.
data Contenu du certificat d'autorité de certification (ca.crt) au format PEM codé en base64 double.
Note : L'API v1alpha3 nécessite que le contenu du certificat soit codé en base64 unique. Si le contenu n'est pas codé en base6 unique, le fichier PEM résultant ne peut pas être traité.
Utilisez la procédure suivante pour intégrer Harbor à un cluster d'API v1alpha3 à l'aide du certificat de registre Harbor.
  1. Téléchargez le certificat de registre Harbor à partir de l'interface Web de Harbor dans l'écran Projets > Référentiels.

    Le fichier de certificat d'autorité de certification se télécharge en tant que ca.crt.

  2. Codez en base64 unique le contenu du certificat d'autorité de certification.
  3. Incluez les champs trust.additionalTrustedCAs dans la spécification du cluster et remplissez les valeurs name et data.
    #tkc-with-trusted-private-reg-cert.yaml
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesCluster
metadata:
  name: tkc01
  namespace: tkgs-cluster-ns
spec:
   topology:
     controlPlane:
       replicas: 3
       storageClass: tkgs-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.25.7---vmware.3-fips.1-tkg.1
     nodePools:
     - name: nodepool-01
       replicas: 3
       storageClass: tkgs-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.25.7---vmware.3-fips.1-tkg.1
   settings:
     storage:
       defaultClass: tkgs-storage-policy
     network:
       cni:
         name: antrea
       services:
         cidrBlocks: ["198.51.100.0/12"]
       pods:
         cidrBlocks: ["192.0.2.0/16"]
       serviceDomain: cluster.local
       trust:
         additionalTrustedCAs:
         - name: CompanyInternalCA-1
           data: LS0tLS1C...LS0tCg==
         - name: CompanyInternalCA-2
           data: MTLtMT1C...MT0tPg==
  4. Pour effectuer la rotation d'un certificat, kubectl edit la spécification du cluster et mettez à jour la valeur trust.additionalTrustedCAs.data, puis lancez une mise à jour continue.

Exemple d'API v1beta1

L'exemple suivant décrit comment intégrer un cluster de Service TKG provisionné à l'aide de l'API v1beta1 à un registre de conteneur privé utilisant son certificat d'autorité de certification.

Pour intégrer un registre de conteneur privé à un cluster TKGS provisionné avec le API de cluster v1beta1, vous utilisez la variable trust et la remplissez avec un secret Kubernetes contenant le certificat de registre privé.
Tableau 2. Variable d'approbation de l'API v1beta1
Champ Description
trust Marqueur de section. N'accepte aucune donnée.
additionalTrustedCAs Marqueur de section. Inclut un tableau de certificats contenant le nom de chacun d'entre eux.
name Le nom défini par l'utilisateur pour le champ de mappage data dans le secret Kubernetes qui contient le certificat d'autorité de certification au format PEM codé en base64 double.
Note : L'API v1beta1 nécessite que le contenu du certificat soit codé en base64 double. Si le contenu n'est pas codé en base6 double, le fichier PEM résultant ne peut pas être traité.
Utilisez la procédure suivante pour intégrer Harbor à un cluster d'API v1beta1 à l'aide du certificat de registre Harbor.
  1. Téléchargez le certificat de registre Harbor à partir de l'interface Web de Harbor dans l'écran Projets > Référentiels.

    Le fichier de certificat d'autorité de certification se télécharge en tant que ca.crt.

  2. Codez en base64 double le contenu du certificat d'autorité de certification.
  3. Créez un fichier YAML de définition de secret Kubernetes avec le contenu suivant.
    #additional-ca-1.yaml
apiVersion: v1
data:
  additional-ca-1: TFMwdExTMUNSGlSzZ3Jaa...VVNVWkpRMEMwdExTMHRDZz09
kind: Secret
metadata:
  name: cluster01-user-trusted-ca-secret
  namespace: tkgs-cluster-ns
type: Opaque
    Où :
    • La valeur du mappage de data du secret est une chaîne définie par l'utilisateur qui est le nom du certificat d'autorité de certification (additional-ca-1 dans cet exemple) dont la valeur est un certificat double codé en base64.
    • Dans la section metadata, nommez le secret CLUSTER-NAME-user-trusted-ca-secret, où CLUSTER-NAME est le nom du cluster. Ce secret doit être créé dans le même Espace de noms vSphere que le cluster.
  4. Créez le secret Kubernetes de manière déclarative.
    kubectl apply -f additional-ca-1.yaml
  5. Vérifiez la création du secret.
    kubeclt get secret -n tkgs-cluster-ns cluster01-user-trusted-ca-secret
NAME                                             TYPE     DATA   AGE
cluster01-user-trusted-ca-secret                 Opaque   12     2d22h
  6. Incluez la variable trust dans la spécification de cluster qui fait référence au nom de la carte de données pour le secret, qui est additional-ca-1 dans cet exemple.
    #cluster-with-trusted-private-reg-cert.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: cluster01
  namespace: tkgs-cluster-ns
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["198.52.100.0/12"]
    pods:
      cidrBlocks: ["192.101.2.0/16"]
    serviceDomain: "cluster.local"
  topology:
    class: tanzukubernetescluster
    version: v1.26.5+vmware.2-fips.1-tkg.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: node-pool
          name: node-pool-01
          replicas: 3
    variables:
      - name: vmClass
        value: guaranteed-medium
      - name: storageClass
        value: tkgs-storage-profile
      - name: defaultStorageClass
        value: tkgs-storage-profile
      - name: trust
        value:
          additionalTrustedCAs:
          - name: additional-ca-1
  7. Pour effectuer une rotation du certificat, créez un secret et modifiez la spécification du cluster avec la valeur appropriée. Cela déclenchera une mise à jour continue du cluster.
    Note : Le système ne surveille pas les modifications apportées au CLUSTER-NAME -user-trusted-ca-secret. Si sa valeur de carte de data change, ces modifications ne seront pas reflétées dans le cluster. Vous devrez créer un secret et sa carte de données name sur trust.additionalTrustCAs.