Usa una duplicación de registro para las imágenes de contenedor

En esta página, se explica cómo crear y actualizar clústeres con imágenes extraídas de una duplicación de registro, en lugar de un registro público, como gcr.io. Esta función se puede habilitar o inhabilitar en cualquier momento del ciclo de vida del clúster.

Esta página está dirigida a los operadores y especialistas en almacenamiento que configuran y administran el rendimiento, el uso y los gastos del almacenamiento. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Tareas y roles comunes de los usuarios de GKE.

Una duplicación de registro es una copia local de un registro público que copia o duplica la estructura de archivos del registro público. Por ejemplo, supongamos que la ruta a la duplicación de tu registro local es 172.18.0.20:5000. Cuando containerd encuentra una solicitud para extraer una imagen como gcr.io/kubernetes-e2e-test-images/nautilus:1.0, containerd intenta extraer esa imagen, no de gcr.io, sino de tu registro local en la siguiente ruta: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Si la imagen no está en esta ruta de registro local, la imagen se extrae automáticamente del registro público gcr.io.

El uso de una duplicación de registro proporciona los siguientes beneficios:

• Te protege de las interrupciones de registros públicos.
• Acelera la creación de Pods.
• Te permite realizar tu propio análisis de vulnerabilidades.
• Evita los límites que imponen los registros públicos sobre la frecuencia con la que puedes enviarles comandos.

Nota: Las extracciones de imágenes para gcr.io/anthos-baremetal-release/kindest/node no recurren a gcr.io. Estas imágenes solo se extraen de la duplicación del registro. Si el duplicado del registro no funciona, la extracción falla.

Antes de comenzar

• Debes tener un servidor de Artifact Registry configurado en tu red.
• Si el servidor de registro ejecuta un certificado TLS privado, debes tener el archivo de autoridad certificadora (CA).
• Si el servidor de registro necesita autenticación, debes tener las credenciales de acceso o el archivo de configuración de Docker adecuados.
• Si usas un registro de Red Hat Quay, es posible que debas crear la estructura de directorios del registro local de forma manual.
• Para usar una duplicación de registro, debes configurar el entorno de ejecución del contenedor como containerd.
• Asegúrate de tener suficiente espacio en el disco de tu estación de trabajo de administrador para admitir las cargas de imágenes. El comando de carga de imágenes, bmctl push images, descomprime el archivo del paquete de imágenes descargado y, luego, extrae todos los archivos de imágenes de forma local antes de subirlos. Debes tener al menos tres veces más espacio en el disco que el tamaño del archivo del paquete de imágenes descargado para poder subir las imágenes. Por ejemplo, el archivo bmpackages_1.31.200-gke.59.tar.xz comprimido ocupa aproximadamente 8.5 GB de espacio en disco, por lo que debes tener al menos 25.5 GB de espacio en disco libre antes de descargarlo.

Descarga todas las imágenes necesarias para Google Distributed Cloud

Descarga la última versión de la herramienta bmctl y el paquete de imágenes de la página Descargar.

Nota: Antes de la versión secundaria 1.29, el formato de archivo tar del paquete de imágenes era compatible con Docker. En la versión secundaria 1.29 y versiones posteriores, el archivo .tar del paquete de imágenes está en formato de imagen de Open Container Initiative (OCI), que no es compatible con Docker.

Sube imágenes de contenedor a tu servidor de registro

Cuando usas bmctl push images para subir imágenes de contenedor a tu servidor de repositorio, bmctl realiza los siguientes pasos en orden:

1. Descomprime un archivo tar comprimido del paquete de imágenes descargado, como bmpackages_1.32.200-gke.104.tar.xz en bmpackages_1.32.200-gke.104.tar.

2. Extrae todas las imágenes del archivo tar descomprimido en un directorio llamado bmpackages_1.32.200-gke.104.

3. Envía cada archivo de imagen al registro privado especificado.

   bmctl usa los valores --username y --password para la autenticación básica y, así, enviar las imágenes a tu registro privado.

En las siguientes secciones, se ilustran algunas variaciones comunes del comando bmctl push images para subir imágenes a tu servidor de repositorio.

Autentícate con tu registro y comparte el certificado TLS

