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.

L'elenco seguente mostra la fase di lancio di questa funzionalità per versione:

  • 1.30: GA
  • 1.29: Anteprima
  • 1.28: non disponibile

Prerequisiti

1,30

Per utilizzare questa funzionalità di GA, il cluster deve soddisfare i seguenti requisiti:

  • La versione del cluster deve essere 1.30.
  • 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 che contiene le credenziali per accedere al tuo registry privato. Ad esempio: /root/.docker/config.json. Se il server del registry privato non richiede credenziali per l'autenticazione, puoi omettere questo campo.

  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. Inoltre, per i cluster utente devi archiviare le credenziali del registry privato in un segreto:

  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.

    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. Ad esempio, /root/.docker/config.json.

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

  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.