È possibile utilizzare un registro di container esterno con pod di cluster di Tanzu Kubernetes. Questa è un'alternativa all'utilizzo del Registro Harbor incorporato.

Caso d'uso del registro privato esterno

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 è DockerHub. Esistono molti registri di container privati. VMware Harbor è un registro di container privato open source nativo del cloud. vSphere with Tanzu integra un'istanza di Harbor che può essere utilizzata come registro di container privato per Pod vSphere e per i pod in esecuzione in cluster di Tanzu Kubernetes. Per ulteriori informazioni, vedere Abilitazione del Registro Harbor incorporato nel Cluster supervisore.

Il Registro Harbor incorporato fornito con vSphere with Tanzu richiede la rete NSX-T. Se è in uso la rete di vSphere, non è possibile utilizzarla. È inoltre possibile che sia già in esecuzione il registro di container privato che si desidera integrare con i cluster di Tanzu Kubernetes. In questo caso, è possibile configurare Servizio Tanzu Kubernetes Grid in modo che consideri attendibili i registri privati con certificati autofirmati, consentendo così ai pod Kubernetes in esecuzione nei cluster di Tanzu Kubernetes di utilizzare il registro esterno.

Requisiti del registro privato esterno

Per utilizzare un registro privato esterno con cluster di Tanzu Kubernetes, è necessario usare vSphere with Tanzu versione 7 U2 o successiva.

È possibile utilizzare il proprio registro privato solo con pod Kubernetes eseguiti in cluster di Tanzu Kubernetes e nelle macchine virtuali dei nodi di Release di Tanzu Kubernetes. Non è possibile utilizzare il proprio registro privato con Pod vSphere eseguiti in modo nativo in host ESXi. Il registro supportato per i Pod vSphere è il Registro Harbor incorporato nella piattaforma vSphere with Tanzu.

Una volta configurato Servizio Tanzu Kubernetes Grid per un registro privato, tutti i nuovi cluster sottoposti a provisioning supporteranno il registro privato. Affinché i cluster esistenti supportino il registro privato, è necessario un aggiornamento in sequenza per applicare TkgServiceConfiguration. Vedere Aggiornamento dei cluster di Tanzu Kubernetes. Inoltre, la prima volta che si crea un TkgServiceConfiguration personalizzato, il sistema avvierà un aggiornamento in sequenza.

Configurazione del registro privato esterno

Per utilizzare il proprio registro privato con cluster di Tanzu Kubernetes, configurare il Servizio Tanzu Kubernetes Grid con uno o più certificati autofirmati per il contenuto del registro privato su HTTPS.

TkgServiceConfiguration viene aggiornata per supportare i certificati autofirmati per il registro privato. In particolare, viene aggiunta una nuova sezione trust con il campo additionalTrustedCAs, che consente di definire un numero qualsiasi di certificati autofirmati che i cluster di Tanzu Kubernetes devono considerare attendibili. Questa funzionalità consente di definire facilmente un elenco di certificati e di aggiornarli nel caso debbano essere ruotati.

Una volta aggiornata e applicata TkgServiceConfiguration, i certificati TLS verranno applicati ai nuovi cluster creati da quel momento in poi. In altre parole, l'applicazione di un aggiornamento a TkgServiceConfiguration.trust.additionalTrustedCAs non attiva un aggiornamento in sequenza automatico dei cluster di 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
Per applicare l'aggiornamento, eseguire il comando seguente. 
kubectl apply -f tkgserviceconfiguration.yaml

Poiché la specifica di Servizio Tanzu Kubernetes Grid viene aggiornata con i certificati del registro privato, non è necessario aggiungere la chiave pubblica al kubeconfig del cluster di Tanzu Kubernetes come quando si utilizza Registro Harbor incorporato con i cluster di Tanzu Kubernetes.

Configurazione di un carico di lavoro di Tanzu Kubernetes per il pull di immagini da un registro ddi container privato

Per eseguire il pull di immagini da un registro di container privato per un carico di lavoro del cluster di Tanzu Kubernetes, configurare il file YAML del carico di lavoro con i dettagli del registro privato.