El siguiente comando incluye las marcas --username y --password para la autenticación del usuario con tu servidor de registro. El comando también incluye la marca --cacert para pasar el certificado de seguridad de la capa de transporte (TLS) de la CA, que se usa para la comunicación segura del servidor de registro, incluidas las inserciones y extracciones de imágenes. Estas marcas proporcionan seguridad básica para tu servidor de registro.

Si tu servidor de registro requiere autenticación y no usas las marcas --username y --password, se te solicitarán credenciales cuando ejecutes bmctl push images. Puedes escribir tu contraseña o elegir el archivo de configuración de Docker que contiene las credenciales.

Para subir imágenes con autenticación y un certificado de CA privada, usa un comando como el siguiente:

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --username USERNAME \
    --password PASSWORD \
    --cacert CERT_PATH

Reemplaza lo siguiente:

• IMAGES_TAR_FILE_PATH: Es la ruta de acceso al archivo tar del paquete de imágenes descargado, como bmpackages_1.32.200-gke.104.tar.xz.

• REGISTRY_IP:PORT: Es la dirección IP y el puerto del servidor de registro privado.

• USERNAME: Es el nombre de usuario de un usuario con permisos de acceso para subir imágenes al servidor de registro.

• PASSWORD: Es la contraseña del usuario para la autenticación con el servidor de registro.

• CERT_PATH: Es la ruta de acceso al archivo de certificado de CA si el servidor de registro usa un certificado TLS privado.

Por ejemplo:

bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --username alex --password pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

Subir imágenes sin autenticación ni certificados del usuario

Si tu servidor de registro no requiere credenciales, como un nombre de usuario y una contraseña, especifica --need-credential=false en el comando bmctl. Si tu servidor de registro usa un certificado TLS público, no necesitas usar la marca --cacert. Este tipo de comando de carga es más adecuado para entornos de prueba, en los que la seguridad es menos importante que en la producción.

Para subir imágenes sin autenticación o un certificado de CA privada, usa un comando como el siguiente:

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --need-credential=false

Por ejemplo:

bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --need-credential=false.

Ajusta la cantidad de subprocesos

La rutina de carga de imágenes puede llevar mucho tiempo debido al tamaño y la cantidad de imágenes de contenedor en el archivo tar del paquete de imágenes. Aumentar la cantidad de subprocesos paralelos hace que la rutina se ejecute más rápido. Puedes usar la marca --threads para cambiar la cantidad de subprocesos paralelos que usa bmctl push images.

De forma predeterminada, la rutina de carga de imágenes usa 4 subprocesos. Si las cargas de imágenes tardan demasiado, aumenta este valor. Como referencia, en un entorno de prueba de Google, subir imágenes desde una estación de trabajo con 4 CPU lleva aproximadamente 10 minutos con 8 subprocesos paralelos.

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --cacert CERT_PATH \
    --threads NUM_THREADS

Reemplaza NUM_THREADS por la cantidad de subprocesos paralelos que se usan para procesar las cargas de imágenes. De forma predeterminada, bmctl push images usa cuatro subprocesos paralelos.

El siguiente comando aumenta la cantidad de subprocesos para la carga de 4 a 8 para reducir el tiempo de carga:

bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem \
    --threads 8

Carga a través de proxy

Si necesitas un proxy para subir las imágenes de tu estación de trabajo al servidor de registro, puedes agregar los detalles del proxy antes del comando bmctl:

HTTPS_PROXY=http://PROXY_IP:PORT bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT \
    --cacert=CERT_PATH

Reemplaza lo siguiente:

• PROXY_IP:PORT: La dirección IP y el puerto del proxy.

• IMAGES_TAR_FILE_PATH: Es la ruta de acceso al archivo tar del paquete de imágenes descargado, como bmpackages_1.32.200-gke.104.tar.xz.

• REGISTRY_IP:PORT: Es la dirección IP y el puerto del servidor de registro privado.

• CERT_PATH: Es la ruta de acceso al archivo de certificado de CA si el servidor de registro usa un certificado TLS privado.

Ingresa tu nombre de usuario y contraseña cuando se te solicite o selecciona un archivo de configuración de Docker.

