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.

Prerequisiti

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"
        ...
    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 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. Aggiungi l'annotazione preview.baremetal.cluster.gke.io/private-registry: "enable" per abilitare il registro privato mentre è Anteprima.

      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.