Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzare un mirroring del registro per creare cluster

Questa pagina spiega come creare cluster utilizzando immagini recuperate da un mirroring del registry anziché da un registro pubblico, come gcr.io.

Un mirroring del registro è una copia locale di un registro pubblico che copia o esegue il mirroring della struttura del file del registro pubblico. Ad esempio, ipotizziamo che il percorso verso il mirroring del registro locale sia 172.18.0.20:5000. Quando containerd rileva una richiesta di pull di un'immagine, ad esempio gcr.io/kubernetes-e2e-test-images/nautilus:1.0, containerd tenta di eseguire il pull dell'immagine, non di gcr.io, ma del registry locale sul seguente percorso: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Se l'immagine non è presente in questo percorso del registro di sistema locale, l'immagine viene estratta automaticamente dal registro pubblico gcr.io.

L'utilizzo di un mirroring del Registro di sistema offre i seguenti vantaggi:

Ti protegge dalle interruzioni pubbliche.
Velocizza la creazione dei pod.
Ti permette di condurre la tua analisi delle vulnerabilità autonomamente.
Evita i limiti imposti dai registry pubblici per la frequenza di emissione di comandi.

Prima di iniziare

Devi avere un server Container Registry configurato nella tua rete.
Se il tuo server del Registro di sistema esegue un certificato TLS privato, devi disporre del file dell'autorità di certificazione (CA).
Se il tuo server del Registro di sistema richiede l'autenticazione, devi disporre delle credenziali di accesso o del file di configurazione Docker corretti.
Per utilizzare un mirroring del Registro di sistema, devi impostare il runtime del container su containerd.

Scarica tutte le immagini richieste per i cluster Anthos su Bare Metal

Scarica l'ultima versione dello strumento bmctl e del pacchetto di immagini dalla pagina Download.

Caricare immagini container sul server di registro

Carica le immagini dal pacchetto di immagini sul server di registro eseguendo questo comando:

