Configura nodos para que se autentiquen en un registro privado

Puedes configurar tu clúster de Google Distributed Cloud para que sus nodos trabajadores puedan usar registros privados, incluido Artifact Registry. Los registros privados a nivel del nodo están diseñados para usarse con tus cargas de trabajo para 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 en consecuencia. Una vez que se configura el clúster, todos los Pods en los nodos calificados pueden usar los registros sin tener que especificar imagePullSecrets en la especificación 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:

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 una posterior (un clúster 1.30 puede tener grupos de nodos en la versión 1.28, pero la función solo funciona para los grupos de nodos en la versión 1.29 o una posterior).

  • Esta función es para clústeres de usuario y clústeres de administración automática (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

Para usar esta función de vista previa, 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 estén en la versión 1.29, pero la función solo funciona para los grupos de nodos en 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 de administración automática (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 autónomo o híbrido para usar 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: Es 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 al archivo de certificado de CA (CA 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 de configuración, config.json (por ejemplo, $HOME/.docker/config.json). Para autenticar containerd para 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.

      Para Artifact Registry, autentica 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 el contenido de la clave JSON pegada entre comillas simples (') para evitar errores de análisis.

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

      Para otros registros privados, la cadena auth codificada en base64 suele formarse a partir de USERNAME:PASSWORD, con tus credenciales de registro específicas. 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 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 de administración automática (híbrido o autónomo).

Configura un clúster de usuario para registros privados

Con los clústeres de usuario, la configuración del registro privado se especifica en la especificación del recurso del clúster de usuario, 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 al archivo de configuración, config.json (por ejemplo, $HOME/.docker/config.json). Para autenticar containerd para 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.

      Para Artifact Registry, autentica 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 el contenido de la clave JSON pegada entre comillas simples (') para evitar errores de análisis.

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

      Para otros registros privados, la cadena auth codificada en base64 suele formarse a partir de USERNAME:PASSWORD, con tus credenciales de registro específicas. 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 Secret debería verse como el 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 CA para el 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 usuario para habilitar y configurar el registro privado:

    1. Solo para los clústeres de la versión 1.29, agrega la función de versión preliminar anotación preview.baremetal.cluster.gke.io/private-registry: "enable" para habilitar la función. Para 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 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 CA. Si no creaste este secreto, quita el bloque caCertSecretRef. Si varios registros privados hacen referencia a Secrets de certificados de la AC con el mismo nombre en diferentes espacios de nombres (excepto el espacio de nombres anthos-creds o del clúster), el sistema agrega un prefijo al nombre del Secret de destino para asegurarse de que los nombres de los Secrets de certificados de la AC sean únicos en todos los espacios de nombres. El sistema no agregará un prefijo a los secretos en el espacio de nombres del clúster ni en el espacio de nombres de origen en anthos-creds.

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

    • REGISTRY_HOST: Es 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 para el Secret de 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