Versione 1.8. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.9, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.9.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Installazione dei cluster Anthos su Bare Metal utilizzando un mirroring del registro

Questa pagina mostra come installare i cluster Anthos su Bare Metal utilizzando uno specchio del Registro di sistema anziché utilizzare gcr.io. Per utilizzare un mirroring del Registro di sistema, devi impostare il runtime del container su containerd.

I mirroring del registro sono progettati per eseguire il mirroring di tutti i componenti di gcr.io, non solo di gcr.io/anthos-baremetal-release/, che è il luogo in cui sono solitamente archiviati i cluster Anthos sulle immagini bare metal.

Ad esempio, se provi a eseguire il pull di un'immagine gcr.io/kubernetes-e2e-test-images/nautilus:1.0, funziona solo se il servizio del Registro di sistema utilizza questa immagine nello stesso percorso, ad esempio 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Tutte le immagini non gcr.io continueranno a funzionare normalmente, ad esempio è ancora possibile eseguire il pull k8s.gcr.io/pause:3.1.

L'uso di un mirroring del Registro di sistema ti aiuta a risparmiare sul traffico e offre un'alternativa all'utilizzo di gcr.io nel caso in cui sia necessario isolare i cluster da interruzioni di gcr.io. Ti permette anche di condurre la tua analisi delle vulnerabilità autonomamente.

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.

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

Scarica la versione più recente dello strumento e del pacchetto di immagini bmctl 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_1.8.0.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.
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

Utilizzo del tuo spazio dei nomi

Se vuoi utilizzare il tuo spazio dei nomi nel server di registro anziché nello spazio dei nomi root, containerd può estrarre da questo spazio dei nomi secondario 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_1.8.0.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace
    --username=<USERNAME>
    --password=<PASSWORD>
    --cacert <path/to/cert.crt>

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

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

Crea cluster dal mirroring del registro

Di seguito è riportato un file di configurazione del cluster di esempio che utilizza il tuo server di mirroring del registro anziché gcr.io.

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

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

Per informazioni dettagliate sulla creazione dei cluster, vedi Creazione di cluster.

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

Tutti i nodi in questo cluster utilizzeranno questo mirroring del Registro di sistema 172.18.0.20:5000 anziché gcr.io.

Failover su `gcr.io`

Se il tuo cluster non riesce a eseguire il pull dal mirroring del registry, verrà eseguito il failover automatico in gcr.io. Ecco perché consigliamo di fornire un valore per gcrKeyPath nel file di configurazione del cluster. Se non viene fornito un valore, il cluster non può eseguire il pull da gcr.io nel caso in cui il mirroring del Registro di sistema abbia esito negativo.

Se non hai bisogno della funzionalità di failover pull, non devi aggiungere un gcrKeyPath o aggiungere gcr.io all'elenco di autorizzazioni proxy.

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.