Utilizzare un mirror del registry per le immagini container

Questa pagina spiega come creare e eseguire l'upgrade dei cluster utilizzando le immagini estratte da un mirroring del Registro di sistema anziché da un registry pubblico, ad esempio gcr.io. Questa funzionalità può essere attivata o disattivata in qualsiasi momento nel ciclo di vita del cluster.

Questa pagina è rivolta a operatori e specialisti di archiviazione che configurano e gestiscono le prestazioni, l'utilizzo e le spese di archiviazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Un mirror del registry è una copia locale di un registry pubblico che copia o esegue il mirroring della struttura file del registry pubblico. Ad esempio, supponiamo che il percorso al mirror del registry locale sia 172.18.0.20:5000. Quando containerd rileva una richiesta di estrazione di un'immagine come gcr.io/kubernetes-e2e-test-images/nautilus:1.0, containerd tenta di estrarre l'immagine non da gcr.io, ma dal tuo registry locale al seguente percorso: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Se l'immagine non si trova in questo percorso del registry locale, viene estratta automaticamente dal registry pubblico gcr.io.

L'utilizzo di un mirror del registry offre i seguenti vantaggi:

  • Ti protegge da interruzioni del registry pubblico.
  • Velocizza la creazione del pod.
  • Ti consente di eseguire la tua analisi delle vulnerabilità.
  • Evita i limiti imposti dai registri pubblici sulla frequenza con cui puoi inviare comandi.

Prima di iniziare

  • Devi avere configurato un server di registry dei container nella tua rete.
  • Se il server del registry esegue un certificato TLS privato, devi disporre del file dell'autorità di certificazione (CA).
  • Se il server del registry richiede l'autenticazione, devi disporre delle credenziali di accesso o del file di configurazione Docker appropriate.
  • Per utilizzare un mirror del registry, devi impostare il runtime del container su containerd.

Scarica tutte le immagini richieste per Google Distributed Cloud

Scarica la versione più recente dello strumento bmctl e del pacchetto di immagini dalla pagina Download.

Carica le immagini container sul server del registry

Carica le immagini dal pacchetto di immagini sul server del registry eseguendo:

