Configurare i nodi per l'autenticazione in un registry 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 tuoi carichi di lavoro per darti 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 la configurazione di containerd di conseguenza. 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 alla versione 1.28, ma la funzionalità funziona solo per i node pool alla versione 1.29 o successive).

  • 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 utente 2
    Deployment di cluster ibridi

    Cluster ibrido

    Cluster di utenti 1

    Cluster utente 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 tutti i node pool devono essere alla versione 1.29, ma la funzionalità funziona solo per i node pool alla 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 utente 2
    Deployment di cluster ibridi

    Cluster ibrido

    Cluster di utenti 1

    Cluster utente 2
    Deployment di cluster autonomi

    Cluster autonomo

Configura un cluster autogestito per i registri privati

Per configurare un cluster autonomo o ibrido in modo che utilizzi 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 radice del server). Ad esempio: /root/cert.pem. Se il tuo 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 tuo registro privato, config.json deve contenere una versione codificata in base64 delle tue 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 in Artifact Registry per Docker nella documentazione di Artifact Registry.

      Per altri registri privati, la stringa auth con codifica base64 è in genere formata da USERNAME:PASSWORD, utilizzando le credenziali specifiche del registro. Se il tuo server di 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 da aggiornare.

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

Configura un cluster utente per i registri privati

Con i cluster utente, la configurazione del registro privato è specificata nella specifica della risorsa 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 tuo registro privato, config.json deve contenere una versione codificata in base64 delle tue 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 in Artifact Registry per Docker nella documentazione di Artifact Registry.

      Per altri registri privati, la stringa auth con codifica base64 è in genere formata da USERNAME:PASSWORD, utilizzando le credenziali specifiche del registro. Se il tuo server di 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 tuo segreto 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 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==
  ```

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

    1. Solo per i cluster della 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 del 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: percorso del file kubeconfig del cluster di amministrazione.