El siguiente comando sube imágenes a través de un proxy:

HTTPS_PROXY=http://10.128.0.136:3128 bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem

Usa tu propio espacio de nombres con bmctl push images

Si deseas usar tu propio espacio de nombres en tu servidor de registro en lugar del espacio de nombres raíz, containerd puede extraer de este espacio de nombres si proporcionas el extremo de la API para tu registro privado en el campo registryMirrors.endpoint de tu archivo de configuración del clúster. Por lo general, el extremo tiene el formato <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Consulta la guía del usuario de tu registro privado para obtener detalles específicos. Para obtener más información, consulta Acerca del uso de v2 en el extremo del registro.

bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT/NAMESPACE \
    --cacert=CERT_PATH

Reemplaza NAMESPACE por el nombre del espacio de nombres en el servidor de registro en el que deseas subir imágenes.

Por ejemplo, si solo tienes acceso a 198.51.20:5000/test-namespace/, puedes usar un comando como el siguiente para subir todas las imágenes en el espacio de nombres test-namespace:

bmctl push images \
    --source=./bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry=198.51.20:5000/test-namespace \
    --username=alex \
    --password=pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

Luego, en el archivo de configuración del clúster, puedes agregar lo siguiente para que containerd extraiga del espacio de nombres test-namespace:

registryMirrors:
  - endpoint: https://198.51.20:5000/v2/test-namespace

Para obtener más información sobre el comando bmctl push images, consulta la referencia del comando bmctl.

Configura clústeres para usar una duplicación del registro

Puedes configurar una duplicación de registro para un clúster durante la creación del clúster o cuando actualices un clúster existente. El método de configuración que uses dependerá del tipo de clúster y, en el caso de los clústeres de usuario, de si estás creando o actualizando un clúster. En las siguientes dos secciones, se describen los dos métodos disponibles para configurar duplicados del registro.

Usa la sección de encabezado en el archivo de configuración del clúster

Google Distributed Cloud te permite especificar duplicados del registro fuera de la especificación del clúster, en la sección del encabezado del archivo de configuración del clúster:

• En el caso de los clústeres de administrador, híbridos y autónomos, la única forma de configurar un duplicado del registro es usar la sección de encabezado en el archivo de configuración del clúster. Este método se aplica a la creación o actualización de clústeres.

• En el caso de los clústeres de usuarios, solo puedes usar este método para configurar una duplicación de registro durante la creación del clúster. Como alternativa, para configurar una duplicación de registro para un clúster de usuario existente, usa la sección nodeConfig.registryMirrors en la especificación del clúster.

En el siguiente archivo de configuración de clúster de muestra, se especifica que las imágenes se deben extraer de una duplicación del registro local cuyo extremo es https://198.51.20:5000. En las siguientes secciones, se describen algunos de los campos que aparecen al comienzo de este archivo de configuración.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://198.51.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

Usa la sección nodeConfig.registryMirrors en la especificación del clúster

Este método para crear o actualizar un duplicado del registro solo se aplica a los clústeres de usuario. Como puedes compartir los secretos creados para el clúster de administración con tu clúster de usuario, puedes usar nodeConfig.registryMirrors desde el clúster híbrido o de administrador de administración para especificar la duplicación del registro en la especificación del clúster para el clúster de usuario.

Para configurar un clúster de usuario de modo que use el mismo duplicado del registro que el clúster de administrador, sigue estos pasos:

1. Obtén la sección nodeConfig.registryMirror, incluidas las referencias a secretos, de nodeConfig.registryMirrors del recurso del clúster de administrador:

   kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE \
       --kubeconfig ADMIN_KUBECONFIG \
       -o yaml
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: Es el nombre del clúster de administrador o híbrido que administra el clúster de usuario.

   • CLUSTER_NAMESPACE: Es el nombre del espacio de nombres del clúster de administración.

   • ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administración.

2. Agrega la configuración de nodeConfig.registryMirrors del clúster de administrador al archivo de configuración del clúster de usuario.

   La sección registryMirrors del archivo de configuración del clúster de usuario debería ser similar al siguiente ejemplo:

   ---
   gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
   sshPrivateKeyPath: /root/ssh-key/id_rsa
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-user1
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: user1
     namespace: cluster-user1
   spec:
     nodeConfig:
       containerRuntime: containerd
       registryMirrors:
       -   caCertSecretRef:
           name: the-secret-created-for-the-admin-cluster
           namespace: anthos-creds
         endpoint: https://172.18.0.20:5000
         hosts:
           -   somehost.io
           -   otherhost.io
         pullCredentialSecretRef:
           name: the-image-pull-creds-created-for-the-admin-cluster
           namespace: anthos-creds
   ...
   

Para realizar cambios posteriores en la configuración del duplicado del registro de tu clúster de usuario, edita nodeConfig.registryMirrors en el archivo de configuración del clúster de usuario y aplica los cambios con bmctl update.

No puedes usar la sección de encabezado del archivo de configuración del clúster para actualizar la configuración de duplicaciones de registro de un clúster de usuario.

Campo hosts

containerd verifica la sección hosts del archivo de configuración del clúster para descubrir qué hosts se duplican de manera local. Estos hosts se asignan al extremo de la duplicación del registro especificado en el archivo de configuración del clúster (registryMirror.endpoint). En el archivo de configuración de ejemplo de la sección anterior, los registros públicos que se enumeran en la sección hosts son somehost.io y otherhost.io. Debido a que estos registros públicos aparecen en la sección hosts, containerd verifica primero la duplicación del registro privado cuando encuentra solicitudes de extracción de imágenes de somehost.io o otherhost.io.

Por ejemplo, supongamos que containerd recibe un comando de extracción a somehost.io/kubernetes-e2e-test-images/nautilus:1.0. Debido a que somehost.io aparece como uno de los hosts en la sección hosts del archivo de configuración del clúster, containerd busca la imagen de kubernetes-e2e-test-images/nautilus:1.0 en la duplicación del registro local. Si somehost.io no aparece en la sección hosts, containerd no sabe que existe una duplicación local de somehost.io. En ese caso, containerd no verifica la duplicación en busca de la imagen y extrae la imagen del registro público somehost.io.

Ten en cuenta que, de forma predeterminada, Google Distributed Cloud duplica automáticamente las imágenes de gcr.io, por lo que no necesitas enumerar gcr.io como un host en la sección hosts.

Los valores de hosts y el valor de endpoint no deben superponerse. Por ejemplo, la siguiente muestra de configuración muestra un host, europe-docker.pkg.dev, que coincide con la parte del dominio del valor del extremo. En este caso, no es necesario que especifiques un valor de hosts:

...
registryMirrors:
  ...
  endpoint: https://europe-docker.pkg.dev:5000/v2/cloud-data-fusion-images
  hosts:
    - europe-docker.pkg.dev
    ...

Campo gcrKeyPath

Si deseas que Google Distributed Cloud use automáticamente Artifact Registry (gcr.io) para extraer imágenes que no aparecen en tu registro local, debes especificar la ruta de acceso a la clave de la cuenta de servicio de Artifact Registry. Google Distributed Cloud no tiene un mecanismo para proporcionar claves para otros registros públicos.

Si no planeas usar la función en la que las imágenes se extraen de gcr.io cuando no aparecen en el registro local, no es necesario que agregues un gcrKeyPath al archivo de configuración del clúster.

Campo caCertPath

Si tu registro requiere un certificado de seguridad de la capa de transporte (TLS) privado, este campo toma la ruta de acceso al archivo de certificado de CA raíz del servidor. Este archivo de certificado debe estar en la estación de trabajo de administrador, la máquina que ejecuta los comandos de bmctl. Si tu registro no requiere un certificado TLS privado, puedes dejar el campo caCertPath en blanco.

Campo pullCredentialConfigPath

Si el servidor de registro no requiere un archivo de configuración de Docker de autenticación, puedes dejar el campo pullCredentialConfigPath en blanco. Ten en cuenta que esta es la ruta de acceso al archivo de configuración en la máquina que ejecuta los comandos de bmctl.

Usa una duplicación de registro con clústeres de usuario

Los clústeres de usuario no extraen imágenes de una duplicación de registro de forma automática si su clúster de administrador se configuró para hacerlo. Para que los clústeres de usuarios extraigan una duplicación de registro, debes configurarlos de forma individual como se describe en Configura clústeres para usar una duplicación de registro.

