Configura i nodi per l'autenticazione in un registro privato

Puoi configurare il cluster Google Distributed Cloud in modo che i suoi nodi worker possono usare registri privati. 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 sui relativi sicurezza. Quando configuri un cluster con i registri privati come descritto, In questo documento, Google Distributed Cloud aggiorna la configurazione containerd di conseguenza. Una volta configurato il cluster, tutti i pod sui nodi qualificati i registri senza dover specificare imagePullSecrets nella specifica del pod.

Questa funzionalità può essere abilitata o disabilitata in qualsiasi momento durante il ciclo di vita del cluster.

Il seguente elenco mostra la fase di avvio di questa funzionalità in base alla versione:

  • 1.30: Disponibilità generale
  • 1.29: Anteprima
  • 1.28: Non disponibile

Prerequisiti

1,30

Per utilizzare questa funzionalità 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à è valida solo per i pool di nodi in versione 1.29 o successive).

  • Questa funzionalità è disponibile per i cluster utente e per la gestione autonoma (ibrida e indipendente) cluster con pool di nodi worker, come illustrato nella tabella seguente:

    Modello di deployment Tipi di cluster supportati
    Deployment dei cluster di amministrazione e degli utenti

    Cluster di amministrazione

    Cluster utente 1

    Cluster utente 2
    Deployment di cluster ibrido

    Cluster ibrido

    Cluster utente 1

    Cluster utente 2
    Deployment del cluster autonomo

    Cluster autonomo

1,29

Per utilizzare questa funzionalità di anteprima, il cluster devono soddisfare i seguenti requisiti:

  • La versione del cluster deve essere 1.29.
  • La versione del pool di nodi deve essere 1.29 (non tutti i pool di nodi devono trovarsi versione 1.29, ma la funzionalità funziona solo per i pool di nodi nella versione 1.29).
  • Il cluster deve avere Anteprima di preview.baremetal.cluster.gke.io/private-registry: "enable" annotazione delle caratteristiche.

  • Questa funzionalità è disponibile per i cluster utente e per la gestione autonoma (ibrida e indipendente) cluster con pool di nodi worker, come illustrato nella tabella seguente:

    Modello di deployment Tipi di cluster supportati
    Deployment dei cluster di amministrazione e degli utenti

    Cluster di amministrazione

    Cluster utente 1

    Cluster utente 2
    Deployment di cluster ibrido

    Cluster ibrido

    Cluster utente 1

    Cluster utente 2
    Deployment del cluster autonomo

    Cluster autonomo

Configura un cluster a gestione autonoma per i registri privati

Per configurare un cluster autonomo o ibrido per utilizzare la proprietà privata a livello di nodo registri:

  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: nome di dominio o indirizzo IP di il registro privato e la porta. Ad esempio: 10.200.0.2:5007.

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

    • CREDENTIALS_FILE_PATH: il percorso del file che contiene le credenziali per accedere al registro privato. Ad esempio: /root/.docker/config.json. Se il server del registry privato 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 che vuoi aggiornamento.

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

Configura un cluster utente per i registri privati

Per i cluster utente, la configurazione del registro privato viene specificata Specifiche delle risorse cluster. Inoltre, per i cluster utente, devi archiviare credenziali del registro private in un secret:

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

    Se vuoi limitare il secret a uno spazio dei nomi specifico, aggiungi --namespace al comando seguente per specificare il nome del deployment nello 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 tuo secret.

    • CREDENTIALS_FILE_PATH: il percorso del Docker di configurazione del deployment. Ad esempio, /root/.docker/config.json.

    Il tuo 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

    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 sopra esempio.

  2. Se applicabile, memorizza il certificato CA per il registry 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 l'impostazione privata registry:

    1. Solo per i cluster della versione 1.29, aggiungi la classe Anteprima dell'annotazione per la funzionalità preview.baremetal.cluster.gke.io/private-registry: "enable" per attivare la caratteristica. Per i cluster della versione 1.30 e successive, il 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 creato per archiviare il certificato CA. Se non hai creato tu questo secret, rimuovi il blocco caCertSecretRef.

    • CA_CERT_SECRET_NAMESPACE: il nome dello spazio dei nomi per il secret del certificato CA, se è stato creato da te.

    • 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 Tipo Secret kubernetes.io/dockerconfigjson per il registry e credenziali.

    • CREDS_SECRET_NAMESPACE: il nome dello spazio dei nomi per Secret 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 aggiornamento in corso.

    • ADMIN_KUBECONFIG: percorso del cluster di amministrazione kubeconfig.