[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 ne hai bisogno, per caricare le immagini dalla workstation al server di registro.
VERSION con la versione del pacchetto di immagini scaricata dalla pagina Download.
REGISTRY_IP:PORT con l'indirizzo IP e la porta del server registro privato.
CERT_PATH con il percorso del file del certificato CA se il server di registro 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 Registro di sistema non richiede credenziali, specifica --need-credential=false.

Per ulteriori informazioni sul comando bmctl push images, esegui:

bmctl push images --help

Utilizzare il proprio spazio dei nomi

Se vuoi utilizzare il tuo spazio dei nomi nel server di registro anziché nello spazio dei nomi root, containerd può eseguire il pull da questo spazio dei nomi se fornisci l'endpoint API per il tuo registro privato in registryMirrors.endpoint. Il formato dell'endpoint è in genere <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Per i dettagli specifici, consulta la guida utente del registry privato.

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>

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

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

Crea cluster dal mirroring del registro

Il seguente file di configurazione del cluster di esempio specifica che le immagini devono essere estratte da un mirroring del registro di sistema 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
...

Campo `hosts`

containerd controlla la sezione hosts del file di configurazione del cluster per scoprire quali host vengono sottoposti a mirroring localmente. Nel file di configurazione di esempio, i registri pubblici elencati nella sezione hosts sono somehost.io e otherhost.io. Poiché questi registri pubblici vengono visualizzati nella sezione hosts, containerd controlla prima il mirroring del registro 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 mirroring del Registro di sistema locale. Se somehost.io non è presente nella sezione hosts, containerd non sa che esiste uno specchio locale di somehost.io. In questo caso, containerd non controlla l'immagine speculare e si limita a estrarre l'immagine dal registro pubblico somehost.io.

Tieni presente che, per impostazione predefinita, i cluster Anthos su Bare Metal riflettono automaticamente le immagini da gcr.io in modo che non sia necessario elencare gcr.io come host nella sezione hosts.

Campo `gcrKeyPath`

Se vuoi che i cluster Anthos su Bare Metal utilizzino automaticamente Container Registry (gcr.io) per estrarre immagini che non vengono visualizzate nel tuo registro locale, devi specificare il percorso della chiave dell'account di servizio di Container Registry. I cluster Anthos su Bare Metal non dispongono di un meccanismo per fornire le chiavi per altri registri pubblici.

Se non hai intenzione di utilizzare la funzionalità in cui le immagini vengono estratte da gcr.io quando non sono visualizzate nel tuo registro locale, non è necessario aggiungere un gcrKeyPath al file di configurazione del cluster.

Campo `caCertPath`

Se il tuo registro non richiede un certificato TLS privato, puoi lasciare vuoto il campo caCertPath.

Campo `pullCredentialConfigPath`

Se il server di registro non richiede un file di configurazione Docker di autenticazione, puoi lasciare vuoto il campo pullCredentialConfigPath.

Crea cluster utente dal mirroring del registro

I cluster utente non estraggono automaticamente le immagini da un mirroring del registry se il loro cluster di amministrazione è stato configurato per farlo. Per fare in modo che i cluster utente vengano recuperati da un mirroring del registro, devi configurarli singolarmente come descritto in Creare cluster dal mirroring del registro.

Aggiornare endpoint, certificati e credenziali di pull del registro

Per aggiornare le credenziali degli endpoint del registry, i certificati o le credenziali pull:

Nel file di configurazione del cluster, aggiorna l'endpoint, il file del certificato CA e il percorso del file di configurazione delle credenziali pull.
Applica le modifiche eseguendo questo comando:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME con il nome del cluster che vuoi aggiornare.
- ADMIN_KUBECONFIG con il percorso del file di configurazione del cluster di amministrazione.

Verifica che le immagini vengano estratte dal mirroring del registro

In questa sezione vengono descritti due metodi che puoi utilizzare per verificare se containerd esegue il pull delle immagini dal mirroring del registro locale anziché da un registro pubblico.

Metodo n. 1: confronta i digest del repository

Questo metodo comporta il confronto dei digest del repository per determinare se un'immagine è stata estratta dal mirroring del registro.

Tieni presente che un registry ha un identificatore univoco chiamato digest di repository e un'immagine ha un identificatore univoco chiamato digest dell'immagine container. Due immagini identiche hanno lo stesso digest delle immagini container, anche se le immagini provengono da registri diversi. Tuttavia, se le immagini provengono da registri diversi, questi hanno digest di repository diversi.

Accedi a un nodo del cluster tramite SSH.
Scegli un'immagine di cui vuoi verificare l'origine.
Esegui il pull dell'immagine dal registro pubblico che utilizzi eseguendo questo comando:
```
crictl pull PUBLIC_ENDPOINT
```
Sostituisci PUBLIC_ENDPOINT con il percorso dell'immagine nel registro pubblico. Ad esempio: gcr.io/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.
Esegui il pull della stessa immagine dal mirroring del registro eseguendo il comando seguente:
```
crictl pull MIRROR_ENDPOINT
```
Sostituisci MIRROR_ENDPOINT con il percorso dell'immagine nel mirroring del registro. Ad esempio: 10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.
Esegui questo comando per visualizzare i digest del repository delle due immagini di cui hai eseguito il pull 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 mirroring del registro dell'immagine. Ognuno va bene perché il comando crictl inspecti guarda il digest dell'immagine container dell'argomento che gli stai passato. Poiché l'immagine del Registro di sistema pubblico è identica all'immagine del mirroring del registry, entrambe hanno lo stesso digest dell'immagine container.

L'output del comando potrebbe avere il seguente aspetto:
```
 "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 che appaiono in grassetto nell'output del passaggio precedente. Se i digest sono identici, i nodi nel tuo cluster vengono recuperati dal tuo mirroring del registro. In caso contrario, i nodi del cluster stanno estraendo immagini da un registro pubblico.

Metodo n. 2: esamina il file `config.toml`

Puoi determinare se containerd sta estraendo immagini dal tuo registro locale esaminando i contenuti di un file config.toml come mostrato nei seguenti passaggi:

Accedi a un nodo ed esamina i contenuti del file seguente: /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 del Registro di sistema è indicato nel campo endpoint. Ecco un estratto di un file config.toml di esempio in cui il campo endpoint viene 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 nel campo endpoint viene visualizzato il mirroring del registro, il nodo esegue il pull delle immagini dal mirroring del registry anziché da un registro pubblico.