Los clústeres de Anthos en Bare Metal ahora son Google Distributed Cloud (solo software) para Bare Metal. Para obtener más información, consulta la descripción general del producto.

Se usó la API de Cloud Translation para traducir esta página.

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á destinada a operadores y especialistas en almacenamiento que configuran y administran el rendimiento, el uso y el gasto 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 Enterprise.

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.

Antes de comenzar

Debes tener un servidor de registro de contenedores 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.
Para usar una duplicación de registro, debes configurar el entorno de ejecución del contenedor como containerd.

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.

Sube imágenes de contenedor a tu servidor de registro

Ejecuta el siguiente comando para subir las imágenes del paquete de imágenes a tu servidor de registro:

[HTTPS_PROXY=http://PROXY_IP:PORT] ./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=REGISTRY_IP:PORT \
    [--cacert=CERT_PATH] \
    [--need-credential=false]

Reemplaza lo siguiente:

PROXY_IP:PORT por la dirección IP y el puerto del proxy si necesitas un proxy para subir las imágenes de la estación de trabajo al servidor de registro
VERSION por la versión del paquete de imágenes que descargaste de la página Descargas.
REGISTRY_IP:PORT por la dirección IP y el puerto del servidor de registro privado
CERT_PATH por la ruta del archivo de certificado de AC si tu 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. Si tu servidor de registro no requiere credenciales, especifica --need-credential=false.

Para obtener más información sobre el uso del comando bmctl push images, consulta:

bmctl push images --help

Usa tu propio espacio de nombres

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

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

./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace \
    --username=<USERNAME> \
    --password=<PASSWORD> \
    --cacert <path/to/cert.crt>

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

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

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

Puedes configurar una duplicación de registro para un clúster cuando lo creas o cada vez que actualizas un clúster existente. El método de configuración que uses depende del tipo de clúster y, en el caso de los clústeres de usuario, de si estás creando un clúster o actualizando uno. En las siguientes dos secciones, se describen los dos métodos disponibles para configurar los espejos de registro.

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

Google Distributed Cloud te permite especificar espejos de 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 espejo de 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, puedes usar este método para configurar una duplicación de registro solo 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://172.18.0.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://172.18.0.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 espejo de registro solo se aplica a los clústeres de usuarios. Debido a que 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 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 para que use el mismo espejo de registro que el clúster de administrador, sigue estos pasos:

Obtén la sección nodeConfig.registryMirror, incluidas las referencias de 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.

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 espejo de registro de tu clúster de usuarios, edita el nodeConfig.registryMirrors en el archivo de configuración del clúster de usuarios 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 las copias de seguridad del registro de un clúster de usuarios.

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. En el archivo de configuración de ejemplo, 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.

Campo `gcrKeyPath`

Si deseas que Google Distributed Cloud use automáticamente Container 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 Container Registry. Google Distributed Cloud no tiene un mecanismo para proporcionar claves de 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 la AC raíz del servidor. Este archivo de certificado debe estar en la estación de trabajo del administrador, la máquina que ejecuta los comandos 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 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:

En el archivo de configuración del clúster, actualiza el extremo, el archivo del certificado de AC y la ruta de acceso del archivo de configuración de la credencial.
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:

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

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", "http://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.