Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzare un mirror del registry per le immagini container

Questa pagina spiega come creare ed eseguire l'upgrade dei cluster utilizzando immagini estratte da un del registro anziché da un registro pubblico, come gcr.io. Questo la funzionalità può essere abilitata o disabilitata in qualsiasi momento durante il 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 dello spazio di archiviazione. Per scoprire di più sui modelli ruoli e attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, vedi Ruoli e attività utente comuni di GKE Enterprise.

Un mirror del registro è una copia locale di un registro pubblico che esegue il mirroring o il mirroring la struttura dei file del registro pubblico. Ad esempio, supponiamo che il percorso al tuo mirror del registro locale è 172.18.0.20:5000. Quando containerd quando rileva una richiesta di pull di un'immagine, gcr.io/kubernetes-e2e-test-images/nautilus:1.0, containerd tenta di eseguire il pull dell'immagine, non di gcr.io, ma del tuo registro locale nel seguente percorso: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Se l'immagine non si trova in questo percorso del registro locale, l'immagine viene estratta automaticamente registro pubblico gcr.io.

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

Ti protegge da interruzioni del registry pubblico.
Velocizza la creazione del pod.
Consente di eseguire l'analisi delle vulnerabilità in autonomia.
Evita i limiti imposti dai registri pubblici sulla frequenza di emissione i comandi.

Prima di iniziare

Devi aver configurato un server Container Registry nella tua rete.
Se il server del registry esegue un certificato TLS privato, devi disporre dell'autorità di certificazione (CA).
Se il server del registry richiede l'autenticazione, devi disporre delle credenziali di accesso corrette le credenziali o il file di configurazione Docker.
Per utilizzare un mirroring del registro, 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 dal Pagina Download.

Carica le immagini container sul server del registry

Carica le immagini dal pacchetto di immagini nel 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 se hai bisogno di un proxy per caricare le immagini dalla workstation registry server.
VERSION con la versione del pacchetto di immagini scaricato dalla pagina Download.
REGISTRY_IP:PORT con l'indirizzo IP e la porta di il 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 una configurazione Docker . Se il server del registry non richiede credenziali, specifica --need-credential=false.

Per maggiori 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>. Controllo della tua guida dell'utente del registry privato per dettagli specifici.

Ad esempio, se hai accesso solo a 172.18.0.20:5000/test-namespace/, puoi utilizzare il comando seguente 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>

Quindi, nel file di configurazione del cluster, puoi aggiungere quanto segue per Esegui il pull di containerd dallo spazio dei nomi:

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

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

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 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
...

Campo `hosts`

containerd controlla la sezione hosts del file di configurazione del cluster per e scoprire quali host vengono sottoposti a mirroring in locale. 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. Perché somehost.io sta elencato come uno degli host nella sezione hosts della configurazione del cluster file, containerd cerca nel mirror del registro locale kubernetes-e2e-test-images/nautilus:1.0 immagine. 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 lo specchio l'immagine ed estrae l'immagine dal registro pubblico somehost.io.

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

Campo `gcrKeyPath`

Se vuoi che Google Distributed Cloud utilizzi automaticamente Container Registry (gcr.io) per eseguire il pull delle immagini che non vengono visualizzate nel tuo registro locale, devi e specificare il percorso della chiave dell'account di servizio di 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 endpoint di mirroring del registro, certificati e credenziali di pull

Per aggiornare gli endpoint di mirroring del registro, i certificati o le credenziali per il pull:

Nel file di configurazione del cluster, aggiorna l'endpoint, il file del certificato CA e il percorso del file di configurazione delle credenziali di pull.
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 rispettivo cluster di amministrazione di configurazione del deployment.

Verificare che le immagini vengano estratte dal mirror del registry

Questa sezione descrive due metodi che puoi utilizzare per verificare se containerd è mediante il pull di immagini dal mirror del registro locale invece che da un registro di sistema.

Metodo 1: confronta le sintesi del repository

Questo metodo prevede il confronto dei digest del repository per determinare se un'immagine è stata estratta dal mirror del registry.

Tieni presente che un registro ha un identificatore univoco chiamato repository digest, mentre un'immagine ha un identificatore univoco chiamato digest dell'immagine container. Due immagini identiche hanno lo stesso digest dell'immagine del contenitore, anche se provengono da registry diversi. Tuttavia, se le immagini provengono da registry diversi, hanno digest del repository diversi.

Accedi a un nodo del cluster mediante SSH.
Scegli un'immagine di cui vuoi verificare l'origine.
Esegui il pull dell'immagine dal registry pubblico che utilizzi eseguendo il seguente comando:
```
crictl pull PUBLIC_ENDPOINT
```
Sostituisci PUBLIC_ENDPOINT con il percorso dell'immagine nella un registry pubblico. Ad esempio: gcr.io/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.
Esegui il pull della stessa immagine dal mirror del registro eseguendo questo comando :
```
crictl pull MIRROR_ENDPOINT
```
Sostituisci MIRROR_ENDPOINT con il percorso dell'immagine in del registro di sistema. Ad esempio: 10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.
Esegui il seguente comando per visualizzare i digest del repository delle due immagini che hai estratto nei passaggi precedenti:
```
crictl inspecti PUBLIC_OR_MIRROR_ENDPOINT | grep -A 3 repoDigests
```
Sostituisci PUBLIC_OR_MIRROR_ENDPOINT con l'endpoint pubblico dell'immagine o con l'endpoint del mirror del registry dell'immagine. Puoi scegliere uno dei due, perché il comando crictl inspecti esamina il digest dell'immagine del contenitore dell'argomento che gli passi. Poiché l'immagine pubblica di un registro è identico all'immagine del mirror del registro, entrambi hanno lo stesso digest dell'immagine container.

L'output del comando potrebbe essere simile al seguente:
```
"repoDigests": [
  "gcr.io/anthos-baremetal-release/kube-rbac-proxy@sha256:
  27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3",
  "10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy@sha256:
  27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3"
],
```
Confronta i digest del repository visualizzati in grassetto nell'output del passaggio precedente. Se i digest sono identici, significa che i nodi del cluster stanno estraendo i dati dal mirror del registry. In caso contrario, i nodi del cluster estraggono le immagini da un registry pubblico.

Metodo 2: esamina il file `config.toml`

Puoi determinare se containerd sta estraendo immagini dalla tua area il registry esaminando i contenuti di un file config.toml come mostrato nel seguenti passaggi:

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

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 registro viene visualizzato nel campo endpoint, il nodo è eseguendo il pull delle immagini dal mirror del registro anziché da un registro pubblico.