Utilizzare un mirroring del Registro di sistema per creare cluster

In questa pagina viene spiegato come creare cluster utilizzando immagini recuperate da uno specchio del Registro di sistema anziché da un registro pubblico, come gcr.io.

Un mirroring del registro è una copia locale di un registro pubblico che copia o rispecchia la struttura del file del registro pubblico. Ad esempio, supponiamo che il percorso del mirror del Registro di sistema 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 di quell'immagine, non di gcr.io, ma del 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 di sistema locale, viene estratta automaticamente dal registro pubblico gcr.io.

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

  • Protegge dalle interruzioni del registro pubblico.
  • Velocizza la creazione dei pod.
  • Consente di effettuare l'analisi delle vulnerabilità.
  • Evita i limiti imposti dai registri pubblici sulla frequenza con cui puoi eseguire comandi.

Prima di iniziare

  • Devi avere un server Container Registry configurato nella tua rete.
  • Se il server di registro esegue un certificato TLS privato, devi disporre del file dell'autorità di certificazione (CA).
  • Se il server di registro 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 Cluster Anthos on bare metal

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

Carica le immagini container sul server di registro

Carica le immagini dal pacchetto di immagini sul server di registro eseguendo questa operazione:

[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 ti serve un proxy per caricare le immagini dalla tua workstation nel server del Registro di sistema.
  • VERSION con la versione del pacchetto di immagini scaricata dalla pagina Download.
  • REGISTRY_IP:PORT con l'indirizzo IP e la porta del server del Registro di sistema 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 di registro non richiede credenziali, specifica --need-credential=false.

Per ulteriori informazioni sul comando bmctl push images, esegui:

bmctl push images --help

Usa il tuo spazio dei nomi

Se vuoi utilizzare il tuo spazio dei nomi nel server del registro anziché nello spazio dei nomi root, containerd può eseguire il pull da questo spazio dei nomi se fornisci l'endpoint API per il registro privato in registryMirrors.endpoint. In genere l'endpoint è nel formato <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Controlla la 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 questo 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>

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 di sistema

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 riportati 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 sono 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 registry pubblici vengono visualizzati nella sezione hosts, containerd controlla prima il mirror del registro privato quando rileva richieste di pull per immagini da somehost.io o otherhost.io.

Supponiamo, ad esempio, che containerd riceva un comando pull a 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 un mirroring locale di somehost.io. In questo caso, containerd non controlla il mirroring dell'immagine e recupera semplicemente l'immagine dal registro pubblico somehost.io.

Tieni presente che per impostazione predefinita, Cluster Anthos on bare metal esegue il mirroring automatico delle immagini da gcr.io, quindi non è 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 eseguire il pull delle immagini che non vengono visualizzate nel registro locale, devi specificare il percorso alla 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 registry pubblici.

Se non prevedi di utilizzare la funzionalità di 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 registry 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 un cluster utente dal mirror del Registro di sistema

I cluster utente non estraggono automaticamente le immagini da un mirroring del registry se il loro cluster di amministrazione è configurato per farlo. Per eseguire il pull dei cluster utente da un mirroring del registry, devi configurare questi cluster singolarmente, come descritto in Creare cluster dal mirror del registry.

Aggiornare gli endpoint del mirroring del registro, i certificati e le credenziali pull

Per aggiornare le credenziali degli endpoint del registro, 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. Per applicare le modifiche, esegui 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 siano state sottoposte a mirroring dal registry

In questa sezione vengono descritti due metodi che puoi utilizzare per verificare se containerd esegue il pull delle immagini dal mirror 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 mirror del registro.

Ricorda che un registry ha un identificatore univoco chiamato digest del 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 provengono da registry diversi. Tuttavia, se le immagini provengono da registry diversi, hanno diversi digest di repository.

  1. Accedi a un nodo del cluster tramite SSH.

  2. Scegli un'immagine di cui vuoi verificare l'origine.

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

  4. Esegui il pull della stessa immagine dal mirroring del Registro di sistema eseguendo questo comando:

    crictl pull MIRROR_ENDPOINT

    Sostituisci MIRROR_ENDPOINT con il percorso dell'immagine nel mirroring del Registro di sistema. Ad esempio: 10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0.

  5. Esegui questo comando per visualizzare i digest del repository delle due immagini recuperate 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. Uno è valido perché il comando crictl inspecti esamina il digest dell'immagine container dell'argomento passato. Poiché l'immagine del registro pubblico è identica a quella del mirror 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"
 ],

  6. Confronta i diges del repository che appaiono in grassetto nell'output del passaggio precedente. Se i digest sono identici, i nodi nel cluster stanno eseguendo il pull dal mirror del Registro di sistema. In caso contrario, i nodi del cluster estraggono le 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:

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