Actualiza extremos de registro duplicado, certificados y credenciales de extracción

Para actualizar los extremos de duplicación del registro, los certificados o las credenciales de extracción, sigue estos pasos:

1. En el archivo de configuración del clúster, actualiza el extremo, el archivo del certificado de CA y la ruta de acceso del archivo de configuración de la credencial.

2. Ejecuta el siguiente comando para aplicar los cambios:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME por el nombre del clúster que deseas actualizar

   • ADMIN_KUBECONFIG por la ruta de acceso del archivo de configuración de su clúster de administrador

Verifica que las imágenes se extraigan de la duplicación del registro

Para determinar si containerd extrae imágenes de tu registro local, examina los contenidos de un archivo config.toml como se muestra en los pasos siguientes:

1. Accede a un nodo y examina el contenido del siguiente archivo: /etc/containerd/config.toml

2. Verifica la sección plugins."io.containerd.grpc.v1.cri".registry.mirrors del archivo config.toml para ver si el servidor de registro aparece en el campo endpoint. Este es un extracto de un archivo config.toml de ejemplo en el que el campo endpoint aparece en negrita:

   version = 2
   root = "/var/lib/containerd"
   state = "/run/containerd"
   ...
   [plugins."io.containerd.grpc.v1.cri".registry]
     [plugins."io.containerd.grpc.v1.cri".registry.configs]
       [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
         [plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
           ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
     [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
       [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
         endpoint = ["http://privateregistry.io", "https://privateregistry2.io"]
   ...
   

   Si la duplicación del registro aparece en el campo endpoint, el nodo extrae imágenes de la duplicación del registro en lugar de un registro público.

Soluciona problemas de configuración de duplicaciones de registro

Puedes usar crictl, la herramienta de línea de comandos de la interfaz de tiempo de ejecución del contenedor, para probar la configuración del registro descargando archivos de imágenes individuales. Cada archivo de imagen se etiqueta de forma independiente con una cadena de versión significativa. Por ejemplo, la imagen del controlador de la API del clúster se etiqueta con la versión de lanzamiento de Google Distributed Cloud y la imagen de etcd se etiqueta con la versión de etcd correspondiente.

En la versión 1.31.200-gke.59 de Google Distributed Cloud en equipos físicos, la imagen del controlador de la API del clúster, cluster-api-controller, y la imagen de etcd, etcd, tienen las siguientes etiquetas:

• cluster-api-controller:1.31.200-gke.59
• etcd:v3.4.30-0-gke.1

Extrae una imagen de la duplicación del registro

Si la duplicación del registro no usa espacios de nombres, usa el siguiente comando para extraer una imagen:

crictl pull REGISTRY_IP:PORT/IMAGE_PATH:IMAGE_TAG

Cómo extraer una imagen de una duplicación de registro que usa espacios de nombres

Si la duplicación del registro usa espacios de nombres, usa el siguiente comando para extraer una imagen:

crictl pull REGISTRY_IP:PORT/NAMESPACE/IMAGE_PATH:IMAGE_TAG

Acerca del uso de v2 en el extremo del registro

Cuando tu registro usa espacios de nombres personalizados, debes anteponer el espacio de nombres en el extremo del registro (registryMirror.endpoint) en el archivo de configuración del clúster con v2/. Si no usas espacios de nombres, no uses v2. En cualquier caso, no uses v2 en el valor de la marca --private-registry ni en los comandos de extracción de imágenes:

Sin espacios de nombres

• Válido:
  • endpoint: https://172.18.0.20:5000
  • crictl pull 172.18.0.20:5000/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
• No válido:
  • endpoint: https://172.18.0.20:5000/v2
  • crictl pull 172.18.0.20:5000/v2/anthos-baremetal-release/etcd:v3.4.30-0-gke.1

Con espacios de nombres

• Válido:
  • endpoint: https://172.18.0.21:5000/v2/namespace
  • crictl 172.18.0.21:5000/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
• No válido:
  • endpoint: https://172.18.0.21:5000/namespace
  • crictl pull 172.18.0.21:5000/v2/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1