Puoi configurare il tuo cluster Google Distributed Cloud in modo che i relativi nodi worker possano utilizzare i registry privati. I registry privati a livello di nodo sono destinati all'uso con i carichi di lavoro per offrirti un maggiore controllo sui tiri delle immagini e sulla relativa sicurezza. Quando configuri un cluster con i registry privati come descritto
in questo documento, Google Distributed Cloud aggiorna la configurazione di containerd
di conseguenza. Una volta configurato il cluster, tutti i pod sui nodi idonei possono utilizzare i registry senza dover specificare imagePullSecrets
nella specifica del pod.
Questa funzionalità può essere attivata o disattivata in qualsiasi momento nel ciclo di vita del cluster.
Il seguente elenco mostra la fase di lancio di questa funzionalità per versione:
- 1.30 e versioni successive: GA
- 1.29: Anteprima
Prerequisiti
1.30 e versioni successive
Per utilizzare questa funzionalità di GA, il cluster deve soddisfare i seguenti requisiti:
- La versione del cluster deve essere 1.30 o successiva.
- La versione del pool di nodi deve essere 1.29 o successiva (un cluster 1.30 può avere pool di nodi nella versione 1.28, ma la funzionalità funziona solo per i pool di nodi nella versione 1.29 o successiva).
Questa funzionalità è destinata ai cluster utente e ai cluster autogestiti (ibridi e autonomi) con pool di nodi worker, come mostrato nella seguente tabella:
Modello di deployment Tipi di cluster supportati Deployment dei cluster di amministrazione e utente Cluster di amministrazione
Cluster di utenti 1
Cluster di utenti 2
Deployment di cluster ibridi Cluster ibrido
Cluster di utenti 1
Cluster di utenti 2
Deployment di cluster autonomi Cluster autonomo
1,29
Per utilizzare questa funzionalità di anteprima, il cluster deve soddisfare i seguenti requisiti:
- La versione del cluster deve essere 1.29.
- La versione del node pool deve essere 1.29 (non è necessario che tutti i node pool siano nella versione 1.29, ma la funzionalità funziona solo per i node pool nella versione 1.29).
- Il cluster deve avere l'annotazione della funzionalità di anteprima
preview.baremetal.cluster.gke.io/private-registry: "enable"
. Questa funzionalità è destinata ai cluster utente e ai cluster autogestiti (ibridi e autonomi) con pool di nodi worker, come mostrato nella seguente tabella:
Modello di deployment Tipi di cluster supportati Deployment dei cluster di amministrazione e utente Cluster di amministrazione
Cluster di utenti 1
Cluster di utenti 2
Deployment di cluster ibridi Cluster ibrido
Cluster di utenti 1
Cluster di utenti 2
Deployment di cluster autonomi Cluster autonomo
Configurare un cluster autonomo per i registry privati
Per configurare un cluster autonomo o ibrido in modo che utilizzi i registry privati a livello di nodo:
Modifica il file di configurazione del cluster per aggiungere il blocco
privateRegistries
nella sezione delle credenziali:--- gcrKeyPath: baremetal/gcr.json sshPrivateKeyPath: .ssh/id_rsa ... privateRegistries: - host: REGISTRY_HOST caCertPath: CA_CERT_PATH pullCredentialConfigPath: CREDENTIALS_FILE_PATH ... --- apiVersion: v1 kind: Namespace metadata: name: cluster-hybrid-basic --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: hybrid-basic namespace: cluster-hybrid-basic annotations: preview.baremetal.cluster.gke.io/private-registry: "enable" # Version 1.29 clusters only ... spec: type: hybrid ...
Sostituisci quanto segue:
REGISTRY_HOST
: il nome di dominio o l'indirizzo IP del registry privato e la porta. Ad esempio:10.200.0.2:5007
.CA_CERT_PATH
: il percorso del file del certificato CA (CA radice del server). Ad esempio:/root/cert.pem
. Se il tuo registry privato non richiede un certificato TLS privato, puoi omettere questo campo.CREDENTIALS_FILE_PATH
: il percorso del file di configurazione Docker,config.json
(ad esempio,$HOME/.docker/config.json
). Per autenticare Docker per accedere al tuo registry privato,config.json
deve contenere una versione codificata in base64 delle tue credenziali nella sezioneauths
del file. Per compilare correttamente la sezioneauths
, puoi seguire le istruzioni riportate in Chiave account di servizio nella documentazione di Artifact Registry. Per difendere i dati sensibili, puoi utilizzarechown
echmod
per limitare l'accesso al file di configurazione di Docker se contiene credenziali.Se il server del registry privato non richiede credenziali per l'autenticazione, puoi omettere il campo
pullCredentialConfigPath
.
Applica le modifiche al cluster:
bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster da aggiornare.CLUSTER_KUBECONFIG
: percorso del file kubeconfig del cluster autonomo (ibrido o autonomo).
Configura un cluster utente per i registry privati
Con i cluster utente, la configurazione del registry privato è specificata nella specifica della risorsa del cluster utente, che si trova nel cluster di amministrazione. Inoltre, devi memorizzare le credenziali del registry privato in un secret, che si trova anche nel cluster di amministrazione:
Crea un secret di Kubernetes di tipo
kubernetes.io/dockerconfigjson
per le credenziali del registry:Se vuoi limitare l'ambito del segreto a uno spazio dei nomi specifico, aggiungi il flag
--namespace
al seguente comando per specificare il nome dello spazio dei nomi. Se il segreto non si trova nello stesso spazio dei nomi del cluster, aggiungi l'annotazionebaremetal.cluster.gke.io/mark-source: "true"
, come mostrato nell'esempio alla fine di questo passaggio.kubectl create secret docker-registry CREDS_SECRET_NAME \ --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \ --kubeconfig=ADMIN_KUBECONFIG
Sostituisci quanto segue:
CREDS_SECRET_NAME
: il nome del secret.CREDENTIALS_FILE_PATH
: il percorso del file di configurazione Docker,config.json
(ad esempio,$HOME/.docker/config.json
). Per autenticare Docker per accedere al tuo registry privato,config.json
deve contenere una versione codificata in base64 delle tue credenziali nella sezioneauths
del file. Per compilare correttamente la sezioneauths
, puoi seguire le istruzioni riportate in Chiave account di servizio nella documentazione di Artifact Registry. Per difendere i dati sensibili, puoi utilizzarechown
echmod
per limitare l'accesso al file di configurazione di Docker se contiene credenziali.Se il server del registry privato non richiede credenziali per l'autenticazione, puoi omettere il campo
pullCredentialConfigPath
.
Il tuo segreto dovrebbe essere simile all'esempio seguente:
apiVersion: v1 data: .dockerconfigjson: ewoJImF1dGhzIjogewoJ...clpYSXdNak14IgoJCX0KCX0KfQ== kind: Secret metadata: creationTimestamp: "2024-04-28T22:06:06Z" name: private-registry-secret namespace: default resourceVersion: "5055821" ... annotations: ... baremetal.cluster.gke.io/mark-source: "true" type: kubernetes.io/dockerconfigjson
Se applicabile, memorizza il certificato CA per il registry in un secret.
Il segreto è simile al seguente:
apiVersion: v1 kind: Secret metadata: annotations: baremetal.cluster.gke.io/mark-source: "true" name: ca-9dd74fd308bac6df562c7a7b220590b5 namespace: some-namespace type: Opaque data: ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2RENDQXFTZ0F3SUJBZ0lVQi 3UGxjUzVFVk8vS0xuYjZiMHRhRFVleXJvd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2ZqRUxNQWtHQ ... QnpPTkxTRFZJVk5LMm9YV1JvNEpJY0ZoNFZ4MWRMRHpqMldEaHhrUEljWEhLdGR3dk5iS2tocU LUVORCBDRVJUSUZJQ0FURS0tLS0tCg== ```
Modifica il file di configurazione del cluster utente per attivare e configurare il registry privato:
Solo per i cluster della versione 1.29, aggiungi l'annotazione della funzionalità Anteprima
preview.baremetal.cluster.gke.io/private-registry: "enable"
per attivarla. Per i cluster della versione 1.30 e successive, la funzionalità del registry privato è abilitata per impostazione predefinita.apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user-basic namespace: cluster-user-basic resourceVersion: "766027" annotations: ... preview.baremetal.cluster.gke.io/private-registry: "enable" ...
Nella sezione
nodeConfig
del file di configurazione del cluster utente, aggiungi il bloccoprivateRegistries
:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user-basic ... spec: bypassPreflightCheck: false ... nodeConfig: containerRuntime: containerd podDensity: maxPodsPerNode: 250 privateRegistries: - caCertSecretRef: name: CA_CERT_SECRET_NAME namespace: CA_CERT_SECRET_NAMESPACE host: REGISTRY_HOST pullCredentialSecretRef: name: CREDS_SECRET_NAME namespace: CREDS_SECRET_NAMESPACE
Sostituisci quanto segue:
CA_CERT_SECRET_NAME
: il nome del secret che hai creato per memorizzare il certificato CA. Se non hai creato questo secret,rimuovi il bloccocaCertSecretRef
.CA_CERT_SECRET_NAMESPACE
: il nome dello spazio dei nomi per il secret del certificato CA, se lo hai creato.REGISTRY_HOST
: il nome di dominio o l'indirizzo IP del registro privato e la porta. Ad esempio:10.200.0.2:5007
.CREDS_SECRET_NAME
: il nome del secret di tipokubernetes.io/dockerconfigjson
per le credenziali del registry.CREDS_SECRET_NAMESPACE
: il nome dello spazio dei nomi per il segreto per le credenziali del registry.
Applica le modifiche al cluster:
bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
Sostituisci quanto segue:
USER_CLUSTER_NAME
: il nome del cluster che stai aggiornando.ADMIN_KUBECONFIG
: percorso del file kubeconfig del cluster di amministrazione.