Puede utilizar un registro de contenedor externo con pods de clústeres de Tanzu Kubernetes. Se trata de una alternativa al uso de un registro de Harbor integrado.

Caso de uso de registro privado externo

Los registros de contenedores proporcionan una función crítica para las implementaciones de Kubernetes, y sirven como repositorio centralizado para almacenar y compartir imágenes de contenedor. El registro de contenedor público más utilizado es DockerHub. Existen muchas ofertas de registros de contenedores privados. VMware Harbor es un registro de contenedor privado, nativo en la nube y de código abierto. vSphere with Tanzu integra una instancia de Harbor que puede utilizar como registro de contenedor privado para pods de vSphere y para los pods que se ejecutan en clústeres de Tanzu Kubernetes. Para obtener más información, consulte Habilitar el registro de Harbor integrado en el clúster supervisor.

El registro de Harbor integrado que se incluye con vSphere with Tanzu requiere redes NSX-T. Si está utilizando redes de vSphere, no podrá utilizarlo. Además, es posible que ya esté ejecutando su propio registro de contenedor privado y que desee integrarlo con sus clústeres de Tanzu Kubernetes. En este caso, puede configurar el servicio Tanzu Kubernetes Grid para que confíe en registros privados con certificados autofirmados, lo que permite que los pods de Kubernetes que se ejecutan en clústeres de Tanzu Kubernetes utilicen el registro externo.

Requisitos del registro privado externo

Para usar un registro privado externo con clústeres de Tanzu Kubernetes, debe usar vSphere with Tanzu versión 7 U2 o posterior.

Solo puede utilizar su propio registro privado con pods de Kubernetes que se ejecuten en clústeres de Tanzu Kubernetes y máquinas virtuales del nodo de versión de Tanzu Kubernetes. No puede usar su propio registro privado con pods de vSphere que se ejecuten de forma nativa en hosts ESXi. El registro admitido para pods de vSphere es el registro de Harbor integrado en la plataforma de vSphere with Tanzu.

Una vez que configure el servicio Tanzu Kubernetes Grid para un registro privado, cualquier clúster nuevo que se aprovisione admitirá el registro privado. Para que los clústeres existentes admitan el registro privado, se requiere una actualización gradual para aplicar TkgServiceConfiguration. Consulte Actualizar clústeres de Tanzu Kubernetes. Además, la primera vez que cree una instancia personalizada de TkgServiceConfiguration, el sistema iniciará una actualización gradual.

Configuración del registro privado externo

Para utilizar su propio registro privado con clústeres de Tanzu Kubernetes, configure el servicio Tanzu Kubernetes Grid con uno o varios certificados autofirmados para que proporcione contenido de registro privado a través de HTTPS.

TkgServiceConfiguration se actualiza para admitir certificados autofirmados para el registro privado. Específicamente, se agrega una nueva sección de trust con el campo additionalTrustedCAs, lo que le permite definir un número cualquiera de certificados autofirmados en los que deberían confiar los clústeres de Tanzu Kubernetes. Esta funcionalidad permite definir fácilmente una lista de certificados y actualizar esos certificados en caso de que necesiten rotación.

Una vez que TkgServiceConfiguration se actualiza y se aplica, los certificados TLS se aplicarán a los clústeres nuevos la próxima vez que se cree un clúster. En otras palabras, la aplicación de una actualización a TkgServiceConfiguration.trust.additionalTrustedCAs no activa una actualización gradual automática de los clústeres de Tanzu Kubernetes.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TkgServiceConfiguration
metadata:
  name: tkg-service-configuration
spec:
  defaultCNI: antrea
  trust:
    additionalTrustedCAs:
      - name: first-cert-name
        data: base64-encoded string of a PEM encoded public cert 1
      - name: second-cert-name
        data: base64-encoded string of a PEM encoded public cert 2
Para aplicar la actualización, ejecute el siguiente comando.
kubectl apply -f tkgserviceconfiguration.yaml