[HTTPS_PROXY=http://PROXY_IP:PORT] ./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=REGISTRY_IP:PORT \
    [--cacert=CERT_PATH] \
    [--need-credential=false]

Sostituisci quanto segue:

  • PROXY_IP:PORT con l'indirizzo IP e la porta del proxy se hai bisogno di un proxy per caricare le immagini dalla tua workstation al server del registry.
  • VERSION con la versione del pacchetto di immagini scaricato dalla pagina Download.
  • REGISTRY_IP:PORT con l'indirizzo IP e la porta del server del registry privato.
  • CERT_PATH con il percorso del file del certificato CA se il server di registry utilizza un certificato TLS privato.

Inserisci il tuo nome utente e la password quando richiesto o seleziona un file di configurazione Docker. Se il server del registry non richiede credenziali, specifica --need-credential=false.

Per ulteriori informazioni sul comando bmctl push images, esegui:

bmctl push images --help

Utilizza il tuo spazio dei nomi

Se vuoi utilizzare il tuo spazio dei nomi nel server del registry anziché lo spazio dei nomi principale, containerd può estrarre dati da questo spazio dei nomi se fornisci l'endpoint API per il tuo registry privato in registryMirrors.endpoint. L'endpoint è in genere nel formato <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Consulta la guida dell'utente del registry privato per informazioni dettagliate.

Ad esempio, se hai accesso solo a 172.18.0.20:5000/test-namespace/, puoi utilizzare il seguente comando per caricare tutte le immagini nello spazio dei nomi test-namespace:

./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace \
    --username=<USERNAME> \
    --password=<PASSWORD> \
    --cacert <path/to/cert.crt>

Poi, nel file di configurazione del cluster, puoi aggiungere quanto segue per eseguire il pull di containerd dal namespace:

registryMirrors:
  - endpoint: https://172.18.0.20:5000/v2/test-namespace

Configurare i cluster per l'utilizzo di un mirror del registry

Puoi configurare un mirror del registry per un cluster al momento della creazione o ogni volta che aggiorni un cluster esistente. Il metodo di configurazione utilizzato dipende dal tipo di cluster e, per i cluster utente, dal fatto che tu stia creando o aggiornando un cluster. Le due sezioni seguenti descrivono i due metodi disponibili per la configurazione degli specchi del registry.

Utilizza la sezione di intestazione nel file di configurazione del cluster

Google Distributed Cloud ti consente di specificare i mirror del registry al di fuori della specifica del cluster, nella sezione dell'intestazione del file di configurazione del cluster:

  • Per i cluster di amministrazione, ibrida e autonomi, l'unico modo per configurare un mirror del registry è utilizzare la sezione di intestazione nel file di configurazione del cluster. Questo metodo si applica alla creazione o agli aggiornamenti dei cluster.

  • Per i cluster utente, puoi utilizzare questo metodo per configurare un mirroring del Registro di sistema solo durante la creazione del cluster. In alternativa, per configurare un mirroring del Registro di sistema per un cluster utente esistente, utilizza la sezione nodeConfig.registryMirrors nella specifica del cluster.

Il seguente file di configurazione del cluster di esempio specifica che le immagini devono essere recuperate da un mirror del registry locale il cui endpoint è https://172.18.0.20:5000. Alcuni dei campi visualizzati all'inizio di questo file di configurazione sono descritti nelle sezioni seguenti.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://172.18.0.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

Utilizza la sezione nodeConfig.registryMirrors nella specifica del cluster

Questo metodo per creare o aggiornare un mirror del registry si applica solo ai cluster di utenti. Poiché puoi condividere i secret creati per il cluster di gestione con il tuo cluster utente, puoi utilizzare nodeConfig.registryMirrors dal cluster di gestione amministrativo o ibrida per specificare il mirroring del Registro di sistema nella specifica del cluster per il cluster utente.

Per configurare un cluster utente in modo che utilizzi lo stesso mirroring del Registro di sistema del cluster di amministrazione, segui questi passaggi:

  1. Recupera la sezione nodeConfig.registryMirror, inclusi i riferimenti ai secret, da nodeConfig.registryMirrors della risorsa cluster di amministrazione:

    kubectl get CLUSTER_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG \
    -o yaml

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster di amministrazione o ibrido che gestisce il cluster di utenti.

    • CLUSTER_NAMESPACE: il nome dello spazio dei nomi per il cluster di gestione.

    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di gestione.

  2. Aggiungi la configurazione nodeConfig.registryMirrors dal cluster di amministrazione al file di configurazione del cluster del cluster utente.

    La sezione registryMirrors nel file di configurazione del cluster utente dovrebbe essere simile all'esempio seguente:

    ---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  nodeConfig:
    containerRuntime: containerd
    registryMirrors:
    -   caCertSecretRef:
        name: the-secret-created-for-the-admin-cluster
        namespace: anthos-creds
      endpoint: https://172.18.0.20:5000
      hosts:
        -   somehost.io
        -   otherhost.io
      pullCredentialSecretRef:
        name: the-image-pull-creds-created-for-the-admin-cluster
        namespace: anthos-creds
...

Per apportare modifiche successive alla configurazione del mirroring del Registro di sistema per il cluster di utenti, modifica nodeConfig.registryMirrors nel file di configurazione del cluster di utenti e applica le modifiche con bmctl update.

Non puoi utilizzare la sezione dell'intestazione del file di configurazione del cluster per aggiornare la configurazione dei mirror del registry per un cluster di utenti.

Campo hosts

containerd controlla la sezione hosts del file di configurazione del cluster per scoprire quali host sono sottoposti a mirroring localmente. Nel file di configurazione di esempio, i registry pubblici elencati nella sezione hosts sono somehost.io e otherhost.io. Poiché questi registri pubblici vengono visualizzati nella sezione hosts, containerd controlla prima il mirror del registry privato quando rileva richieste di pull per le immagini da somehost.io o otherhost.io.

Ad esempio, supponiamo che containerd riceva un comando pull per somehost.io/kubernetes-e2e-test-images/nautilus:1.0. Poiché somehost.io è elencato come uno degli host nella sezione hosts del file di configurazione del cluster, containerd cerca l'immagine kubernetes-e2e-test-images/nautilus:1.0 nel mirror del registry locale. Se somehost.io non è elencato nella sezione hosts, containerd non sa che esiste un mirror locale di somehost.io. In questo caso, containerd non controlla se l'immagine è presente nel mirror e la estrae dal registry pubblico somehost.io.

Tieni presente che per impostazione predefinita, Google Distributed Cloud esegue automaticamente il mirroring delle immagini da gcr.io, quindi non è necessario elencare gcr.io come host nella sezione hosts.

Campo gcrKeyPath

Se vuoi che Google Distributed Cloud utilizzi automaticamente Container Registry (gcr.io) per estrarre le immagini che non compaiono nel tuo registry locale, devi specificare il percorso della chiave dell'account di servizio Container Registry. Google Distributed Cloud non dispone di un meccanismo per fornire chiavi per altri registrar pubblici.

Se non prevedi di utilizzare la funzionalità in cui le immagini vengono estratte da gcr.io quando non vengono visualizzate nel tuo registry locale, non devi aggiungere un gcrKeyPath al file di configurazione del cluster.

Campo caCertPath

Se il registry richiede un certificato TLS (Transport Layer Security) privato, questo campo prende il percorso del file del certificato CA radice del server. Questo file del certificato deve trovarsi sulla workstation di amministrazione, la macchina su cui vengono eseguiti i comandi bmctl. Se il tuo registry non richiede un certificato TLS privato, puoi lasciare vuoto il campo caCertPath.

Campo pullCredentialConfigPath

Se il server del registry non richiede un file di configurazione Docker per l'autenticazione, puoi lasciare vuoto il campo pullCredentialConfigPath. Tieni presente che si tratta del percorso del file di configurazione sulla macchina su cui vengono eseguiti i comandi bmctl.

Utilizzare un mirror del registry con i cluster utente

I cluster utente non estraggono automaticamente le immagini da un mirroring del Registro di sistema, se il cluster di amministrazione è stato configurato. Per fare in modo che i cluster utente estraggano le immagini da un mirroring del Registro di sistema, devi configurarli singolarmente come descritto in Configurare i cluster per l'utilizzo di un mirroring del Registro di sistema.

Aggiorna gli endpoint di mirroring del registry, i certificati e le credenziali di pull

Per aggiornare gli endpoint di mirroring del registry, i certificati o le credenziali pull:

  1. Nel file di configurazione del cluster, aggiorna l'endpoint, il file del certificato CA e il percorso del file di configurazione delle credenziali pull.

  2. Applica le modifiche eseguendo:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME con il nome del cluster da aggiornare.

    • ADMIN_KUBECONFIG con il percorso del file di configurazione del cluster di amministrazione.

Verificare che le immagini vengano estratte dal mirror del registry

Puoi determinare se containerd estrae le immagini dal tuo registry locale esaminando i contenuti di un file config.toml, come mostrato nei passaggi che seguono:

  1. Accedi a un nodo ed esamina i contenuti del seguente file: /etc/containerd/config.toml

  2. Controlla la sezione plugins."io.containerd.grpc.v1.cri".registry.mirrors del file config.toml per verificare se il tuo server di registry è elencato nel campo endpoint. Ecco un estratto di un file config.toml di esempio in cui il campo endpoint è visualizzato in grassetto:

    version = 2
root = "/var/lib/containerd"
state = "/run/containerd"
...
[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.configs]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
      [plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
        ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
      endpoint = ["http://privateregistry.io", "http://privateregistry2.io"]
...

    Se il mirror del registry viene visualizzato nel campo endpoint, il nodo sta estraendo le immagini dal mirror del registry anziché da un registry pubblico.