Fare riferimento a queste istruzioni per eseguire il provisioning di un cluster TKG basato su una ClusterClass personalizzata. Si tenga presente che queste istruzioni sono specifiche per ambienti vSphere 8 U1.

Prerequisiti

La procedura per il provisioning di un cluster TKG basato su una ClusterClass personalizzata è disponibile a partire dalla versione vSphere 8 U1. Se si utilizza vSphere 8 U2, vedere Esempio v1beta1: cluster basato su una ClusterClass personalizzata (workflow di vSphere 8 U2 e versioni successive).

Attenersi ai seguenti prerequisiti.
  • Ambiente vSphere 8 U1
  • Gestione del carico di lavoro abilitata
  • Supervisore configurato
  • Client Ubuntu con Strumenti CLI Kubernetes di vSphere installato
Avvertimento: La ClusterClass personalizzata è una funzionalità Kubernetes sperimentale così come illustrata nella documentazione relativa all'API del cluster upstream. Poiché la gamma di personalizzazioni disponibili con la ClusterClass personalizzata è molto vasta, VMware non può testare o convalidare tutte le personalizzazioni possibili. I clienti sono responsabili del test, della convalida e della risoluzione dei problemi dei propri cluster con ClusterClass personalizzata. I clienti possono aprire ticket di supporto relativi ai cluster con ClusterClass personalizzata. Tuttavia, l'assistenza VMware è limitata solo al massimo sforzo possibile e non può garantire la risoluzione di tutti i problemi aperti per i cluster con ClusterClass personalizzata. I clienti devono essere consapevoli di questi rischi prima di distribuire cluster con ClusterClass personalizzata negli ambienti di produzione.

Parte 1: creazione di una ClusterClass personalizzata

La prima parte prevede la creazione di una ClusterClass personalizzata mediante clonazione della ClusterClass predefinita denominata tanzukubernetescluster.
  1. Creare uno Spazio dei nomi vSphere denominato custom-ns.
  2. Accedere a Supervisore.
  3. Passare al contesto dello Spazio dei nomi vSphere denominato custom-ns.
  4. Ottenere la ClusterClass predefinita.
    kubectl get clusterclass tanzukubernetescluster -o json
  5. Creare una ClusterClass personalizzata denominata custom-cc clonando la ClusterClass predefinita.
    kubectl get clusterclass tanzukubernetescluster -o json | jq '.metadata.name="custom-cc"' | kubectl apply -f -
    Risultato previsto: 
    clusterclass.cluster.x-k8s.io/custom-cc created
  6. Ottenere la ClusterClass personalizzata.
    kubectl get clusterclass custom-cc -o json

    Se necessario, è possibile utilizzare il comando less per visualizzare la ClusterClass personalizzata.

    kubectl get clusterclass custom-cc -o json | less
    Nota: Eseguire il comando "q" per chiudere less.

Parte 2: creazione degli oggetti Supervisore necessari per il provisioning del cluster TKG

La parte successiva consiste nel creare gli oggetti Supervisore necessari per la distribuzione iniziale di un cluster TKG personalizzato utilizzando la ClusterClass personalizzata.
Nota: Per impostazione predefinita, viene utilizzato il nome cluster "ccc-cluster". Se si utilizza un nome cluster diverso, sarà necessario modificarlo nei campi appropriati.
  1. Creare l'emittente del certificato delle estensioni autofirmato.
    #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
    Risultato previsto: 
    issuer.cert-manager.io/self-signed-extensions-issuer created
  2. Creare il segreto per il certificato CA delle estensioni.
    #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
    Risultato previsto: 
    certificate.cert-manager.io/ccc-cluster-extensions-ca created
  3. Creare l'emittente per il certificato CA delle estensioni.
    #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
    Risultato previsto: 
    issuer.cert-manager.io/ccc-cluster-extensions-ca-issuer created
  4. Creare il segreto per il certificato del servizio di autenticazione.
    #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
    Risultato previsto: 
    certificate.cert-manager.io/ccc-cluster-auth-svc-cert created
  5. Verificare la creazione di emittenti e certificati.
    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: creazione di un cluster TKG basato sulla ClusterClass personalizzata

Utilizzare l' API v1beta1 del cluster per creare un cluster basato su una ClusterClass. Un cluster v1beta1 basato su una ClusterClass personalizzata richiede il seguente set minimo di variabili.
Variabile Descrizione
vmClass Vedere Utilizzo di classi di macchine virtuali con i cluster Servizio TKG.
storageClass Vedere Configurazione dello storage persistente per Spazio dei nomi vSphere.
ntp Server NTP utilizzato per abilitare Supervisore.
extensionCert Generato automaticamente dopo la creazione del "certificato CA delle estensioni" nella sezione precedente.
clusterEncryptionConfigYaml Nella sezione che segue viene illustrato il processo per recuperare questo file
  1. Creare il segreto di crittografia.
    #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
    Risultato previsto: 
    secret/ccc-cluster-encryption created
  2. Raccogliere il server NTP da Supervisore.
    kubectl -n vmware-system-vmop get configmap vmoperator-network-config -o jsonpath={.data.ntpservers}
  3. Creare il manifesto cluster-with-ccc.yaml per eseguire il provisioning del cluster.
    #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==
    Nel manifesto del cluster verificare o aggiornare i campi seguenti:
    Parametro Descrizione
    metadata.name Nome del cluster v1beta1.
    spec.topology.class Nome della ClusterClass personalizzata.
    spec.topology.version Versione di Release di Tanzu Kubernetes
    spec.topology.variables.storageClass.value StoragePolicy collegato allo Spazio dei nomi vSphere in cui verrà eseguito il provisioning del cluster
    spec.topology.variables.ntp.value Indirizzo del server NTP
    spec.topology.variables.extensionCert.value.contentSecret.name Verifica
    spec.topology.variables.clusterEncryptionConfigYaml.value Compilare con il valore data.key del segreto ClusterEncryptionConfig
  4. Creare il cluster in base alla ClusterClass personalizzata.
    kubectl apply -f cluster-with-ccc.yaml -n custom-ns
    Risultato previsto: 
    cluster.cluster.x-k8s.io/ccc-cluster created

    Utilizzando vSphere Client, verificare che il cluster sia stato creato.

  5. Accedere al cluster 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: creazione degli oggetti Supervisore necessari per gestire il cluster TKG

Una volta applicato il cluster con CCC, vari controller cercheranno di eseguirne il provisioning. Tuttavia, le risorse dell'infrastruttura sottostante richiedono che venga comunque eseguito il bootstrap degli oggetti aggiuntivi.
Parametro Valore
Autenticazione I valori di autenticazione devono essere raccolti e aggiornati in un file denominato values.yaml
Codifica Base64 Il file values.yaml verrà codificato in una stringa base64
guest-cluster-auth-service-data-values.yaml Questa stringa verrà aggiunta al file guest-cluster-auth-service-data-values.yaml scaricato da CCC_config_yamls.tar.gz prima di applicare il file
Segreto GuestClusterAuthSvcDataValues Infine, è necessario modificare il bootstrap del cluster guest in modo che faccia riferimento al segreto GuestClusterAuthSvcDataValues appena creato.
  1. Passare al contesto dello Spazio dei nomi vSphere in cui viene eseguito il provisioning del cluster.
    kubectl config use-context custom-ns
  2. Ottenere il valore authServicePublicKeys.
    kubectl -n vmware-system-capw get configmap vc-public-keys -o jsonpath="{.data.vsphere\.local\.json}"
    Copiare il risultato in un file di testo denominato values.yaml. 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
  3. Ottenere l'UID del cluster per aggiornare il authServicePublicKeys.
    kubectl get cluster -n custom-ns ccc-cluster -o yaml | grep uid
  4. Nella sezione authServicePublicKeys del file values.yaml, aggiungere l'UID del cluster al valore "client_id".

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

    Ad esempio: 
    vmware-tes:vc:vns:k8s:7d95b50b-4fd4-4642-82a3-5dbfe87f499c
  5. Ottenere il valore del certificato (sostituire ccc-cluster con il nome cluster scelto).
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.crt}" | base64 -d
  6. Aggiungere il certificato a values.yaml.

    Aggiungere il contenuto del certificato sotto la sezione authServicePublicKeys.

    Nota: Per evitare errori, il certificato deve rientrare in 4 spazi.
    Ad esempio: 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
ceritificate: |
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIQMibGSjeuJelQoPxCof/+xzANBgkqhkiG9w0BAQsFADAg
    ...
    sESk/RDTB1UAvi8PD3zcbEKZuRxuo4IAJqFFbAabwULhjUo0UwT+dIJo1gLf5/ep
    VoIRJS7j6VT98WbKyZp5B4I=
    -----END CERTIFICATE-----
  7. Ottenere il valore di privateKey.
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.key}"
  8. Verificare il file 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. Utilizzare il simbolo di cancelletto per il file values.yaml con codifica Base64 per raccogliere l'output per il file guest-cluster-auth-service-data-values.yaml.
    base64 -i values.yaml -w 0
  10. Creare il file guest-cluster-auth-service-data-values.yaml.
    Ecco un modello per il segreto. 
    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
    Fare riferimento alla tabella seguente per popolare i valori segreti previsti.
    Parametro Valore
    data.values.yaml

    Stringa di values.yaml con codifica Base64
    metadata.labels.cluster-name

    Nome del cluster, ad esempio ccc-cluster
    metadata.labels.package-name

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

    Per ottenere questo valore, eseguire il comando kubectl get tkr v1.26.5---vmware.2-fips.1-tkg.1 -o yaml

    Modificare la versione di TKR in base alla versione in uso
    metadata.name

    Nome del cluster, ad esempio ccc-cluster
  11. Creare il segreto guest-cluster-auth-service-data-values.yaml.
    kubectl apply -f guest-cluster-auth-service-data-values.yaml -n custom-ns
  12. Modificare il bootstrap del cluster in modo che faccia riferimento al segreto.
    kubectl edit clusterbootstrap ccc-cluster -n custom-ns
  13. Aggiungere le righe seguenti sotto la riga guest-cluster-auth-service.tanzu.vmware.com.versione:.
    valuesFrom:
  secretRef: ccc-cluster-guest-cluster-auth-service-data-values
    Ad esempio: 
    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. Salvare ed uscire per applicare le modifiche del bootstrap del cluster.

Parte 5: configurazione della sicurezza del pod

Se si utilizza TKR 1.25 e versioni successive, configurare la sicurezza del pod per lo Spazio dei nomi vSphere denominato custom-ns. Vedere Configurazione di PSA per TKR 1.25 e versioni successive.

Se si utilizza TKR 1.24 e versioni precedenti, i pod nel cluster richiedono il binding al criterio di sicurezza del pod. Per applicare gli oggetti risorsa richiesti a livello di cluster, utilizzare il processo seguente.
  1. Raccogliere il kubeconfig del cluster TKG.
    kubectl -n custom-ns get secret ccc-cluster-kubeconfig -o jsonpath="{.data.value}" | base64 -d > ccc-cluster-kubeconfig
  2. Creare il file 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. Applicare il criterio di sicurezza del pod.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f psp.yaml
  4. Accedere al cluster 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. Elencare gli spazi dei nomi.
    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: sincronizzazione dei ruoli vSphere SSO con il cluster TKG personalizzato

Affinché gli sviluppatori possano gestire i carichi di lavoro del cluster, è necessario sincronizzare il RoleBinding per gli utenti di vCenter Single Sign-On integrati negli Spazi dei nomi vSphere dal cluster Supervisore al cluster TKG.

Questo processo richiede l'esportazione dell'elenco di RoleBinding esistente da Supervisore, la raccolta dei RoleBinding con il ruolo "Modifica" e la creazione del file sync-cluster-edit-rolebinding.yaml e quindi l'applicazione al cluster TKG tramite KUBECONFIG.
  1. Raccogliere i RoleBinding esistenti dal Supervisore.
    kubectl get rolebinding -n custom-ns  -o yaml
  2. Dall'elenco restituito di oggetti RoleBinding, identificare quelli con roleRef.name uguale a "modifica".
    Ad esempio: 
    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. Creare un file denominato sync-cluster-edit-rolebinding.yaml per aggiungere eventuali altri RoleBinding diversi da quelli [email protected] predefiniti. Ad esempio:
    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: Nel campo metadata.name, il ruolo utente vien preceduto da vmware-system-auth-sync- per tutti gli utenti. Le voci metadata.name e subjects.name richiederanno modifiche per tutti i ruoli non predefiniti.
  4. Applicare la configurazione sync-cluster-edit-rolebinding.yaml per sincronizzare i RoleBinding.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f sync-cluster-edit-rolebinding.yaml