Configura nodos para que se autentiquen en un registro privado

Puedes configurar tu clúster de Google Distributed Cloud para que sus nodos de trabajo puedan usar registros privados. Los registros privados a nivel del nodo están diseñados para usarse con tus cargas de trabajo y brindarte más control sobre las extracciones de imágenes y su seguridad relacionada. Cuando configuras un clúster con los registros privados como se describe en este documento, Google Distributed Cloud actualiza la configuración de containerd según corresponda. Una vez que se configura el clúster, todos los Pods en nodos calificados pueden usar los registros sin tener que especificar imagePullSecrets en las especificaciones del Pod.

Esta función se puede habilitar o inhabilitar en cualquier momento del ciclo de vida del clúster.

En la siguiente lista, se muestra la etapa de lanzamiento de esta función por versión:

• 1.30 y versiones posteriores: GA
• 1.29: Vista previa

Requisitos previos

1.30 y versiones posteriores

Para usar esta función de GA, tu clúster debe cumplir con los siguientes requisitos:

• La versión del clúster debe ser 1.30 o una posterior.
• La versión del grupo de nodos debe ser 1.29 o posterior (un clúster de la versión 1.30 puede tener grupos de nodos en la versión 1.28, pero la función solo funciona para grupos de nodos en la versión 1.29 o posterior).

• Esta función es para clústeres de usuario y clústeres autoadministrados (híbridos y autónomos) con grupos de nodo trabajador, como se muestra en la siguiente tabla:

  Modelo de implementación	Tipos de clústeres compatibles
  Implementación de clústeres de administrador y de usuario	Clúster de administrador Clúster de usuario 1 Clúster de usuario 2
  Implementación de clúster híbrido	Clúster híbrido Clúster de usuario 1 Clúster de usuario 2
  Implementación del clúster independiente	Clúster independiente

1.29

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Para usar esta función de Versión preliminar, tu clúster debe cumplir con los siguientes requisitos:

• La versión del clúster debe ser 1.29.
• La versión del grupo de nodos debe ser 1.29 (no es necesario que todos los grupos de nodos tengan la versión 1.29, pero la función solo funciona para los grupos de nodos que tienen la versión 1.29).
• El clúster debe tener la anotación de función de versión preliminar preview.baremetal.cluster.gke.io/private-registry: "enable".

• Esta función es para clústeres de usuario y clústeres autoadministrados (híbridos y autónomos) con grupos de nodo trabajador, como se muestra en la siguiente tabla:

  Modelo de implementación	Tipos de clústeres compatibles
  Implementación de clústeres de administrador y de usuario	Clúster de administrador Clúster de usuario 1 Clúster de usuario 2
  Implementación de clúster híbrido	Clúster híbrido Clúster de usuario 1 Clúster de usuario 2
  Implementación del clúster independiente	Clúster independiente

Configura un clúster de administración automática para registros privados

Para configurar un clúster independiente o híbrido para que use registros privados a nivel del nodo, haz lo siguiente:

1. Edita el archivo de configuración del clúster para agregar el bloque privateRegistries en la sección de credenciales:

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

   Reemplaza lo siguiente:

   • REGISTRY_HOST: el nombre de dominio o la dirección IP del registro privado y el puerto Por ejemplo: 10.200.0.2:5007.

   • CA_CERT_PATH: Es la ruta de acceso del archivo de certificado de la AC (AC raíz del servidor). Por ejemplo: /root/cert.pem. Si tu registro privado no requiere un certificado TLS privado, puedes omitir este campo.

   • CREDENTIALS_FILE_PATH: Es la ruta de acceso al archivo que contiene las credenciales para acceder a tu registro privado. Por ejemplo: /root/.docker/config.json Si tu servidor de registro privado no requiere credenciales para la autenticación, puedes omitir este campo.

2. Aplica los cambios a tu clúster:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.

   • CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster autoadministrado (híbrido o independiente).

Configura un clúster de usuario para registros privados

Con los clústeres de usuarios, la configuración del registro privado se especifica en la especificación de recursos del clúster de usuarios, que se encuentra en el clúster de administrador. Además, debes almacenar las credenciales del registro privado en un Secret, que también se encuentra en el clúster de administrador:

1. Crea un Secret de Kubernetes de tipo kubernetes.io/dockerconfigjson para las credenciales del registro:

   Si deseas limitar el Secret a un espacio de nombres específico, agrega la marca --namespace al siguiente comando para especificar el nombre del espacio de nombres. Si el Secret no está en el mismo espacio de nombres que el clúster, agrega la anotación baremetal.cluster.gke.io/mark-source: "true", como se muestra en el ejemplo al final de este paso.

   kubectl create secret docker-registry CREDS_SECRET_NAME \
       --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \
       --kubeconfig=ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CREDS_SECRET_NAME: Es el nombre del Secret.

   • CREDENTIALS_FILE_PATH: Es la ruta de acceso del archivo de configuración de Docker. Por ejemplo, /root/.docker/config.json

   Tu Secret debería verse similar al siguiente ejemplo:

   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. Si corresponde, almacena el certificado de la AC del registro en un Secret.

   El Secret es similar al siguiente:

   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. Edita el archivo de configuración del clúster de usuarios para habilitar y configurar el registro privado:

   1. Solo para los clústeres de la versión 1.29, agrega la anotación de la función Preview preview.baremetal.cluster.gke.io/private-registry: "enable" para habilitar la función. Para los clústeres de la versión 1.30 y versiones posteriores, la función de registro privado está habilitada de forma predeterminada.

      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. En la sección nodeConfig del archivo de configuración del clúster de usuario, agrega el bloque 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
      

   Reemplaza lo siguiente:

   • CA_CERT_SECRET_NAME: Es el nombre del Secret que creaste para almacenar el certificado de la AC. Si no creaste este Secret, quita el bloque caCertSecretRef.

   • CA_CERT_SECRET_NAMESPACE: Es el nombre del espacio de nombres del Secret del certificado de la AC, si lo creaste.

   • REGISTRY_HOST: El nombre de dominio o la dirección IP del registro privado y el puerto. Por ejemplo: 10.200.0.2:5007.

   • CREDS_SECRET_NAME: Es el nombre del Secret de tipo kubernetes.io/dockerconfigjson para las credenciales del registro.

   • CREDS_SECRET_NAMESPACE: Es el nombre del espacio de nombres del Secret para las credenciales del registro.

4. Aplica los cambios a tu clúster:

   bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • USER_CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.

   • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador