Crea istanze del registro Harbor

Utilizza il servizio Managed Harbor Service (MHS) di Google Distributed Cloud (GDC) con air gap per creare un'istanza del registry Harbor in ogni progetto. Un'istanza del registry Harbor funge da repository centrale per l'archiviazione e la gestione delle immagini container in un ambiente cloud-native. Estende le funzionalità della distribuzione Docker open source. Si applicano le seguenti limitazioni:

  • Puoi creare un massimo di un'istanza per progetto.
  • Le istanze sono isolate e non condividono dati o risorse di calcolo.

Prima di iniziare

Se sei responsabile della creazione di istanze del registry Harbor, contatta l'amministratore del progetto IAM per richiedere il ruolo Amministratore istanza Harbor (harbor-instance-admin), che ti consente di recuperare, elencare, controllare, creare, aggiornare, applicare patch ed eliminare istanze Harbor, repository di backup, piani di backup, backup e ripristini all'interno di uno spazio dei nomi del progetto. Questo ruolo include le autorizzazioni necessarie per eseguire il provisioning di nuove istanze Harbor.

Crea un'istanza del registry Harbor

Crea un'istanza del registry Harbor nella console GDC o nella CLI gdcloud.

Console

Nella console GDC, segui questi passaggi:

  1. Nel menu di navigazione, nella sezione CI/CD, fai clic su Harbor Container Registry.
  2. Fai clic su Crea istanza.
  3. Nel campo Nome istanza, inserisci un nome per l'istanza.
  4. (Facoltativo) Nella sezione Progetti, per creare un progetto predefinito per questa istanza Harbor, fai clic sul pulsante di attivazione/disattivazione Crea un progetto predefinito durante la creazione di questa istanza e segui questi passaggi:
    1. Nel campo Project Name (Nome progetto), inserisci un nome per il progetto.
  5. Leggi i Termini di servizio di Harbor Managed, quindi seleziona la casella di controllo se accetti i termini.
  6. Fai clic su Crea. Il campo Stato mostra In corso e il campo Nome mostra un link esterno contenente il nome dell'istanza Harbor appena creata.
  7. Dopo aver creato l'istanza e quando lo Stato mostra Pronto, fai clic sul link esterno nella pagina per visitare l'interfaccia utente web dell'istanza Harbor.

gdcloud

Crea l'istanza del registry Harbor:

gdcloud harbor instances create INSTANCE \
  --project=PROJECT

Sostituisci quanto segue:

  • INSTANCE: il nome dell'istanza
  • PROJECT: il nome del progetto GDC in cui creare l'istanza

Attendibilità dei nodi del cluster per le istanze del registry Harbor

Quando un'istanza del registry Harbor è pronta, GDC configura automaticamente i nodi dei cluster Kubernetes condivisi e standard della tua organizzazione in modo che considerino attendibile il certificato TLS dell'istanza, emesso dall'autorità di certificazione radice attendibile della tua organizzazione. Per eseguire il pull delle immagini dall'istanza, non è necessario installare la CA principale o modificare la configurazione del runtime dei container sui nodi del cluster.

La configurazione automatica ha il seguente comportamento:

  • Tempi di aggiornamento dei nodi: GDC aggiunge l'istanza alla configurazione del registry privato di ogni cluster, quindi aggiorna ogni nodo del cluster. Un nodo può eseguire il pull delle immagini dall'istanza solo dopo il completamento dell'aggiornamento su quel nodo, che può richiedere fino a 60 minuti su tutti i nodi.
  • Cluster nuovi e tra zone: GDC configura anche i cluster che crei dopo che l'istanza è pronta e i cluster in altre zone della tua organizzazione.
  • Nome host attendibile: i nodi considerano attendibile solo il nome host dell'istanza, ovvero l'URL dell'istanza senza il prefisso https://, ad esempio harbor-1-my-project.org-1.zone1.google.gdc.test. Puoi trovare l'URL dell'istanza nel link all'istanza della console GDC o nel campo status.url dell'output del comando gdcloud harbor instances describe. Utilizza il nome host dell'istanza nei riferimenti alle immagini, ad esempio INSTANCE_HOSTNAME/HARBOR_PROJECT/IMAGE:TAG, dove HARBOR_PROJECT è il progetto Harbor in cui è archiviata l'immagine.
  • Client Docker della workstation: l'attendibilità automatica si applica solo ai nodi del cluster. Per eseguire il push o il pull delle immagini con Docker dalla tua workstation, devi configurare il client Docker locale in modo che consideri attendibile la CA radice. Per saperne di più, consulta Configura Docker in modo che consideri attendibile la CA root di Harbor.

Se i nodi del cluster non considerano attendibile la tua istanza, consulta Risolvi gli errori dei certificati durante il pull delle immagini.

Risolvi gli errori dei certificati durante il pull delle immagini

Se i nodi del cluster non considerano attendibile il certificato per il nome host in un riferimento all'immagine, i pod non possono eseguire il pull dell'immagine. I pod mostrano lo stato ErrImagePull o ImagePullBackOff e gli eventi dei pod mostrano un errore simile al seguente:

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

