Consulte este tema para integrar clústeres de Servicio TKG con un registro de contenedor privado.

Caso de uso del registro de contenedor privado

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 utilizado con más frecuencia es Docker Hub. 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 que viene con Supervisor.

Integración del registro de contenedor privado

Para integrar un registro privado con un clúster de Servicio TKG, configure el clúster con uno o más certificados de CA autofirmados para que proporcione contenido de registro privado a través de HTTPS. Para ello, en la especificación del clúster se incluye un campo trust con el valor additionalTrustedCAs. Puede definir cualquier número de certificados de CA autofirmados en los que el clúster de TKGS debe confiar. Esta funcionalidad permite definir fácilmente una lista de certificados y actualizar los que necesiten rotación.

Puede configurar el certificado de registro privado la primera vez que crea el clúster o puede actualizar un clúster existente y proporcionar el certificado del registro privado. Para editar un clúster existente y agregar el certificado del registro privado, utilice el método de kubectl edit. Consulte Configurar un editor de texto para Kubectl.

Tenga en cuenta que la implementación del campo trust.additionalTrustedCAs difiere ligeramente entre las API compatibles para aprovisionar clústeres de TKGS. Consulte las tablas Campos de confianza de API v1alpha3 y Variable de confianza de la API v1beta1 para obtener más información.

Ejemplo de API v1alpha3

El siguiente ejemplo demuestra cómo integrar un clúster de Servicio TKG aprovisionado mediante la API v1alpha3 con un registro de contenedor privado usando su certificado de CA.

Con el API v1alpha3 del clúster de Tanzu Kubernetes, el campo trust.additionalTrustedCAs incluye uno o varios pares nombre-datos, cada uno de los cuales puede incluir un certificado de TLS para un registro privado.
Tabla 1. Campos de confianza de API v1alpha3
Campo Descripción
trust Marcador de sección. No acepta datos.
additionalTrustedCAs Marcador de sección. Incluye una matriz de certificados con campos de name y data para cada uno.
name Nombre definido por el usuario del certificado de CA.
data Contenido del certificado de CA (ca.crt) en formato PEM que está doblemente codificado en base64.
Nota: La API v1alpha3 requiere que el contenido del certificado esté codificado en base64 único. Si el contenido no tiene codificación base6 única, no se puede procesar el archivo PEM resultante.
Utilice el siguiente procedimiento para integrar Harbor con un clúster de API v1alpha3 mediante el certificado del registro de Harbor.
  1. Descargue el certificado de registro de Harbor desde la interfaz web de Harbor en la pantalla Proyectos > Repositorios.

    El archivo de certificado de CA se descarga como ca.crt.

  2. El contenido del certificado de CA se codifica con una sola base64.
  3. Incluya los campos trust.additionalTrustedCAs en la especificación del clúster y rellene con los valores name y data.
    #tkc-with-trusted-private-reg-cert.yaml
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesCluster
metadata:
  name: tkc01
  namespace: tkgs-cluster-ns
spec:
   topology:
     controlPlane:
       replicas: 3
       storageClass: tkgs-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.25.7---vmware.3-fips.1-tkg.1
     nodePools:
     - name: nodepool-01
       replicas: 3
       storageClass: tkgs-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.25.7---vmware.3-fips.1-tkg.1
   settings:
     storage:
       defaultClass: tkgs-storage-policy
     network:
       cni:
         name: antrea
       services:
         cidrBlocks: ["198.51.100.0/12"]
       pods:
         cidrBlocks: ["192.0.2.0/16"]
       serviceDomain: cluster.local
       trust:
         additionalTrustedCAs:
         - name: CompanyInternalCA-1
           data: LS0tLS1C...LS0tCg==
         - name: CompanyInternalCA-2
           data: MTLtMT1C...MT0tPg==
  4. Para rotar un certificado, kubectl edit la especificación del clúster y actualice el valor de trust.additionalTrustedCAs.data y, a continuación, inicie una actualización gradual.

