Configurar nodos para que se autentiquen en un registro privado

Puedes configurar tu clúster de Google Distributed Cloud para que sus nodos de trabajador puedan usar registros privados, incluido Artifact Registry. Los registros privados a nivel de nodo están pensados para usarse con tus cargas de trabajo y te permiten tener más control sobre las extracciones de imágenes y su seguridad relacionada. Cuando configuras un clúster con los registros privados tal como se describe en este documento, Google Distributed Cloud actualiza la configuración de containerd en consecuencia. Una vez configurado el clúster, todos los pods de los nodos aptos 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 fase de lanzamiento de esta función por versión:

Requisitos previos

1.30 y versiones posteriores

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

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

  • Esta función está disponible para clústeres de usuario y clústeres autogestionados (híbridos y independientes) con grupos de nodos de trabajador, tal como se muestra en la siguiente tabla:

    Modelo de implementación Tipos de clúster admitidos
    Despliegue de clústeres de administrador y de usuario

    Clúster de administrador

    Clúster de usuarios 1

    Clúster de usuarios 2
    Despliegue de clúster híbrido

    Clúster híbrido

    Clúster de usuarios 1

    Clúster de usuarios 2
    Despliegue de clústeres independientes

    Clúster independiente

1,29

Para usar la función Vista previa, tu clúster debe cumplir 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 con los grupos de nodos que tengan la versión 1.29).
  • El clúster debe tener la anotación de la función de preview.baremetal.cluster.gke.io/private-registry: "enable" vista previa.

  • Esta función está disponible para clústeres de usuario y clústeres autogestionados (híbridos y independientes) con grupos de nodos de trabajador, tal como se muestra en la siguiente tabla:

    Modelo de implementación Tipos de clúster admitidos
    Despliegue de clústeres de administrador y de usuario

    Clúster de administrador

    Clúster de usuarios 1

    Clúster de usuarios 2
    Despliegue de clúster híbrido

    Clúster híbrido

    Clúster de usuarios 1

    Clúster de usuarios 2
    Despliegue de clústeres independientes

    Clúster independiente

Configurar un clúster autogestionado para registros privados

Para configurar un clúster independiente o híbrido para que use registros privados a nivel de nodo, sigue estos pasos:

  1. Edita el archivo de configuración del clúster para añadir 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
  ...

    Haz los cambios siguientes:

    • 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: ruta 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: la ruta del archivo de configuración, config.json (por ejemplo, $HOME/.docker/config.json). Para autenticar containerd y acceder a tu registro privado, config.json debe contener una versión codificada en base64 de tus credenciales en la sección auths del archivo.

      En Artifact Registry, autentícate con una clave JSON de cuenta de servicio con los siguientes valores:

      • username: _json_key
      • password: el contenido completo del archivo de clave JSON de la cuenta de servicio. Encierra entre comillas simples (') el contenido de la clave JSON pegada para evitar errores de análisis.

      Para obtener más información sobre cómo generar este archivo, consulta el artículo Configurar la autenticación en Artifact Registry para Docker de la documentación de Artifact Registry.

      En el caso de otros registros privados, la cadena auth codificada en Base64 se suele formar a partir de USERNAME:PASSWORD, con las credenciales de tu registro específico. Si tu servidor de registro privado no requiere credenciales para la autenticación, puedes omitir el campo pullCredentialConfigPath.

      Para proteger los datos sensibles, puedes usar chown y chmod para restringir el acceso al archivo de configuración.

  2. Aplica los cambios al clúster:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG

    Haz los cambios siguientes:

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

    • CLUSTER_KUBECONFIG: ruta del archivo kubeconfig del clúster autogestionado (híbrido o independiente).

Configurar un clúster de usuarios para registros privados

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

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

    Si quieres limitar el ámbito del secreto a un espacio de nombres específico, añade la marca --namespace al siguiente comando para especificar el nombre del espacio de nombres. Si el secreto no está en el mismo espacio de nombres que el clúster, añade 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

    Haz los cambios siguientes:

    • CREDS_SECRET_NAME: el nombre del secreto.

    • CREDENTIALS_FILE_PATH: la ruta del archivo de configuración, config.json (por ejemplo, $HOME/.docker/config.json). Para autenticar containerd y acceder a tu registro privado, config.json debe contener una versión codificada en base64 de tus credenciales en la sección auths del archivo.

      En Artifact Registry, autentícate con una clave JSON de cuenta de servicio con los siguientes valores:

      • username: _json_key
      • password: el contenido completo del archivo de clave JSON de la cuenta de servicio. Encierra entre comillas simples (') el contenido de la clave JSON pegada para evitar errores de análisis.

      Para obtener más información sobre cómo generar este archivo, consulta el artículo Configurar la autenticación en Artifact Registry para Docker de la documentación de Artifact Registry.

      En el caso de otros registros privados, la cadena auth codificada en Base64 se suele formar a partir de USERNAME:PASSWORD, con las credenciales de tu registro específico. Si tu servidor de registro privado no requiere credenciales para la autenticación, puedes omitir el campo pullCredentialSecretRef.

      Para proteger los datos sensibles, puedes usar chown y chmod para restringir el acceso al archivo de configuración.

    Tu secreto debería tener un aspecto similar al del 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 procede, almacena el certificado de CA del registro en un secreto.

    El secreto tiene un aspecto 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 usuario para habilitar y configurar el registro privado:

    1. Solo en los clústeres de la versión 1.29, añade la anotación de la función Vista previa preview.baremetal.cluster.gke.io/private-registry: "enable" para habilitar la función. En los clústeres de la versión 1.30 y 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 usuarios, añade 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

    Haz los cambios siguientes:

    • CA_CERT_SECRET_NAME: el nombre del secreto que has creado para almacenar el certificado de CA. Si no has creado este secreto, elimina el bloque caCertSecretRef.

    • CA_CERT_SECRET_NAMESPACE: el nombre del espacio de nombres del secreto del certificado de CA, si lo has creado.

    • 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: el nombre del tipo Secret del registro de kubernetes.io/dockerconfigjson credenciales.

    • CREDS_SECRET_NAMESPACE: nombre del espacio de nombres del secreto de las credenciales del registro.

  4. Aplica los cambios al clúster:

    bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Haz los cambios siguientes:

    • USER_CLUSTER_NAME: el nombre del clúster que vas a actualizar.

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