Questa procedura può essere utilizzata per eseguire il pull delle immagini da un registro di container privato o da Registro Harbor incorporato. In questo esempio viene creata una specifica di pod che utilizza un'immagine archiviata nel Registro Harbor incorporato e viene usato il segreto di pull delle immagini configurato in precedenza.
  1. Creare una specifica di pod di esempio con i dettagli relativi al registro privato.
    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>
    • Sostituire <workload-name> con il nome del carico di lavoro del pod.
    • Sostituire <kubernetes-namespace> con lo spazio dei nomi di Kubernetes nel cluster in cui verrà creato il pod. Deve essere lo stesso spazio dei nomi di Kubernetes in cui il segreto di pull delle immagini del servizio di registro è archiviato nel cluster di Tanzu Kubernetes (ad esempio lo spazio dei nomi predefinito).
    • Sostituire <Registry-IP-Address> con l'indirizzo IP dell'istanza di Registro Harbor incorporata in esecuzione nel Cluster supervisore.
    • Sostituire <vsphere-namespace> con lo Spazio dei nomi vSphere in cui viene eseguito il provisioning del Tanzu Kubernetes di destinazione.
    • Sostituire <image-name> con il nome dell'immagine desiderata.
    • Sostituire <version> con una versione appropriata dell'immagine, ad esempio "la più recente".
    • Sostituire <registry-secret-name> con il nome del segreto del pull delle immagini del servizio di registro creato in precedenza.
  2. Creare un carico di lavoro nel cluster di Tanzu Kubernetes in base alla specifica del pod definita.
    kubectl --kubeconfig=<path>/cluster-kubeconfig apply -f <pod.yaml>

    Il pod deve essere creato dall'immagine di cui è stato eseguito il pull dal registro.

Campi di attendibilità per i registri privati esterni

Aggiungere una voce del certificato (stringa con codifica base64 di un certificato pubblico con codifica PEM) nella sezione additionalTrustedCAs di TkgServiceConfiguration. I dati sono certificati pubblici archiviati in testo normale in TkgServiceConfiguration.

Tabella 1. Campi di attendibilità per i registri privati
Campo Descrizione
trust Marcatore di sezione. Non accetta alcun dato.
additionalTrustedCAs Marcatore di sezione. Include un array di certificati con nome e dati per ciascuno.
name Nome del certificato TLS.
data Stringa codificata in base64 di un certificato pubblico con codifica PEM.

Rimozione dei certificati del registro privato esterno

Rimuovere un certificato dall'elenco di certificati nella sezione additionalTrustedCAs di TkgServiceConfiguration e applicare TkgServiceConfiguration al Servizio Tanzu Kubernetes Grid.

Rotazione dei certificati del registro privato esterno

Per ruotare un certificato, l'amministratore di VI o il tecnico di DevOps deve modificare il contenuto del certificato in TkgServiceConfiguration o nella specifica del cluster di Tanzu Kubernetes e applicare tale configurazione per attivare un aggiornamento in sequenza di tale TKC.

Risoluzione dei problemi relativi ai certificati del registro privato esterno

Se si configura Servizio Tanzu Kubernetes Grid con i certificati da considerare attendibili e si aggiunge il certificato autofirmato al kubeconfig del cluster, è possibile eseguire correttamente il pull di un'immagine di container da un registro privato che utilizza tale certificato autofirmato.

Il comando seguente consente di stabilire se il pull dell'immagine del container è stato effettuato correttamente per un carico di lavoro del pod:

kubectl describe pod PODNAME

Questo comando mostra in dettaglio lo stato e i messaggi di errore di un determinato pod. Esempio di tentativo di effettuare il pull di un'immagine prima di aggiungere certificati personalizzati al 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
E quando si esegue il comando seguente: 
kubectl get pods
L'errore di ErrImagePull è visibile anche nella vista dello stato generale del pod: 
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
Gli errori "x509: certificato firmato da autorità sconosciuta" e "ErrImagePull" indicano che il cluster non è configurato con il certificato corretto per la connessione al registro di container privato. Il certificato manca oppure non è configurato correttamente.

Se si verificano errori durante la connessione a un registro privato dopo la configurazione dei certificati, è possibile verificare se i certificati applicati nella configurazione sono applicati al cluster. È possibile verificare se i certificati sono stati applicati correttamente nella loro configurazione utilizzando SSH.

È possibile eseguire due passaggi di analisi collegandosi a un nodo worker tramite SSH.
  1. Controllare nella cartella /etc/ssl/certs/ la presenza di file denominati tkg-<cert_name>.pem, dove <cert_name> è la proprietà "name" del certificato aggiunto in TkgServiceConfiguration. Se i certificati corrispondono a ciò che si trova in TkgServiceConfiguration e l'utilizzo di un registro privato continua a non funzionare, procedere ulteriormente con la diagnosi eseguendo il passaggio successivo.
  2. Eseguire il test della connessione openssl seguente nel server di destinazione utilizzando certificati autofirmati eseguendo il comando openssl s_client -connect hostname:port_num, dove hostname è il nome host o il nome DNS del registro privato che utilizza certificati autofirmati e port_num è il numero della porta in cui è in esecuzione il servizio (in genere 443 per HTTPS). È possibile controllare esattamente l'errore restituito da openssl quando si tenta di connettersi all'endpoint che utilizza certificati autofirmati e risolvere la situazione da tale posizione, ad esempio aggiungendo i certificati corretti a TkgServiceConfiguration. Se il cluster di Tanzu Kubernetes è incorporato con un certificato errato, sarà necessario aggiornare la configurazione di Servizio Tanzu Kubernetes Grid con i certificati corretti, eliminare il cluster di Tanzu Kubernetes e quindi ricrearlo utilizzando la configurazione che contiene i certificati corretti.