Questa pagina spiega come creare e aggiornare i cluster utilizzando le immagini estratte da un mirroring del Registro di sistema anziché da un registro pubblico come gcr.io
. Questa
funzionalità può essere attivata o disattivata in qualsiasi momento del ciclo di vita del cluster.
Questa pagina è dedicata agli operatori e agli specialisti dello spazio di archiviazione che configurano e gestiscono le prestazioni, l'utilizzo e le spese dello spazio di archiviazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Google Cloud
Un mirror 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
al mirror 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
di quell'immagine non da gcr.io
, ma dal 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, viene estratta automaticamente dal
registro pubblico gcr.io
.
L'utilizzo di un mirror del registro offre i seguenti vantaggi:
- Ti protegge dalle interruzioni del registro pubblico.
- Velocizza la creazione dei pod.
- Consente di eseguire la propria analisi delle vulnerabilità.
- Evita i limiti imposti dai registri pubblici alla frequenza con cui puoi inviare comandi.
Prima di iniziare
- Nella tua rete deve essere configurato un server Artifact Registry.
- 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.
- Se utilizzi un registro Red Hat Quay, potrebbe essere necessario creare manualmente la struttura di directory del registro locale.
- Per utilizzare un mirror del registro, devi impostare il runtime del container su containerd.
- Assicurati di avere spazio su disco sufficiente sulla workstation amministrativa per supportare
i caricamenti delle immagini. Il comando di caricamento delle immagini,
bmctl push images
, decomprime il file del pacchetto di immagini scaricato ed estrae tutti i file di immagine localmente prima di caricarli. Per caricare le immagini, devi disporre di uno spazio su disco almeno tre volte superiore alle dimensioni del file del pacchetto di immagini scaricato. Ad esempio, il file compressobmpackages_1.31.200-gke.59.tar.xz
occupa circa 8,5 GB di spazio su disco, quindi devi avere almeno 25,5 GB di spazio su disco libero prima di scaricare il file.
Scarica tutte le immagini richieste per Google Distributed Cloud
Scarica l'ultima versione dello strumento bmctl
e del pacchetto di immagini dalla pagina
Download.
Carica le immagini container sul server di registro
Quando utilizzi bmctl push images
per caricare immagini container nel server del repository, bmctl
esegue i seguenti passaggi in ordine:
Decomprimi un file tar compresso di un pacchetto di immagini scaricato, ad esempio
bmpackages_1.32.200-gke.104.tar.xz
inbmpackages_1.32.200-gke.104.tar
.Estrai tutte le immagini dal file tar decompresso in una directory denominata
bmpackages_1.32.200-gke.104
.Esegui il push di ogni file immagine nel registro privato specificato.
bmctl
utilizza i valori--username
e--password
per l'autenticazione di base per eseguire il push delle immagini nel tuo registro privato.
Le sezioni seguenti illustrano alcune varianti comuni del comando bmctl push
images
per caricare immagini sul server del repository.
Esegui l'autenticazione con il registro e condividi il certificato TLS
Il seguente comando include i flag --username
e --password
per l'autenticazione
dell'utente con il server di registro. Il comando include anche il
flag --cacert
per il passaggio del certificato TLS (Transport Layer Security) della CA,
che viene utilizzato per la comunicazione sicura con il server di registro, inclusi i push
e i pull delle immagini. Questi flag forniscono una sicurezza di base per il server di registro.
Se il server di registro richiede l'autenticazione e non utilizzi i flag
--username
e --password
, ti verranno richieste le credenziali quando
esegui bmctl push images
. Puoi digitare la password o scegliere il file di configurazione Docker che contiene le credenziali.
Per caricare immagini con l'autenticazione e un certificato CA privato, utilizza un comando come il seguente:
bmctl push images \
--source IMAGES_TAR_FILE_PATH \
--private-registry REGISTRY_IP:PORT \
--username USERNAME \
--password PASSWORD \
--cacert CERT_PATH
Sostituisci quanto segue:
IMAGES_TAR_FILE_PATH
: il percorso del file tar del pacchetto di immagini scaricate, ad esempiobmpackages_1.32.200-gke.104.tar.xz
.REGISTRY_IP:PORT
: l'indirizzo IP e la porta del server del registro privato.USERNAME
: il nome utente di un utente con autorizzazioni di accesso per caricare immagini sul server di registro.PASSWORD
: la password dell'utente per l'autenticazione con il server del registro.CERT_PATH
: il percorso del file del certificato CA, se il server di registro utilizza un certificato TLS privato.
Ad esempio:
bmctl push images \
--source bmpackages_1.32.200-gke.104.tar.xz \
--private-registry 172.18.0.20:5000 \
--username alex --password pa55w0rd \
--cacert /etc/pki/tls/certs/ca-bundle.crt
Caricare immagini senza autenticazione o certificati utente
Se il server di registro non richiede credenziali, ad esempio un nome utente e una
password, specifica --need-credential=false
nel comando bmctl
. Se il server
del registro utilizza un certificato TLS pubblico, non è necessario utilizzare il flag
--cacert
. Questo tipo di comando di caricamento è più adatto agli ambienti di test, in cui la sicurezza è meno importante rispetto alla produzione.
Per caricare immagini senza autenticazione o un certificato CA privato, utilizza un comando come il seguente:
bmctl push images \
--source IMAGES_TAR_FILE_PATH \
--private-registry REGISTRY_IP:PORT \
--need-credential=false
Ad esempio:
bmctl push images \
--source bmpackages_1.32.200-gke.104.tar.xz \
--private-registry 172.18.0.20:5000 \
--need-credential=false.
Regolare il numero di thread
La routine di caricamento delle immagini può richiedere molto tempo a causa delle dimensioni e della quantità di
immagini container nel file tar del pacchetto di immagini. L'aumento del numero di thread paralleli
accelera l'esecuzione della routine. Puoi utilizzare il flag --threads
per modificare il numero di thread paralleli utilizzati da bmctl push images
.
Per impostazione predefinita, la routine di caricamento delle immagini utilizza 4 thread. Se i caricamenti delle immagini richiedono troppo tempo, aumenta questo valore. Come benchmark, in un ambiente di test Google, il caricamento delle immagini da una workstation con 4 CPU richiede circa 10 minuti con 8 thread paralleli.
bmctl push images \
--source IMAGES_TAR_FILE_PATH \
--private-registry REGISTRY_IP:PORT \
--cacert CERT_PATH \
--threads NUM_THREADS
Sostituisci NUM_THREADS
con il numero di thread paralleli
utilizzati per elaborare i caricamenti delle immagini. Per impostazione predefinita, bmctl push images
utilizza quattro
thread paralleli.
Il seguente comando aumenta il numero di thread per il caricamento da 4
a
8
per ridurre il tempo di caricamento:
bmctl push images \
--source bmpackages_1.32.200-gke.104.tar.xz \
--private-registry 172.18.0.20:5000 \
--cacert ~/cert.pem \
--threads 8
Caricamento tramite proxy
Se hai bisogno di un proxy per caricare le immagini dalla tua workstation al server di registro, puoi aggiungere i dettagli del proxy prima del comando bmctl
:
HTTPS_PROXY=http://PROXY_IP:PORT bmctl push images \
--source=IMAGES_TAR_FILE_PATH \
--private-registry=REGISTRY_IP:PORT \
--cacert=CERT_PATH
Sostituisci quanto segue:
PROXY_IP:PORT
: l'indirizzo IP e la porta del proxy.IMAGES_TAR_FILE_PATH
: il percorso del file tar del pacchetto di immagini scaricate, ad esempiobmpackages_1.32.200-gke.104.tar.xz
.REGISTRY_IP:PORT
: l'indirizzo IP e la porta del server del registro privato.CERT_PATH
: il percorso del file del certificato CA, se il server di registro utilizza un certificato TLS privato.
Inserisci il tuo nome utente e la tua password quando richiesto o seleziona un file di configurazione Docker.
Il seguente comando carica le immagini tramite un proxy:
HTTPS_PROXY=http://10.128.0.136:3128 bmctl push images \
--source bmpackages_1.32.200-gke.104.tar.xz \
--private-registry 172.18.0.20:5000 \
--cacert ~/cert.pem
Utilizzare il proprio spazio dei nomi con bmctl push images
Se vuoi utilizzare il tuo spazio dei nomi nel server di registro anziché lo spazio dei nomi radice, containerd
può eseguire il pull da questo spazio dei nomi se fornisci l'endpoint API per il tuo registro privato nel campo registryMirrors.endpoint
del file di configurazione del cluster. L'endpoint è in genere nel formato
<REGISTRY_IP:PORT>/v2/<NAMESPACE>
. Per informazioni specifiche, consulta la guida dell'utente del registro privato. Per ulteriori informazioni, consulta la sezione Informazioni sull'utilizzo di v2
nell'endpoint del registro.
bmctl push images \
--source=IMAGES_TAR_FILE_PATH \
--private-registry=REGISTRY_IP:PORT/NAMESPACE \
--cacert=CERT_PATH
Sostituisci NAMESPACE
con il nome dello spazio dei nomi nel
server di registro in cui vuoi caricare le immagini.
Ad esempio, se hai accesso solo a 198.51.20:5000/test-namespace/
, puoi utilizzare un comando come il seguente per caricare tutte le immagini nello spazio dei nomi test-namespace
:
bmctl push images \
--source=./bmpackages_1.32.200-gke.104.tar.xz \
--private-registry=198.51.20:5000/test-namespace \
--username=alex \
--password=pa55w0rd \
--cacert /etc/pki/tls/certs/ca-bundle.crt
Poi, nel file di configurazione del cluster, puoi aggiungere quanto segue per fare in modo che
containerd
estragga i dati dallo spazio dei nomi test-namespace
:
registryMirrors:
- endpoint: https://198.51.20:5000/v2/test-namespace
Per ulteriori informazioni sul comando bmctl push images
, consulta il bmctl
riferimento al comando.
Configura i cluster per utilizzare un mirror del registro
Puoi configurare un mirror del registro per un cluster al momento della creazione del cluster o ogni volta che aggiorni un cluster esistente. Il metodo di configurazione che utilizzi 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 configurare i mirror del registro.
Utilizza la sezione dell'intestazione nel file di configurazione del cluster
Google Distributed Cloud consente di specificare i mirror del registro al di fuori della specifica del cluster, nella sezione dell'intestazione del file di configurazione del cluster:
Per i cluster di amministrazione, ibridi e autonomi, l'unico modo per configurare un mirror del registro è utilizzare la sezione di intestazione nel file di configurazione del cluster. Questo metodo si applica alla creazione o agli aggiornamenti del cluster.
Per i cluster utente, puoi utilizzare questo metodo per configurare un mirroring del registro 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
estratte da un mirror del registro locale il cui endpoint è
https://198.51.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://198.51.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 di creazione o aggiornamento di un mirror del registro si applica solo ai cluster utente. Poiché puoi condividere i secret creati per il cluster di gestione con il cluster utente, puoi utilizzare nodeConfig.registryMirrors
dal cluster di amministrazione o ibrido di gestione per specificare il mirroring del registro 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:
Recupera la sezione
nodeConfig.registryMirror
, inclusi i riferimenti ai secret, danodeConfig.registryMirrors
della risorsa cluster di amministrazione:kubectl get cluster 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 utente.CLUSTER_NAMESPACE
: il nome dello spazio dei nomi per il cluster di gestione.ADMIN_KUBECONFIG
: il percorso del file kubeconfig del cluster di gestione.
Aggiungi la configurazione
nodeConfig.registryMirrors
dal cluster di amministrazione al file di configurazione del cluster utente.La sezione
registryMirrors
del 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 mirror del registro per il cluster utente, modifica nodeConfig.registryMirrors
nel file di configurazione del cluster utente e applica le modifiche con bmctl update
.
Non puoi utilizzare la sezione di intestazione del file di configurazione del cluster per aggiornare la configurazione dei mirror del registro per un cluster utente.
Campo hosts
containerd
controlla la sezione hosts
del file di configurazione del cluster per
scoprire quali host vengono sottoposti a mirroring in locale. Questi host sono mappati all'endpoint
mirror del registro specificato nel file di configurazione del cluster
(registryMirror.endpoint
). Nel file di configurazione di esempio della
sezione precedente, 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 mirror del registro privato quando
rileva richieste di pull per 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 una copia locale di
somehost.io
. In questo caso, containerd
non controlla il mirror per
l'immagine ed esegue il pull dell'immagine dal registro 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
.
I valori hosts
e endpoint
non devono sovrapporsi. Ad esempio, il seguente esempio di configurazione mostra un host, europe-docker.pkg.dev
, che corrisponde alla parte del dominio del valore dell'endpoint. In questo caso, non è necessario specificare un valore hosts
:
...
registryMirrors:
...
endpoint: https://europe-docker.pkg.dev:5000/v2/cloud-data-fusion-images
hosts:
- europe-docker.pkg.dev
...
Campo gcrKeyPath
Se vuoi che Google Distributed Cloud utilizzi automaticamente Artifact Registry
(gcr.io
) per estrarre le immagini che non vengono visualizzate nel tuo registro locale, devi
specificare il percorso della chiave del account di servizio Artifact Registry.
Google Distributed Cloud non dispone di un meccanismo per fornire chiavi per altri
registri pubblici.
Se non prevedi di utilizzare la funzionalità in cui le immagini vengono estratte da gcr.io
quando non vengono visualizzate nel registro locale, non è necessario aggiungere un
gcrKeyPath
al file di configurazione del cluster.
Campo caCertPath
Se il registro richiede un certificato TLS (Transport Layer Security) privato,
questo campo accetta il percorso del file del certificato CA radice del server. Questo
file di certificato deve trovarsi sulla workstation di amministrazione, la macchina che esegue i comandi bmctl
. Se il tuo 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 di autenticazione, puoi lasciare vuoto il campo pullCredentialConfigPath
. Tieni presente che
questo è il percorso del file di configurazione sulla macchina che esegue i comandi bmctl
.
Utilizzo di un mirror del registro 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.
Aggiorna endpoint, certificati e credenziali di pull del mirror del registro
Per aggiornare gli endpoint mirror del registro, i certificati o le credenziali di 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 file di configurazione del cluster di amministrazione.
Verifica che le immagini vengano estratte dal mirror del registro
Puoi determinare se containerd
estrae le 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 seguente file:
/etc/containerd/config.toml
Controlla la sezione
plugins."io.containerd.grpc.v1.cri".registry.mirrors
del fileconfig.toml
per verificare se il tuo server di registrazione è elencato nel campoendpoint
. Ecco un estratto di un fileconfig.toml
di esempio in cui il campoendpoint
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", "https://privateregistry2.io"] ...
Se il mirror del registro viene visualizzato nel campo
endpoint
, il nodo estrae le immagini dal mirror del registro anziché da un registro pubblico.
Risolvere i problemi relativi alle impostazioni del mirror del registro
Puoi utilizzare crictl
, lo strumento a riga di comando dell'interfaccia di runtime del container, per testare
le impostazioni del registro scaricando singoli file di immagine. Ogni file immagine viene
taggato in modo indipendente con una stringa di versione significativa. Ad esempio, l'immagine del controller API del cluster è taggata con la versione di rilascio di Google Distributed Cloud e l'immagine etcd è taggata con la versione etcd corrispondente.
Per la release 1.31.200-gke.59 di Google Distributed Cloud per bare metal,
l'immagine del controller API cluster, cluster-api-controller
, e l'immagine etcd,
etcd
, hanno i seguenti tag:
cluster-api-controller:1.31.200-gke.59
etcd:v3.4.30-0-gke.1
Esegui il pull di un'immagine dal mirror del registro
Se il mirror del registro non utilizza spazi dei nomi, utilizza il seguente comando per estrarre un'immagine:
crictl pull REGISTRY_IP:PORT/IMAGE_PATH:IMAGE_TAG
Estrai un'immagine da un mirror del registro che utilizza gli spazi dei nomi
Se il mirror del registro utilizza spazi dei nomi, utilizza il seguente comando per eseguire il pull di un'immagine:
crictl pull REGISTRY_IP:PORT/NAMESPACE/IMAGE_PATH:IMAGE_TAG
Informazioni sull'utilizzo di v2
nell'endpoint del registro
Quando il registro utilizza spazi dei nomi personalizzati, devi anteporre lo spazio dei nomi
all'endpoint del registro (registryMirror.endpoint
) nel file di configurazione del cluster
con v2/
. Se non utilizzi gli spazi dei nomi, non utilizzare v2
. In entrambi i casi,
non utilizzare v2
nel valore del flag --private-registry
o nei comandi di pull delle immagini:
Senza spazi dei nomi
- Valido:
endpoint: https://172.18.0.20:5000
crictl pull 172.18.0.20:5000/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
- Non valido:
endpoint: https://172.18.0.20:5000/v2
crictl pull 172.18.0.20:5000/v2/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
Con spazi dei nomi
- Valido:
endpoint: https://172.18.0.21:5000/v2/namespace
crictl 172.18.0.21:5000/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
- Non valido:
endpoint: https://172.18.0.21:5000/namespace
crictl pull 172.18.0.21:5000/v2/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1