Configurare i nodi per l'autenticazione in un registry privato

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:

  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 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 sezione auths del file. Per compilare correttamente la sezione auths, puoi seguire le istruzioni riportate in Chiave account di servizio nella documentazione di Artifact Registry. Per difendere i dati sensibili, puoi utilizzare chown e chmod 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.

  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 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:

  1. 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'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 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 sezione auths del file. Per compilare correttamente la sezione auths, puoi seguire le istruzioni riportate in Chiave account di servizio nella documentazione di Artifact Registry. Per difendere i dati sensibili, puoi utilizzare chown e chmod 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

  2. 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==
  ```

  3. Modifica il file di configurazione del cluster utente per attivare e configurare il registry 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 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"
...

    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 memorizzare 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 registry.

    • CREDS_SECRET_NAMESPACE: il nome dello spazio dei nomi per il segreto per le credenziali del registry.

  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.