Usa un mirroring del registro per creare cluster

Questa pagina spiega come creare cluster utilizzando immagini estratte da un mirroring del registro 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 dei file del registro pubblico. Ad esempio, supponiamo che il percorso del mirroring del registro locale sia 172.18.0.20:5000. Quando containerd rileva una richiesta di pull di un'immagine come gcr.io/kubernetes-e2e-test-images/nautilus:1.0, containerd tenta di eseguire il pull dell'immagine, non da gcr.io, ma dal tuo registro 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 registro locale, viene estratta automaticamente dal registro pubblico gcr.io.

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

  • Ti protegge da interruzioni del registro pubblico.
  • Velocizza la creazione dei pod.
  • Ti permette di condurre la tua analisi delle vulnerabilità.
  • Evita i limiti imposti dai registri pubblici sulla frequenza con cui puoi emettere comandi.

Prima di iniziare

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

Scarica tutte le immagini richieste per GKE su Bare Metal

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

Carica le immagini container sul server del registro

Carica le immagini dal pacchetto delle immagini sul server del registro 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 workstation al server del registro.
  • VERSION con la versione del pacchetto di immagini che hai scaricato dalla pagina Download.
  • REGISTRY_IP:PORT con l'indirizzo IP e la porta del server di registro privato.
  • CERT_PATH con il percorso del file del certificato CA se il server del 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 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é quello principale, containerd può eseguire il pull da questo spazio dei nomi se fornisci l'endpoint API per il tuo registro privato in registryMirrors.endpoint. In genere l'endpoint ha il formato <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Per informazioni dettagliate, consulta la guida dell'utente del registro 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 ricavate da un mirror del registro locale il cui endpoint è https://172.18.0.20:5000. Nelle sezioni seguenti sono descritti alcuni dei campi visualizzati all'inizio di questo file di configurazione.

# 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 verifica 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 mirror del registro 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 esegue il controllo del mirroring dell'immagine, ma esegue semplicemente il pull dell'immagine dal registro pubblico somehost.io.

Tieni presente che, per impostazione predefinita, GKE su Bare Metal 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 GKE su Bare Metal utilizzi automaticamente Container Registry (gcr.io) per eseguire il pull di immagini che non vengono visualizzate nel tuo registro locale, devi specificare il percorso della chiave dell'account di servizio di Container Registry. GKE su Bare Metal non dispone di un meccanismo per fornire chiavi per altri registry pubblici.

Se non prevedi di utilizzare la funzionalità con cui le immagini vengono estratte da gcr.io quando non vengono visualizzate nel registro locale, non è necessario aggiungere gcrKeyPath al file di configurazione del cluster.

Campo caCertPath

Se il registro richiede un certificato TLS (Private Transport Layer Security), questo campo indica il percorso al file del certificato CA radice del server. Questo file del certificato deve trovarsi sulla workstation di amministrazione, sulla macchina che esegue i comandi bmctl. Se il registro non richiede un certificato TLS privato, puoi lasciare vuoto il campo caCertPath.

Campo pullCredentialConfigPath

Se il server del registro non richiede un file di configurazione Docker per l'autenticazione, puoi lasciare vuoto il campo pullCredentialConfigPath. Tieni presente che questo è il percorso del file di configurazione sulla macchina che esegue i comandi bmctl.

Crea un cluster utente dal mirroring del registro

I cluster utente non estraggono automaticamente le immagini da un mirroring del Registro di sistema, se il cluster di amministrazione è stato configurato.

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

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

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

  2. Applica le modifiche eseguendo:

    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 relativo cluster di amministrazione.

Verifica che le immagini siano estratte dal mirroring del registro

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

Metodo 1: confronta i digest del repository

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

Tieni presente 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 di immagini container, anche se le immagini provengono da registri diversi. Tuttavia, se le immagini provengono da registri diversi, hanno digest di repository diversi.

  1. Accedi a un nodo cluster utilizzando 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 eseguendo questo comando:

    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.

  5. Esegui questo comando per visualizzare i digest del repository delle due immagini estratte 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 l'endpoint di mirroring del registro dell'immagine. Entrambi sono corretti perché il comando crictl inspecti esamina il digest dell'immagine container dell'argomento passato. Poiché l'immagine del registro pubblico è identica a quella del mirroring del registro, entrambe 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"
 ],

  6. Confronta i digest del repository visualizzati in grassetto nell'output del passaggio precedente. Se i digest sono identici, i nodi nel cluster stanno eseguendo il pull dal mirror del registro. In caso contrario, i nodi del cluster stanno eseguendo il pull delle immagini da un registro pubblico.

Metodo 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 il contenuto 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 del registro di sistema è elencato nel campo endpoint. Ecco un estratto da 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 nel campo endpoint viene visualizzato il mirroring del registro, il nodo esegue il pull delle immagini dal mirroring del registro anziché da un registro pubblico.