Ejemplo de API v1beta1

En el siguiente ejemplo, se describe cómo integrar un clúster de Servicio TKG aprovisionado mediante la API v1beta1 con un registro de contenedor privado usando su certificado de CA.

Para integrar un registro de contenedor privado con un clúster de TKGS aprovisionado con el API de clúster v1beta1, utilice la variable trust y rellénelo con un secreto de Kubernetes que contenga el certificado del registro privado.
Tabla 2. Variable de confianza de la API v1beta1
Campo Descripción
trust Marcador de sección. No acepta datos.
additionalTrustedCAs Marcador de sección. Incluye una matriz de certificados con el nombre para cada uno.
name El nombre definido por el usuario para el campo de asignación de data en el secreto de Kubernetes que contiene el certificado de CA en formato PEM con codificación base64 doble.
Nota: La API v1beta1 requiere que el contenido del certificado tenga doble codificación base64. Si el contenido no tiene doble codificación base6, no se puede procesar el archivo PEM resultante.
Utilice el siguiente procedimiento para integrar Harbor con un clúster de API v1beta1 mediante el certificado del registro de Harbor.
  1. Descargue el certificado de registro de Harbor desde la interfaz web de Harbor en la pantalla Proyectos > Repositorios.

    El archivo de certificado de CA se descarga como ca.crt.

  2. Codificación base64 doble del contenido del certificado de CA.
  3. Cree un archivo YAML de definición de secreto de Kubernetes con el siguiente contenido.
    #additional-ca-1.yaml
apiVersion: v1
data:
  additional-ca-1: TFMwdExTMUNSGlSzZ3Jaa...VVNVWkpRMEMwdExTMHRDZz09
kind: Secret
metadata:
  name: cluster01-user-trusted-ca-secret
  namespace: tkgs-cluster-ns
type: Opaque
    Donde:
    • El valor de la asignación de data del secreto es una cadena definida por el usuario que es el nombre del certificado de CA (additional-ca-1 en este ejemplo) cuyo valor es un certificado con codificación base64 doble.
    • En la sección metadata, asigne el nombre CLUSTER-NAME-user-trusted-ca-secret al secreto, donde CLUSTER-NAME es el nombre del clúster. Este secreto se debe crear en el mismo espacio de nombres de vSphere que el clúster.
  4. Cree el secreto de Kubernetes de forma declarativa.
    kubectl apply -f additional-ca-1.yaml
  5. Compruebe la creación del secreto.
    kubeclt get secret -n tkgs-cluster-ns cluster01-user-trusted-ca-secret
NAME                                             TYPE     DATA   AGE
cluster01-user-trusted-ca-secret                 Opaque   12     2d22h
  6. Incluya la variable trust en la especificación del clúster que hace referencia el nombre de la asignación de datos del secreto, que en este ejemplo es additional-ca-1.
    #cluster-with-trusted-private-reg-cert.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: cluster01
  namespace: tkgs-cluster-ns
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["198.52.100.0/12"]
    pods:
      cidrBlocks: ["192.101.2.0/16"]
    serviceDomain: "cluster.local"
  topology:
    class: tanzukubernetescluster
    version: v1.26.5+vmware.2-fips.1-tkg.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: node-pool
          name: node-pool-01
          replicas: 3
    variables:
      - name: vmClass
        value: guaranteed-medium
      - name: storageClass
        value: tkgs-storage-profile
      - name: defaultStorageClass
        value: tkgs-storage-profile
      - name: trust
        value:
          additionalTrustedCAs:
          - name: additional-ca-1
  7. Para rotar el certificado, cree un nuevo secreto y edite la especificación del clúster con el valor adecuado. Esto activará una actualización gradual del clúster.
    Nota: El sistema no supervisa los cambios en CLUSTER-NAME-user-trusted-ca-secret. Si cambia el valor de asignación de data, estos cambios no se verán reflejados en el clúster. Deberá crear un nuevo secreto y su asignación de datos name en trust.additionalTrustCAs.