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.
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 dalle interruzioni dei registri pubblici.
- Accelera la creazione dei 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 di 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 server del registry.VERSION
con la versione del pacchetto di immagini che hai scaricati 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 del registry usa 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é
principale, containerd
può estrarre da questo spazio dei nomi se fornisci lo spazio dei nomi
Endpoint API per il tuo registro privato in registryMirrors.endpoint
. La
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
Configura i cluster per l'utilizzo di un mirror del registro
Il seguente file di configurazione del cluster di esempio specifica che le immagini devono essere
estratto da un mirror del registro 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 registri pubblici elencati nella sezione hosts
sono somehost.io
e
otherhost.io
. Poiché questi registri pubblici compaiono nella sezione hosts
,
Quando containerd
rileva il pull, verifica prima il mirroring del registro privato
richieste di 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 è presente nell'elenco
nella sezione hosts
, containerd
non sa che un mirror locale di
somehost.io
esiste. 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
registri pubblici.
Se non prevedi di utilizzare la funzionalità che utilizza le immagini estratte da gcr.io
quando non compaiono nel registry locale, non occorre aggiungere
gcrKeyPath
al file di configurazione del cluster.
Campo caCertPath
Se il registro richiede un certificato TLS (Private Transport Layer Security),
questo campo segue il percorso del file del certificato CA radice del server. Questo
il file del certificato deve trovarsi sulla workstation di amministrazione, la macchina che esegue bmctl
tramite comandi SQL. Se il registro non richiede un certificato TLS privato,
può lasciare vuoto il campo caCertPath
.
Campo pullCredentialConfigPath
Se il server del registry non richiede una configurazione Docker di autenticazione
puoi lasciare vuoto il campo pullCredentialConfigPath
. Tieni presente che
questo è il percorso del file di configurazione sulla macchina che esegue bmctl
tramite comandi SQL.
Usa un mirror del registro con i cluster utente
I cluster utente non eseguono il pull automatico delle immagini da un mirror del registro se di amministrazione di Google Cloud è stato configurato per farlo. Per fare in modo che i cluster utente eseguano il pull da del registro di sistema, è necessario configurarli singolarmente come descritto in Configura i cluster per utilizzare un mirror del registro.
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 che vuoi aggiornamento.ADMIN_KUBECONFIG
con il percorso del rispettivo cluster di amministrazione di configurazione del deployment.
Verifica che le immagini vengano estratte dal mirror del registro
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 comporta il confronto delle sintesi del repository per determinare se un'immagine di cui è stato eseguito il pull dal mirror del registro.
Tieni presente che un registro ha un identificatore univoco chiamato repository digest e un'immagine ha un identificatore univoco chiamato digest immagine container. Due immagini identiche hanno lo stesso digest dell'immagine container, anche se le immagini provengono da registri diversi. Tuttavia, se le immagini provengono da diversi nei registri, hanno varie sintesi dei repository.
Accedi a un nodo del cluster mediante 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 nella registro 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 questo comando per visualizzare le sintesi dei due repository immagini recuperate nei passaggi precedenti:
crictl inspecti PUBLIC_OR_MIRROR_ENDPOINT | grep -A 3 repoDigests
Sostituisci
PUBLIC_OR_MIRROR_ENDPOINT
con all'endpoint pubblico dell'immagine o all'endpoint di mirroring del registro dell'immagine. Entrambi va bene perché il comandocrictl inspecti
esamina l'immagine container digest dell'argomento che 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 le sintesi del repository che appaiono in grassetto nell'output passaggio precedente. Se i digest sono identici, i nodi nel tuo cluster eseguendo il pull dal mirror del registro. In caso contrario, i nodi del cluster il pull di immagini da un registro 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 il contenuto del seguente file:
/etc/containerd/config.toml
Controlla la sezione
plugins."io.containerd.grpc.v1.cri".registry.mirrors
di il fileconfig.toml
per verificare se il server del registry è elencato nelendpoint
. Ecco un estratto di un fileconfig.toml
di esempio in 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", "http://privateregistry2.io"] ...
Se il mirror del registry viene visualizzato nel campo
endpoint
, il nodo è eseguendo il pull delle immagini dal mirror del registro anziché da un registro pubblico.