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
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.
- 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.
- Reemplace
- 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.
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
kubectl get pods
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 79sLos 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.
- Compruebe la carpeta
/etc/ssl/certs/
en busca de archivos denominadostkg-<cert_name>.pem
, donde<cert_name>
es la propiedad "name" del certificado agregado enTkgServiceConfiguration
. Si los certificados coinciden con lo que está presente enTkgServiceConfiguration
, y sigue sin poder usarse un registro privado, complete el siguiente paso para profundizar en el diagnóstico. - 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 aTkgServiceConfiguration
. 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.