Configura i nodi per l'autenticazione a un registro privato

Puoi configurare il cluster Google Distributed Cloud in modo che i relativi nodi worker possano utilizzare i registri privati, incluso Artifact Registry. I registri privati a livello di nodo sono destinati all'uso con i carichi di lavoro per offrirti un maggiore controllo sui pull delle immagini e sulla relativa sicurezza. Quando configuri un cluster con i registri privati come descritto in questo documento, Google Distributed Cloud aggiorna di conseguenza la configurazione di containerd. Una volta configurato il cluster, tutti i pod sui nodi qualificati possono utilizzare i registri senza dover specificare imagePullSecrets nelle specifiche del pod.

Questa funzionalità può essere attivata o disattivata in qualsiasi momento durante il 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à GA, il cluster deve soddisfare i seguenti requisiti:

  • La versione del cluster deve essere 1.30 o successiva.
  • La versione pool di nodi deve essere 1.29 o successiva (un cluster 1.30 può avere node pool nella versione 1.28, ma la funzionalità funziona solo per i node pool nella versione 1.29 o successiva).

  • Questa funzionalità è destinata ai cluster utente e ai cluster autogestiti (ibridi e autonomi) con node pool worker, come mostrato nella tabella seguente:

    Modello di deployment Tipi di cluster supportati
    Deployment di cluster di amministrazione e utente

    Cluster di amministrazione

    Cluster utente 1

    Cluster utente 2
    Deployment di cluster ibridi

    Cluster ibrido

    Cluster utente 1

    Cluster utente 2
    Deployment di cluster autonomi

    Cluster autonomo

1.29

Per utilizzare questa funzionalità in 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 tutti i node pool devono essere nella versione 1.29, ma la funzionalità funziona solo per i node pool nella versione 1.29).
  • Il cluster deve avere l' preview.baremetal.cluster.gke.io/private-registry: "enable"annotazione della funzionalità in anteprima.

  • Questa funzionalità è destinata ai cluster utente e ai cluster autogestiti (ibridi e autonomi) con node pool worker, come mostrato nella tabella seguente:

    Modello di deployment Tipi di cluster supportati
    Deployment di cluster di amministrazione e utente

    Cluster di amministrazione

    Cluster utente 1

    Cluster utente 2
    Deployment di cluster ibridi

    Cluster ibrido

    Cluster utente 1

    Cluster utente 2
    Deployment di cluster autonomi

    Cluster autonomo

Configurare un cluster autogestito per i registri privati

Per configurare un cluster autonomo o ibrido in modo che utilizzi i registri privati a livello di nodo:

  1. 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 registro privato e la porta. Ad esempio: 10.200.0.2:5007.

    • CA_CERT_PATH: il percorso del file del certificato CA (CA root del server). Ad esempio: /root/cert.pem. Se il registro privato non richiede un certificato TLS privato, puoi omettere questo campo.

    • CREDENTIALS_FILE_PATH: il percorso del file di configurazione, config.json (ad esempio, $HOME/.docker/config.json). Per autenticare containerd per accedere al registro privato, config.json deve contenere una versione codificata in Base64 delle credenziali nella sezione auths del file.

      Per Artifact Registry, esegui l'autenticazione utilizzando una chiave JSON dell'account di servizio con i seguenti valori:

      • username: _json_key
      • password: l'intero contenuto del file della chiave JSON dell'account di servizio. Racchiudi il contenuto della chiave JSON in virgolette singole (') per evitare errori di analisi.

      Per ulteriori informazioni su come generare questo file, consulta Configurare l'autenticazione ad Artifact Registry per Docker nella documentazione di Artifact Registry.

      Per altri registri privati, la stringa auth codificata in Base64 viene in genere formata da USERNAME:PASSWORD, utilizzando le credenziali del registro specifiche. Se il server del registro privato non richiede credenziali per l'autenticazione, puoi omettere il campo pullCredentialConfigPath.

      Per proteggere i dati sensibili, puoi utilizzare chown e chmod per limitare l'accesso al file di configurazione.

  2. Applica le modifiche al cluster:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster che vuoi aggiornare.

    • CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster autogestito (ibrido o autonomo).

Configurare un cluster utente per i registri privati

Con i cluster utente, la configurazione del registro privato viene specificata nelle specifiche delle risorse del cluster utente, che si trova nel cluster di amministrazione. Inoltre, devi archiviare le credenziali del registro privato in un secret, che si trova anche nel cluster di amministrazione:

  1. Crea un secret di Kubernetes di tipo kubernetes.io/dockerconfigjson per le credenziali del registro:

    Se vuoi limitare l'ambito del secret a uno spazio dei nomi specifico, aggiungi il flag --namespace al seguente comando per specificare il nome dello spazio dei nomi. Se il secret non si trova nello stesso spazio dei nomi del cluster, aggiungi l' annotazione baremetal.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, config.json (ad esempio, $HOME/.docker/config.json). Per autenticare containerd per accedere al registro privato, config.json deve contenere una versione codificata in Base64 delle credenziali nella sezione auths del file.

      Per Artifact Registry, esegui l'autenticazione utilizzando una chiave JSON dell'account di servizio con i seguenti valori:

      • username: _json_key
      • password: l'intero contenuto del file della chiave JSON dell'account di servizio. Racchiudi il contenuto della chiave JSON in virgolette singole (') per evitare errori di analisi.

      Per ulteriori informazioni su come generare questo file, consulta Configurare l'autenticazione ad Artifact Registry per Docker nella documentazione di Artifact Registry.

      Per altri registri privati, la stringa auth codificata in Base64 viene in genere formata da USERNAME:PASSWORD, utilizzando le credenziali del registro specifiche. Se il server del registro privato non richiede credenziali per l'autenticazione, puoi omettere il campo pullCredentialSecretRef.

      Per proteggere i dati sensibili, puoi utilizzare chown e chmod per limitare l'accesso al file di configurazione.

    Il secret dovrebbe essere simile al seguente esempio:

    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

  2. Se applicabile, archivia il certificato CA per il registro in un secret.

    Il secret è 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==
  ```

  3. Modifica il file di configurazione del cluster utente per abilitare e configurare il registro privato:

    1. Solo per i cluster versione 1.29, aggiungi l'annotazione della funzionalità Anteprima preview.baremetal.cluster.gke.io/private-registry: "enable" per abilitare la funzionalità. Per i cluster versione 1.30 e successive, la funzionalità del registro 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"
...

    2. Nella sezione nodeConfig del file di configurazione del cluster utente, aggiungi il blocco privateRegistries:

      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 archiviare il certificato CA. Se non hai creato questo secret, rimuovi il blocco caCertSecretRef.

    • 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 tipo kubernetes.io/dockerconfigjson per le credenziali del registro.

    • CREDS_SECRET_NAMESPACE: il nome dello spazio dei nomi per il secret per le credenziali del registro.

  4. 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: il percorso del file kubeconfig del cluster di amministrazione.