Per risolvere i problemi relativi ai certificati, devi disporre di quanto segue:

  • Il ruolo Harbor Instance Viewer (harbor-instance-viewer) o Harbor Instance Admin (harbor-instance-admin) nel progetto GDC che contiene l'istanza.
  • Un ruolo che consente di visualizzare gli eventi dei pod ed eliminare i pod nel cluster interessato:
    • Per un cluster condiviso, il ruolo Namespace Admin (namespace-admin) nello spazio dei nomi del progetto del workload.
    • Per un cluster standard, il ruolo Sviluppatore cluster (cluster-developer) nel progetto che contiene il cluster.
  • Un file kubeconfig per il cluster Kubernetes interessato:

Per risolvere questo problema, completa i seguenti passaggi:

  1. Visualizza gli eventi del pod e il nodo che lo esegue:

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

    Sostituisci quanto segue:

    • CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster Kubernetes interessato.
    • NAMESPACE: lo spazio dei nomi del pod. Per un cluster condiviso, si tratta di uno spazio dei nomi del progetto.
    • POD_NAME: il nome del pod.

    Nell'output, il campo Node mostra il nodo che esegue il pod e la sezione Events mostra il messaggio di errore e il riferimento all'immagine.

  2. Verifica che l'istanza sia pronta e non presenti codici di errore:

    • Nella console GDC, verifica che lo Stato dell'istanza sia Pronto. Anche se lo stato è Pronto, utilizza la CLI gdcloud per verificare la presenza di codici di errore.

    • Utilizza la CLI gdcloud per controllare lo stato dell'istanza ed eventuali codici di errore:

      gdcloud harbor instances describe INSTANCE \
  --project=PROJECT

      Sostituisci quanto segue:

      • INSTANCE: il nome dell'istanza del registry Harbor.
      • PROJECT: il nome del progetto GDC che contiene l'istanza.

      Nell'output, verifica che la condizione con type: Ready nell'elenco status.conditions abbia status: "True". L'output è simile al seguente:

      # 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

    Se lo Stato rimane In corso o mostra Sconosciuto o Errore, o se la condizione Ready non ha status: "True", contatta il tuo operatore di infrastruttura (IO). Se la sezione status dell'output gdcloud harbor instances describe contiene un campo errorStatus con codici di errore, ad esempio HAAS0008, contatta l'IO anche se la condizione Ready è True. Includi i codici e i messaggi di errore.

  3. Verifica che il riferimento all'immagine nel workload utilizzi il nome host dell'istanza esattamente come appare nell'URL dell'istanza, senza il prefisso https://. I nodi non considerano attendibili altri nomi per l'istanza, ad esempio un indirizzo IP. Se il riferimento all'immagine utilizza un nome diverso, aggiorna il riferimento in modo che utilizzi il nome host dell'istanza, quindi esegui nuovamente il deployment del workload.

  4. Se sono trascorsi meno di 60 minuti da quando l'istanza ha mostrato lo stato Pronta o da quando hai creato il cluster, a seconda di quale sia l'evento più recente, attendi che GDC termini l'aggiornamento dei nodi del cluster:

    • Aggiornamenti parziali dei nodi: se i pull delle immagini hanno esito positivo su alcuni nodi e non su altri, l'aggiornamento è ancora in corso.
    • Backup e ripristini: gli aggiornamenti dei nodi attendono mentre è in corso un backup o un ripristino dell'istanza. Inizia il periodo di 60 minuti al termine del backup o del ripristino.
    • Cluster nuovi o tra zone: per i cluster che crei dopo che l'istanza è pronta e per i cluster in una zona diversa da quella dell'istanza, lo stato Pronta dell'istanza non mostra se i nodi del cluster sono aggiornati.

  5. Al termine dell'aggiornamento del nodo, verifica che il workload possa eseguire il pull dell'immagine. Kubernetes riprova automaticamente i pull delle immagini non riusciti. Per riprovare immediatamente, elimina il pod in errore in modo che il relativo controller, ad esempio un Deployment, lo ricrei:

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

    Se nessun controller gestisce il pod, ricrealo. Per confermare che il problema è stato risolto, verifica che il nuovo pod mostri lo stato Running anziché ErrImagePull o ImagePullBackOff:

    kubectl --kubeconfig CLUSTER_KUBECONFIG \
  -n NAMESPACE get pods

  6. Se l'errore persiste per più di 60 minuti dopo che l'istanza ha mostrato lo stato Pronta o dopo la creazione del cluster, a seconda di quale evento si verifica per ultimo, contatta il tuo IO. Fornisci le seguenti informazioni:

    • L'organizzazione e la zona dell'istanza e del cluster interessato
    • Il nome dell'istanza e il progetto GDC che contiene l'istanza
    • Il nome del cluster Kubernetes interessato, se si tratta di un cluster condiviso o standard e, per un cluster standard, il progetto che contiene il cluster
    • Il riferimento completo all'immagine e il messaggio di errore completo degli eventi del pod
    • I nomi dei nodi in cui i pull delle immagini non vanno a buon fine e se i pull delle immagini vanno a buon fine su altri nodi
    • Quando l'istanza ha mostrato lo stato Pronta, quando hai creato il cluster e se era in corso un backup o un ripristino dell'istanza
    • La sezione status dell'output gdcloud harbor instances describe, inclusi eventuali codici di errore errorStatus

Passaggi successivi

Quando l'istanza del registry Harbor è pronta, puoi creare progetti per ospitare le tue raccolte di immagini o gestire le istanze esistenti: