Consulte estas instrucciones para aprovisionar un clúster de TKG basado en una ClusterClass personalizada. Tenga en cuenta que estas instrucciones son específicas para entornos de vSphere 8 U1.

Requisitos previos

El procedimiento para aprovisionar un clúster de TKG basado en una ClusterClass personalizada está disponible a partir de la versión vSphere 8 U1. Si utiliza vSphere 8 U2, consulte Ejemplo de v1beta1: clúster basado en una ClusterClass personalizada (flujo de trabajo de vSphere 8 U2 y versiones posteriores).

Debe cumplir los siguientes requisitos previos.
  • Entorno de vSphere 8 U1
  • Administración de cargas de trabajo habilitada
  • Supervisor configurados
  • Cliente de Ubuntu con Herramientas de la CLI de Kubernetes para vSphere instalado
Atención: La ClusterClass personalizada es una función experimental de Kubernetes según la documentación de la API del clúster ascendente. Debido a la variedad de personalizaciones disponibles con la ClusterClass personalizada, VMware no puede probar ni validar todas las personalizaciones posibles. Los clientes son responsables de probar, validar y solucionar los problemas que puedan surgir en sus clústeres ClusterClass personalizados. Los clientes pueden abrir tickets de soporte relacionados con sus clústeres ClusterClass personalizados. Sin embargo, el soporte de VMware tan solo puede ayudar dentro de unos límites y no puede garantizar la resolución de todos los problemas que se abran para los clústeres ClusterClass personalizados. Los clientes deben tener en cuenta estos riesgos antes de implementar clústeres ClusterClass personalizados en entornos de producción.

Parte 1: Crear el ClusterClass personalizado

La primera parte implica la creación de una ClusterClass personalizada mediante la clonación de la ClusterClass predeterminada, que se denomina tanzukubernetescluster.
  1. Cree un espacio de nombres de vSphere denominado custom-ns.
  2. Inicie sesión en Supervisor.
  3. Cambie el contexto al espacio de nombres de vSphere denominado custom-ns.
  4. Obtenga la ClusterClass predeterminada.
    kubectl get clusterclass tanzukubernetescluster -o json
  5. Cree una ClusterClass personalizada denominada custom-cc mediante la clonación de la ClusterClass predeterminada.
    kubectl get clusterclass tanzukubernetescluster -o json | jq '.metadata.name="custom-cc"' | kubectl apply -f -
    Resultado esperado: 
    clusterclass.cluster.x-k8s.io/custom-cc created
  6. Obtenga la ClusterClass personalizada.
    kubectl get clusterclass custom-cc -o json

    Si fuera necesario, puede utilizar "less" para ver la ClusterClass personalizada.

    kubectl get clusterclass custom-cc -o json | less
    Nota: Introduzca el comando "q" para salir de "less".

Parte 2: Crear objetos de Supervisor necesarios para aprovisionar el clúster de TKG

La siguiente parte consiste en crear los objetos de Supervisor necesarios para la implementación inicial de un clúster de TKG personalizado mediante la ClusterClass personalizada.
Nota: De forma predeterminada, se utiliza el nombre de clúster "ccc-cluster". Si utiliza un nombre de clúster diferente, deberá cambiarlo en los campos correspondientes.
  1. Cree el emisor del certificado de extensiones autofirmado.
    #self-signed-extensions-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: self-signed-extensions-issuer
spec:
  selfSigned: {}
    kubectl apply -f self-signed-extensions-issuer.yaml -n custom-ns
    Resultado esperado: 
    issuer.cert-manager.io/self-signed-extensions-issuer created
  2. Cree el secreto para el certificado de CA de las extensiones.
    #extensions-ca-certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ccc-cluster-extensions-ca
spec:
  commonName: kubernetes-extensions
  duration: 87600h0m0s
  isCA: true
  issuerRef:
    kind: Issuer
    name: self-signed-extensions-issuer
  secretName: ccc-cluster-extensions-ca
  usages:
  - digital signature
  - cert sign
  - crl sign
    kubectl apply -f extensions-ca-certificate.yaml -n custom-ns
    Resultado esperado: 
    certificate.cert-manager.io/ccc-cluster-extensions-ca created
  3. Cree el emisor del certificado de CA de las extensiones.
    #extensions-ca-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ccc-cluster-extensions-ca-issuer
spec:
  ca:
    secretName: ccc-cluster-extensions-ca
    kubectl apply -f extensions-ca-issuer.yaml -n custom-ns
    Resultado esperado: 
    issuer.cert-manager.io/ccc-cluster-extensions-ca-issuer created
  4. Cree el secreto para el certificado del servicio de autenticación.
    #auth-svc-cert.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ccc-cluster-auth-svc-cert
spec:
  commonName: authsvc
  dnsNames:
  - authsvc
  - localhost
  - 127.0.0.1
  duration: 87600h0m0s
  issuerRef:
    kind: Issuer
    name: ccc-cluster-extensions-ca-issuer
  secretName: ccc-cluster-auth-svc-cert
  usages:
  - server auth
  - digital signature
    kubectl apply -f auth-svc-cert.yaml -n custom-ns
    Resultado esperado: 
    certificate.cert-manager.io/ccc-cluster-auth-svc-cert created
  5. Compruebe la creación de los emisores y los certificados.
    kubectl get issuers -n custom-ns
NAME                               READY   AGE
ccc-cluster-extensions-ca-issuer   True    2m57s
self-signed-extensions-issuer      True    14m

    kubectl get certs -n custom-ns
NAME                        READY   SECRET                      AGE
ccc-cluster-auth-svc-cert   True    ccc-cluster-auth-svc-cert   34s
ccc-cluster-extensions-ca   True    ccc-cluster-extensions-ca   5m

Parte 3: Crear un clúster de TKG basado en la ClusterClass personalizada

Utilice la API v1beta1 del clúster para crear un clúster basado en una ClusterClass. Un clúster v1beta1 basado en una ClusterClass personalizada requiere el siguiente conjunto mínimo de variables.
Variable Descripción
vmClass Consulte Uso de clases de máquinas virtuales con clústeres de Servicio TKG.
storageClass Consulte Configurar el almacenamiento persistente para el espacio de nombres de vSphere.
ntp Servidor NTP utilizado para habilitar Supervisor.
extensionCert Se genera automáticamente después de crear el "certificado de CA de extensiones" en la sección anterior.
clusterEncryptionConfigYaml la siguiente sección revisará el proceso de obtención de este archivo
  1. Cree el secreto de cifrado.
    #encryption-secret.yaml
apiVersion: v1
data:
  key: all3dzZpODFmRmh6MVlJbUtQQktuN2ViQzREbDBQRHlxVk8yYXRxTW9QQT0=
kind: Secret
metadata:
  name: ccc-cluster-encryption
type: Opaque
    kubectl apply -f encryption-secret.yaml -n custom-ns
    Resultado esperado: 
    secret/ccc-cluster-encryption created
  2. Recopile el servidor NTP de Supervisor.
    kubectl -n vmware-system-vmop get configmap vmoperator-network-config -o jsonpath={.data.ntpservers}
  3. Cree el manifiesto de cluster-with-ccc.yaml para aprovisionar el clúster.
    #cluster-with-ccc.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: ccc-cluster
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - 193.0.0.0/16
    serviceDomain: managedcluster1.local
    services:
      cidrBlocks:
      - 198.201.0.0/16
  topology:
    class: custom-cc
    version: v1.26.5---vmware.2-fips.1-tkg.1
    controlPlane:
      metadata: {}
      replicas: 3
    workers:
      machineDeployments:
        - class: node-pool
          metadata: { }
          name: node-pool-workers
          replicas: 3
    variables:
    - name: vmClass
      value: guaranteed-medium
    - name: storageClass
      value: tkg-storage-profile
    - name: ntp
      value: time.acme.com
    - name: extensionCert
      value:
        contentSecret:
          key: tls.crt
          name: ccc-cluster-extensions-ca
    - name: clusterEncryptionConfigYaml
      value: LS0tCm...Ht9Cg==
    En el manifiesto del clúster, compruebe o actualice los siguientes campos:
    Parámetro Descripción
    metadata.name Nombre del clúster v1beta1.
    spec.topology.class Nombre de la ClusterClass personalizada.
    spec.topology.version Versión de versión de Tanzu Kubernetes
    spec.topology.variables.storageClass.value StoragePolicy asociada al espacio de nombres de vSphere en el que se aprovisionará el clúster
    spec.topology.variables.ntp.value Dirección del servidor NTP
    spec.topology.variables.extensionCert.value.contentSecret.name Verificar
    spec.topology.variables.clusterEncryptionConfigYaml.value Rellene con el valor de data.key del secreto ClusterEncryptionConfig
  4. Cree el clúster en función de la ClusterClass personalizada.
    kubectl apply -f cluster-with-ccc.yaml -n custom-ns
    Resultado esperado: 
    cluster.cluster.x-k8s.io/ccc-cluster created

    Mediante vSphere Client, compruebe que se ha creado el clúster.

  5. Inicie sesión en el clúster de TKG.
    kubectl vsphere login --server=xxx.xxx.xxx.xxx --vsphere-username [email protected] --tanzu-kubernetes-cluster-name ccc-cluster --tanzu-kubernetes-cluster-namespace custom-ns

Parte 4: Crear objetos de Supervisor necesarios para administrar el clúster de TKG

Una vez que se aplica el clúster con CCC, varios controladores intentarán aprovisionarlo; no obstante, los recursos de infraestructura subyacentes aún requieren objetos adicionales para arrancar correctamente.
Parámetro Valor
Autenticación Los valores de autenticación deben recopilarse y actualizarse en un archivo denominado values.yaml
Codificado en Base64 El archivo values.yaml se codificará en forma de cadena en base64
guest-cluster-auth-service-data-values.yaml Esta cadena se agregará al archivo guest-cluster-auth-service-data-values.yaml descargado de CCC_config_yamls.tar.gz antes de aplicar el archivo
Secreto GuestClusterAuthSvcDataValues Por último, el arranque del clúster invitado debe modificarse para que haga referencia al secreto GuestClusterAuthSvcDataValues recién creado.
  1. Cambie el contexto a la instancia de espacio de nombres de vSphere en la que se aprovisiona el clúster.
    kubectl config use-context custom-ns
  2. Obtenga el valor de authServicePublicKeys.
    kubectl -n vmware-system-capw get configmap vc-public-keys -o jsonpath="{.data.vsphere\.local\.json}"
    Copie el resultado en un archivo de texto denominado values.yaml. 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
  3. Obtenga el UID del clúster para actualizar las authServicePublicKeys.
    kubectl get cluster -n custom-ns ccc-cluster -o yaml | grep uid
  4. En la sección authServicePublicKeys del archivo values.yaml, anexe el UID del clúster al valor "client_id".

    Sintaxis: vmware-tes:vc:vns:k8s:clusterUID

    Por ejemplo: 
    vmware-tes:vc:vns:k8s:7d95b50b-4fd4-4642-82a3-5dbfe87f499c
  5. Obtenga el valor del certificado (reemplace ccc-cluster por el nombre de clúster seleccionado).
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.crt}" | base64 -d
  6. Agregue el certificado a values.yaml.

    Agregue el contenido del certificado debajo de la sección authServicePublicKeys.

    Nota: El certificado debe tener una sangría de 4 espacios para evitar errores.
    Por ejemplo: 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
ceritificate: |
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIQMibGSjeuJelQoPxCof/+xzANBgkqhkiG9w0BAQsFADAg
    ...
    sESk/RDTB1UAvi8PD3zcbEKZuRxuo4IAJqFFbAabwULhjUo0UwT+dIJo1gLf5/ep
    VoIRJS7j6VT98WbKyZp5B4I=
    -----END CERTIFICATE-----
  7. Obtenga el valor de privateKey.
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.key}"
  8. Compruebe su archivo values.yaml.
    authServicePublicKeys: '{"issuer_url":"https://10.197.79.141/openidconnect/vsphere.local","client_id":"vmware-tes:vc:vns:k8s:7d95...499c",...SShrDw=="]}]}}'
certificate: |
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIQWQyXAQDRMhgrGre8ysVN0DANBgkqhkiG9w0BAQsFADAg
    ...
    uJSBP49sF0nKz5nf7w+BdYE=
    -----END CERTIFICATE-----
privateKey: LS0tLS1CRUdJTi...VktLS0tLQo=
  9. Obtenga el valor hash del archivo values.yaml para la codificación en Base64 para recopilar la salida del archivo guest-cluster-auth-service-data-values.yaml.
    base64 -i values.yaml -w 0
  10. Cree el archivo guest-cluster-auth-service-data-values.yaml.
    A continuación se muestra una plantilla para el secreto. 
    apiVersion: v1
data:
  values.yaml: YXV0a...ExRbz0K
kind: Secret
metadata:
  labels:
    tkg.tanzu.vmware.com/cluster-name: ccc-cluster
    tkg.tanzu.vmware.com/package-name: guest-cluster-auth-service.tanzu.vmware.com.1.3.0+tkg.2-vmware
  name: ccc-cluster-guest-cluster-auth-service-data-values
type: Opaque
    Consulte la siguiente tabla para rellenar los valores secretos esperados.
    Parámetro Valor
    data.values.yaml

    Cadena de values.yaml codificada en Base64
    metadata.labels.cluster-name

    Nombre del clúster, como ccc-cluster
    metadata.labels.package-name

    guest-cluster-auth-service.tanzu.vmware.com.version

    Para obtener este valor, ejecute el comando kubectl get tkr v1.26.5---vmware.2-fips.1-tkg.1 -o yaml

    Cambie la versión de TKR según la versión que esté utilizando
    metadata.name

    Nombre del clúster, como ccc-cluster
  11. Cree el secreto guest-cluster-auth-service-data-values.yaml.
    kubectl apply -f guest-cluster-auth-service-data-values.yaml -n custom-ns
  12. Edite el arranque del clúster para hacer referencia al secreto.
    kubectl edit clusterbootstrap ccc-cluster -n custom-ns
  13. Agregue las siguientes líneas debajo de la línea guest-cluster-auth-service.tanzu.vmware.com.version:.
    valuesFrom:
  secretRef: ccc-cluster-guest-cluster-auth-service-data-values
    Por ejemplo: 
    spec:
  additionalPackages:
  - refName: guest-cluster-auth-service.tanzu.vmware.com.1.3.0+tkg.2-vmware
    valuesFrom:
      secretRef: ccc-cluster-guest-cluster-auth-service-data-values
  14. Guarde y salga para aplicar las modificaciones de clusterbootstrap.

Parte 5: Configurar la seguridad de pods

Si utiliza TKR 1.25 y versiones posteriores, configure la seguridad de pods para el espacio de nombres de vSphere denominado custom-ns. Consulte Configurar PSA para TKR 1.25 y versiones posteriores.

Si utiliza TKR 1.24 y versiones anteriores, los pods del clúster requieren el enlace a la directiva de seguridad de pods. Para aplicar los objetos de recursos necesarios en el nivel de clúster, utilice el siguiente proceso.
  1. Recopile el kubeconfig del clúster de TKG.
    kubectl -n custom-ns get secret ccc-cluster-kubeconfig -o jsonpath="{.data.value}" | base64 -d > ccc-cluster-kubeconfig
  2. Cree el archivo psp.yaml. 
    apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: tanzu-system-kapp-ctrl-restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - configMap
    - emptyDir
    - projected
    - secret
    - downwardAPI
    - persistentVolumeClaim
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false
  3. Aplique la directiva de seguridad de pods.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f psp.yaml
  4. Inicie sesión en el clúster de TKG.
    kubectl vsphere login --server=10.197.154.66 --vsphere-username [email protected] --insecure-skip-tls-verify --tanzu-kubernetes-cluster-name ccc-cluster --tanzu-kubernetes-cluster-namespace custom-ns
  5. Enumere los espacios de nombres.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl get ns -A
    NAME                           STATUS   AGE
default                        Active   13d
kube-node-lease                Active   13d
kube-public                    Active   13d
kube-system                    Active   13d
secretgen-controller           Active   13d
tkg-system                     Active   13d
vmware-system-antrea           Active   13d
vmware-system-cloud-provider   Active   13d
vmware-system-csi              Active   13d
vmware-system-tkg              Active   13d

Parte 6: Sincronizar funciones de SSO de vSphere con el clúster de TKG personalizado

El objeto Rolebinding para los usuarios de vCenter Single Sign-On que están integrados en los espacios de nombres de vSphere debe sincronizarse desde Supervisor con el clúster de TKG para que los desarrolladores administren las cargas de trabajo del clúster.

Este proceso requiere que se exporte la lista de RoleBinding existente desde Supervisor, que se recopilen los RoleBinding que tengan la función "editar" y que se cree el archivo sync-cluster-edit-rolebinding.yaml y, a continuación, se aplique al clúster de TKG mediante su KUBECONFIG.
  1. Recopile los RoleBindings existentes en Supervisor.
    kubectl get rolebinding -n custom-ns  -o yaml
  2. En la lista de objetos RoleBinding devuelta, identifique los que tengan roleRef.name igual a "editar".
    Por ejemplo: 
    apiVersion: v1
items:
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T18:44:45Z"
    name: ccc-cluster-8lr5x-ccm
    namespace: custom-ns
    ownerReferences:
    - apiVersion: vmware.infrastructure.cluster.x-k8s.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: ProviderServiceAccount
      name: ccc-cluster-8lr5x-ccm
      uid: b5fb9f01-9a55-4f69-8673-fadc49012994
    resourceVersion: "108766602"
    uid: eb93efd4-ae56-4d9f-a745-d2782885e7fb
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: ccc-cluster-8lr5x-ccm
  subjects:
  - kind: ServiceAccount
    name: ccc-cluster-8lr5x-ccm
    namespace: custom-ns
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T18:44:45Z"
    name: ccc-cluster-8lr5x-pvcsi
    namespace: custom-ns
    ownerReferences:
    - apiVersion: vmware.infrastructure.cluster.x-k8s.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: ProviderServiceAccount
      name: ccc-cluster-8lr5x-pvcsi
      uid: d9342f8f-13d2-496d-93cb-b24edfacb5c1
    resourceVersion: "108766608"
    uid: fd1820c7-7993-4299-abb7-bb67fb17f1fd
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: ccc-cluster-8lr5x-pvcsi
  subjects:
  - kind: ServiceAccount
    name: ccc-cluster-8lr5x-pvcsi
    namespace: custom-ns
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T16:58:06Z"
    labels:
      managedBy: vSphere
    name: wcp:custom-ns:group:vsphere.local:administrators
    namespace: custom-ns
    resourceVersion: "108714148"
    uid: d74a98c7-e7da-4d71-b1d5-deb60492d429
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: edit
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: sso:[email protected]
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2023-08-25T16:58:21Z"
    labels:
      managedBy: vSphere
    name: wcp:custom-ns:user:vsphere.local:administrator
    namespace: custom-ns
    resourceVersion: "108714283"
    uid: 07f7dbba-2670-4100-a59b-c09e4b2edd6b
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: edit
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: sso:[email protected]
kind: List
metadata:
  resourceVersion: ""
  3. Cree un archivo denominado sync-cluster-edit-rolebinding.yaml para agregar los RoleBindings adicionales que no sean el valor predeterminado [email protected]. Por ejemplo:
    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    run.tanzu.vmware.com/vmware-system-synced-from-supervisor: "yes"
  name: vmware-system-auth-sync-wcp:custom-ns:group:vsphere.local:administrators
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: sso:[email protected]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    run.tanzu.vmware.com/vmware-system-synced-from-supervisor: "yes"
  name: vmware-system-auth-sync-wcp:custom-ns:group:SSODOMAIN.COM:testuser
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: sso:[email protected]
    Nota: En el campo metadata.name, la función de usuario se antepone con vmware-system-auth-sync- para todos los usuarios. Las entradas metadata.name y subjects.name requerirán modificaciones para todas las funciones no predeterminadas.
  4. Aplique la configuración sync-cluster-edit-rolebinding.yaml para sincronizar los RoleBindings.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f sync-cluster-edit-rolebinding.yaml