Fare riferimento a questo argomento per integrare i cluster Servizio TKG con un registro di container privato.

Caso d'uso del registro container privato

I registri di container forniscono una funzione essenziale per le distribuzioni Kubernetes, che funge da repository centralizzato per lo storage e la condivisione delle immagini dei container. Il registro di container pubblico più comunemente utilizzato è Docker Hub . Esistono molti registri di container privati. VMware Harbor è un registro di container privato open source nativo del cloud che viene fornito con Supervisore.

Integrazione del registro di container privato

Per integrare un registro privato con un cluster Servizio TKG, configurare il cluster con uno o più certificati CA autofirmati per il contenuto del registro privato su HTTPS. A tale scopo, nella specifica del cluster includere un campo trust con il valore additionalTrustedCAs. È possibile definire un numero qualsiasi di certificati CA autofirmati che il cluster TKGS deve considerare attendibili. Questa funzionalità consente di definire facilmente un elenco di certificati e di aggiornare quelli che devono essere ruotati.

È possibile configurare il certificato del registro privato quando si crea inizialmente il cluster oppure aggiornare un cluster esistente e fornire il certificato del registro privato. Per modificare un cluster esistente e aggiungere il certificato del registro privato, utilizzare il metodo kubectl edit. Vedere Configurazione di un editor di testo per Kubectl.

Si tenga presente che l'implementazione del campo trust.additionalTrustedCAs è leggermente diversa tra le API supportate per il provisioning dei cluster TKGS. Per ulteriori dettagli, fare riferimento alle tabelle Campi trust dell'API v1alpha3 e Variabile trust dell'API v1beta1.

Esempio di API v1alpha3

L'esempio seguente illustra come integrare un cluster Servizio TKG sottoposto a provisioning mediante l'API v1alpha3 con un registro di container privato utilizzando il relativo certificato CA.

Con TanzuKubernetesCluster v1alpha3 API, il campo trust.additionalTrustedCAs include una o più coppie nome-dati, ognuna delle quali può includere un certificato TLS per un registro privato.
Tabella 1. Campi trust dell'API v1alpha3
Campo Descrizione
trust Marcatore di sezione. Non accetta alcun dato.
additionalTrustedCAs Marcatore di sezione. Include un array di certificati con i campi name e data per ciascuno.
name Nome definito dall'utente del certificato CA.
data Contenuto del certificato CA (ca.crt) in formato PEM con doppia codifica base64.
Nota: L'API v1alpha3 richiede che il contenuto del certificato abbia una codifica base64 singola. Se il contenuto non ha una codifica base64 singola, il file PEM risultante non può essere elaborato.
Utilizzare la procedura seguente per integrare Harbor con un cluster dell'API v1alpha3 utilizzando il certificato del registro Harbor.
  1. Scaricare il certificato del registro Harbor dall'interfaccia Web di Harbor nella schermata Progetti > Repository.

    Il file del certificato CA viene scaricato come ca.crt.

  2. Codificare tramite codifica base64 singola il contenuto del certificato CA.
  3. Includere i campi trust.additionalTrustedCAs nella specifica del cluster e popolarli con i valori name e 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. Per ruotare un certificato, applicare kubectl edit alla specifica del cluster e aggiornare il valore trust.additionalTrustedCAs.data, quindi avviare un aggiornamento in sequenza.

Esempio di API v1beta1

L'esempio seguente descrive come integrare un cluster Servizio TKG sottoposto a provisioning mediante l'API v1beta1 con un registro di container privato utilizzando il relativo certificato CA.

Per integrare un registro di container privato con un cluster TKGS sottoposto a provisioning con API v1beta1 del cluster, utilizzare la variabile trust e popolarla con un segreto Kubernetes contenente il certificato del registro privato.
Tabella 2. Variabile trust dell'API v1beta1
Campo Descrizione
trust Marcatore di sezione. Non accetta alcun dato.
additionalTrustedCAs Marcatore di sezione. Include un array di certificati con il nome per ciascuno.
name Nome definito dall'utente per il campo della mappa data nel segreto Kubernetes che contiene il certificato CA in formato PEM con doppia codifica base64.
Nota: L'API v1beta1 richiede che il contenuto del certificato abbia una codifica base64 doppia. Se la codifica del contenuto non è base64 doppia, il file PEM risultante non può essere elaborato.
Utilizzare la procedura seguente per integrare Harbor con un cluster dell'API v1beta1 utilizzando il certificato del registro Harbor.
  1. Scaricare il certificato del registro Harbor dall'interfaccia Web di Harbor nella schermata Progetti > Repository.

    Il file del certificato CA viene scaricato come ca.crt.

  2. Codificare tramite codifica base64 doppia il contenuto del certificato CA.
  3. Creare un file YAML di definizione del segreto Kubernetes con il contenuto seguente.
    #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
    dove:
    • Il valore della mappa data del segreto è una stringa definita dall'utente che è il nome del certificato CA (additional-ca-1 in questo esempio) il cui valore è un certificato con codifica base64 doppia.
    • Nella sezione metadata, attribuire al segreto il nome CLUSTER-NAME-user-trusted-ca-secret, dove CLUSTER-NAME è il nome del cluster. Questo segreto deve essere creato nello stesso Spazio dei nomi vSphere del cluster.
  4. Creare il segreto Kubernetes in modo dichiarativo.
    kubectl apply -f additional-ca-1.yaml
  5. Verificare la creazione del segreto.
    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. Includere la variabile trust nella specifica del cluster che fa riferimento al nome della mappa dei dati per il segreto, che in questo esempio è additional-ca-1.
    #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. Per ruotare il certificato, creare un nuovo segreto e modificare la specifica del cluster con il valore appropriato. Verrà attivato un aggiornamento in sequenza del cluster.
    Nota: Il sistema non monitora le modifiche apportate a CLUSTER-NAME-user-trusted-ca-secret. Se il valore della mappa data cambia, queste modifiche non vengono riportate nel cluster. Sarà necessario creare un nuovo segreto e il valore name della mappa dei dati per trust.additionalTrustCAs.