Debido a que la especificación de servicio Tanzu Kubernetes Grid se está actualizando con los certificados del registro privado, no es necesario agregar la clave pública al clúster de Tanzu Kubernetes kubeconfig como lo hace cuando utiliza el registro de Harbor integrado con clústeres de Tanzu Kubernetes.

Configurar una carga de trabajo de Tanzu Kubernetes para extraer imágenes de un registro de contenedor privado

Para extraer imágenes de un registro de contenedor privado para una carga de trabajo del clúster de Tanzu Kubernetes, configure el YAML de carga de trabajo con los detalles del registro privado.

Este procedimiento se puede utilizar para extraer imágenes de un registro de contenedor privado o del registro de Harbor incrustado. En este ejemplo, creamos una especificación de pod que utilizará una imagen almacenada en el registro de Harbor integrado y utilizará el secreto de extracción de imágenes que se configuró anteriormente.
  1. Cree un ejemplo de especificación de Pod con los detalles del registro privado.
    apiVersion: v1
    kind: Pod
    metadata:
      name: <workload-name>
      namespace: <kubernetes-namespace>
    spec:
      containers:
      - name: private-reg-container
        image: <Registry-IP-Address>/<vsphere-namespace>/<image-name>:<version>
      imagePullSecrets:
      - name: <registry-secret-name>
    • Reemplace <workload-name> por el nombre de la carga de trabajo del pod.
    • Reemplace <kubernetes-namespace> por el espacio de nombres de Kubernetes del clúster en el que se creará el pod. Debe ser el mismo espacio de nombres de Kubernetes en el que se almacena el secreto de extracción de imágenes del servicio de registro en el clúster de Tanzu Kubernetes (por ejemplo, el espacio de nombres predeterminado).
    • Reemplace <Registry-IP-Address> por la dirección IP de la instancia del registro de Harbor integrado que se ejecuta en el clúster supervisor.
    • Reemplace <vsphere-namespace> por el espacio de nombres de vSphere en el que se aprovisiona la instancia de Tanzu Kubernetes de destino.
    • Reemplace <image-name> por el nombre de imagen que desee.
    • Reemplace <version> por una versión adecuada de la imagen (por ejemplo, "más reciente").
    • Reemplace <registry-secret-name> por el nombre del secreto de extracción de imágenes del servicio de registro que creó anteriormente.
  2. Cree una carga de trabajo en el clúster de Tanzu Kubernetes basada en la especificación de pod que definió.
    kubectl --kubeconfig=<path>/cluster-kubeconfig apply -f <pod.yaml>

    El pod se debe crear a partir de la imagen extraída del registro.

Campos de confianza para registros privados externos

Agregue una entrada de certificado (cadena con codificación Base64 de un certificado público con codificación PEM) a la sección additionalTrustedCAs de TkgServiceConfiguration. Los datos son certificados públicos almacenados en texto sin formato en TkgServiceConfiguration.

Tabla 1. Campos de confianza para registros privados
Campo Descripción
trust Marcador de sección. No acepta datos.
additionalTrustedCAs Marcador de sección. Incluye una matriz de certificados con nombre y datos para cada uno.
name El nombre del certificado de TLS.
data La cadena codificada en base64 de un certificado público con codificación PEM.

Quitar certificados de registro privado externo

Elimine un certificado de la lista de certificados de la sección additionalTrustedCAs de TkgServiceConfiguration y aplique TkgServiceConfiguration al servicio Tanzu Kubernetes Grid.

Rotación de certificados de registro privado externo

Para rotar un certificado, el administrador de VI o el ingeniero de desarrollo y operaciones cambiaría el contenido del certificado en TkgServiceConfiguration o la especificación del clúster de Tanzu Kubernetes y aplicaría esa configuración para activar una actualización gradual de ese TKC.

Solucionar problemas de certificados de registro privado externo

Si configura el servicio Tanzu Kubernetes Grid con los certificados en los que confiar y agrega el certificado autofirmado al clúster kubeconfig, debería poder extraer correctamente una imagen de contenedor de un registro privado que use ese certificado autofirmado.

El siguiente comando puede ayudarle a determinar si la imagen del contenedor se extrajo correctamente para una carga de trabajo del pod:

kubectl describe pod PODNAME

Este comando muestra el estado detallado y los mensajes de error para un pod determinado. Un ejemplo de intento de extracción de una imagen antes de agregar certificados personalizados al clúster:

Events:
  Type     Reason                        Age               From               Message
  ----     ------                        ----              ----               -------
  Normal   Scheduled                     33s               default-scheduler  ...
  Normal   Image                         32s               image-controller   ...
  Normal   Image                         15s               image-controller   ...
  Normal   SuccessfulRealizeNSXResource  7s (x4 over 31s)  nsx-container-ncp  ...
  Normal   Pulling                       7s                kubelet            Waiting test-gc-e2e-demo-ns/testimage-8862e32f68d66f727d1baf13f7eddef5a5e64bbd-v10612
  Warning  Failed                        4s                kubelet            failed to get images: ... Error: ... x509: certificate signed by unknown authority
Y, al ejecutar el siguiente comando:
kubectl get pods
El error ErrImagePull también se puede ver en la vista de estado general del pod:
NAME                                         READY   STATUS         RESTARTS   AGE
testimage-nginx-deployment-89d4fcff8-2d9pz   0/1     Pending        0          17s
testimage-nginx-deployment-89d4fcff8-7kp9d   0/1     ErrImagePull   0          79s
testimage-nginx-deployment-89d4fcff8-7mpkj   0/1     Pending        0          21s
testimage-nginx-deployment-89d4fcff8-fszth   0/1     ErrImagePull   0          50s
testimage-nginx-deployment-89d4fcff8-sjnjw   0/1     ErrImagePull   0          48s
testimage-nginx-deployment-89d4fcff8-xr5kg   0/1     ErrImagePull   0          79s
Los errores “x509: certificado firmado por entidad desconocida” y “ErrImagePull” indican que el clúster no está configurado con el certificado correcto para conectarse al registro de contenedor privado. Falta el certificado o está mal configurado.

Si experimenta errores al conectarse a un registro privado después de configurar los certificados, puede comprobar si los certificados aplicados en la configuración se aplican al clúster. Puede comprobar si los certificados se aplicaron correctamente en su configuración mediante SSH.

Se pueden realizar dos pasos de investigación conectándose a un nodo de trabajador a través de SSH.
  1. Compruebe la carpeta /etc/ssl/certs/ en busca de archivos denominados tkg-<cert_name>.pem, donde <cert_name> es la propiedad "name" del certificado agregado en TkgServiceConfiguration. Si los certificados coinciden con lo que está presente en TkgServiceConfiguration, y sigue sin poder usarse un registro privado, complete el siguiente paso para profundizar en el diagnóstico.
  2. Ejecute la siguiente prueba de conexión openssl con el servidor de destino mediante certificados autofirmados ejecutando el comando openssl s_client -connect hostname:port_num, donde hostname es el nombre de host o el nombre DNS del registro privado que utiliza certificados autofirmados, y port_num es el número de puerto en el que se ejecuta el servicio (por lo general, el puerto 443 para HTTPS). Puede comprobar exactamente qué error devuelve openssl cuando intenta conectarse al endpoint que utiliza certificados autofirmados y solucionar la situación desde allí; por ejemplo, agregando los certificados correctos a TkgServiceConfiguration. Si el clúster de Tanzu Kubernetes está integrado con el certificado incorrecto, deberá actualizar la configuración de servicio Tanzu Kubernetes Grid con los certificados correctos, eliminar el clúster de Tanzu Kubernetes y, a continuación, volver a crearlo con la configuración que contiene los certificados correctos.