Reportez-vous à ces instructions pour provisionner un cluster TKG basé sur une ClusterClass personnalisée. Notez que ces instructions sont spécifiques aux environnements vSphere 8 U1.

Conditions requises

La procédure de provisionnement d'un cluster TKG basé sur une ClusterClass personnalisée est disponible à partir de la version vSphere 8 U1. Si vous utilisez vSphere 8 U2, reportez-vous à la section Exemple v1beta1 : cluster basé sur une ClusterClass personnalisée (workflow vSphere 8 U2 et ultérieur).

Respectez les conditions préalables suivantes.
  • Environnement vSphere 8 U1
  • Gestion de la charge de travail activée
  • Superviseur configuré
  • Client Ubuntu avec Outils de l'interface de ligne de commande Kubernetes pour vSphere installé
Attention : La ClusterClass personnalisée est une fonctionnalité Kubernetes expérimentale, selon la documentation de l'API du cluster en amont. En raison de la plage de personnalisations disponible avec la ClusterClass personnalisée, VMware ne peut pas tester ou valider toutes les personnalisations possibles. Les clients sont responsables du test, de la validation et du dépannage de leurs clusters ClusterClass personnalisés. Les clients peuvent ouvrir des tickets de support concernant leurs clusters ClusterClass personnalisés. Toutefois, le support VMware se limite uniquement au principe du « meilleur effort » et ne peut pas garantir la résolution de chaque problème ouvert pour les clusters ClusterClass personnalisés. Les clients doivent tenir compte de ces risques avant de déployer des clusters ClusterClass personnalisés dans des environnements de production.

Partie 1 : Créer une ClusterClass personnalisée

La première partie implique la création d'une ClusterClass personnalisée en clonant la ClusterClass par défaut nommée tanzukubernetescluster.
  1. Créez un Espace de noms vSphere nommé custom-ns.
  2. Connectez-vous à Superviseur.
  3. Basculez le contexte sur l'Espace de noms vSphere nommé custom-ns.
  4. Obtenir la ClusterClass par défaut.
    kubectl get clusterclass tanzukubernetescluster -o json
  5. Créez une ClusterClass personnalisée nommée custom-cc en clonant la ClusterClass par défaut.
    kubectl get clusterclass tanzukubernetescluster -o json | jq '.metadata.name="custom-cc"' | kubectl apply -f -
    Résultat attendu : 
    clusterclass.cluster.x-k8s.io/custom-cc created
  6. Obtenez la ClusterClass personnalisée.
    kubectl get clusterclass custom-cc -o json

    Si nécessaire, vous pouvez utiliser l'affichage less pour afficher la ClusterClass personnalisée.

    kubectl get clusterclass custom-cc -o json | less
    Note : Exécutez la commande « q » pour quitter l'affichage less.

Étape 2 : Créer les objets Superviseur requis pour provisionner le cluster TKG

La partie suivante consiste à créer les objets Superviseur requis pour le déploiement initial d'un cluster TKG personnalisé à l'aide de la ClusterClass personnalisée.
Note : Nous utilisons le nom de cluster « ccc-cluster » par défaut. Si vous utilisez un nom de cluster différent, vous devrez modifier les champs appropriés.
  1. Créez l'émetteur du certificat d'extensions auto-signé.
    #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
    Résultat attendu : 
    issuer.cert-manager.io/self-signed-extensions-issuer created
  2. Créez le secret pour le certificat d'autorité de certification des extensions.
    #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
    Résultat attendu : 
    certificate.cert-manager.io/ccc-cluster-extensions-ca created
  3. Créez l'émetteur pour le certificat d'autorité de certification des extensions.
    #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
    Résultat attendu : 
    issuer.cert-manager.io/ccc-cluster-extensions-ca-issuer created
  4. Créez le secret pour le certificat du service d'authentification.
    #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
    Résultat attendu : 
    certificate.cert-manager.io/ccc-cluster-auth-svc-cert created
  5. Vérifiez la création des émetteurs et des certificats.
    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

Étape 3 : créer un cluster TKG basé sur la ClusterClass personnalisée

Utilisez l' API de cluster v1beta1 pour créer un cluster basé sur une ClusterClass. Un cluster v1beta1 basé sur une ClusterClass personnalisée nécessite l'ensemble minimal de variables suivant.
Variable Description
vmClass Reportez-vous à la section Utilisation de classes de machines virtuelles avec des clusters de Service TKG.
storageClass Reportez-vous à la section Configurer le stockage persistant pour l'Espace de noms vSphere.
ntp Serveur NTP utilisé pour activer le Superviseur.
extensionCert Généré automatiquement après la création du « certificat d'extension de l'autorité de certification » dans la section précédente.
clusterEncryptionConfigYaml la section ci-dessous décrit le processus d'obtention de ce fichier
  1. Créez le secret de chiffrement.
    #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
    Résultat attendu : 
    secret/ccc-cluster-encryption created
  2. Récupérez le serveur NTP à partir du Superviseur.
    kubectl -n vmware-system-vmop get configmap vmoperator-network-config -o jsonpath={.data.ntpservers}
  3. Construisez le manifeste cluster-with-ccc.yaml pour provisionner le 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==
    Dans le manifeste du cluster, vérifiez ou mettez à jour les champs suivants :
    Paramètre Description
    metadata.name Nom du cluster v1beta1.
    spec.topology.class Nom de la ClusterClass personnalisée.
    spec.topology.version Version de Version de Tanzu Kubernetes
    spec.topology.variables.storageClass.value Stratégie de stockage attachée à l'Espace de noms vSphere dans lequel le cluster sera provisionné
    spec.topology.variables.ntp.value Adresse du serveur NTP
    spec.topology.variables.extensionCert.value.contentSecret.name Vérifier
    spec.topology.variables.clusterEncryptionConfigYaml.value Remplissez la valeur data.key avec la valeur du secret ClusterEncryptionConfig.
  4. Créez le cluster en fonction de la ClusterClass personnalisée.
    kubectl apply -f cluster-with-ccc.yaml -n custom-ns
    Résultat attendu : 
    cluster.cluster.x-k8s.io/ccc-cluster created

    À l'aide de vSphere Client, vérifiez que le cluster est créé.

  5. Connectez-vous au 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

Partie 4 : Créer les objets de Superviseur requis pour gérer un cluster TKG

Une fois que le cluster avec CCC est appliqué, différents contrôleurs essaieront de le provisionner ; cependant, les ressources d'infrastructure sous-jacentes nécessitent toujours que des objets supplémentaires soient démarrés correctement.
Paramètre Valeur
Authentification Les valeurs d'authentification doivent être collectées et mises à jour dans un fichier nommé values.yaml
Codé en Base64 Le fichier values.yaml sera codé dans une chaîne base64
guest-cluster-auth-service-data-values.yaml Cette chaîne sera ajoutée au fichier guest-cluster-auth-service-data-values.yaml téléchargé à partir de CCC_config_yamls.tar.gz avant d'appliquer le fichier.
Secret GuestClusterAuthSvcDataValues Enfin, le fichier de démarrage du cluster invité doit être modifié pour référencer le secret GuestClusterAuthSvcDataValues récemment créé.
  1. Changez de contexte pour utiliser l'Espace de noms vSphere où le cluster est provisionné.
    kubectl config use-context custom-ns
  2. Obtenez la valeur authServicePublicKeys.
    kubectl -n vmware-system-capw get configmap vc-public-keys -o jsonpath="{.data.vsphere\.local\.json}"
    Copiez le résultat dans un fichier texte nommé values.yaml. 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
  3. Obtenez l'UID du cluster pour mettre à jour authServicePublicKeys.
    kubectl get cluster -n custom-ns ccc-cluster -o yaml | grep uid
  4. Dans la section authServicePublicKeys du fichier values.yaml, ajoutez l'UID du cluster à la valeur « client_id ».

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

    Par exemple : 
    vmware-tes:vc:vns:k8s:7d95b50b-4fd4-4642-82a3-5dbfe87f499c
  5. Obtenez la valeur de certificat (remplacez ccc-cluster par le nom de cluster choisi).
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.crt}" | base64 -d
  6. Ajoutez le certificat au fichier values.yaml.

    Ajoutez le contenu du certificat sous la section authServicePublicKeys.

    Note : Le certificat doit comporter 4 espaces en retrait pour éviter un échec.
    Par exemple : 
    authServicePublicKeys: '{"issuer_url":"https://...SShrDw=="]}]}}'
ceritificate: |
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIQMibGSjeuJelQoPxCof/+xzANBgkqhkiG9w0BAQsFADAg
    ...
    sESk/RDTB1UAvi8PD3zcbEKZuRxuo4IAJqFFbAabwULhjUo0UwT+dIJo1gLf5/ep
    VoIRJS7j6VT98WbKyZp5B4I=
    -----END CERTIFICATE-----
  7. Obtenez la valeur privateKey.
    kubectl -n custom-ns get secret ccc-cluster-auth-svc-cert -o jsonpath="{.data.tls\.key}"
  8. Vérifiez votre fichier 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. Hachez le fichier values.yaml en utilisant le codage Base64 pour collecter la sortie du fichier guest-cluster-auth-service-data-values.yaml.
    base64 -i values.yaml -w 0
  10. Créez le fichier guest-cluster-auth-service-data-values.yaml.
    Voici un modèle pour le secret. 
    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
    Reportez-vous au tableau suivant pour remplir les valeurs secrètes attendues.
    Paramètre Valeur
    data.values.yaml

    Chaîne codée en Base64 de values.yaml
    metadata.labels.cluster-name

    Nom du cluster, tel que ccc-cluster
    metadata.labels.package-name

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

    Pour obtenir cette valeur, exécutez la commande kubectl get tkr v1.26.5---vmware.2-fips.1-tkg.1 -o yaml

    Modifier la version de TKR en fonction de la version que vous utilisez
    metadata.name

    Nom du cluster, tel que ccc-cluster
  11. Créez le secret guest-cluster-auth-service-data-values.yaml.
    kubectl apply -f guest-cluster-auth-service-data-values.yaml -n custom-ns
  12. Modifiez le fichier de démarrage du cluster pour référencer le secret.
    kubectl edit clusterbootstrap ccc-cluster -n custom-ns
  13. Ajoutez les lignes suivantes sous la ligne guest-cluster-auth-service.tanzu.vmware.com.version :.
    valuesFrom:
  secretRef: ccc-cluster-guest-cluster-auth-service-data-values
    Par exemple : 
    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. Enregistrez et quittez pour appliquer les modifications de clusterbootstrap.

Partie 5 : Configurer la sécurité de l'espace

Si vous utilisez TKR versions 1.25 et ultérieures, configurez la sécurité de l'espace pour l'Espace de noms vSphere nommé custom-ns. Reportez-vous à la section Configurer PSA pour TKR 1.25 et versions ultérieures.

Si vous utilisez TKR versions 1.24 et antérieures, les espaces du cluster nécessitent une liaison à la stratégie de sécurité de l'espace. Pour appliquer les objets de ressources requis au niveau du cluster, utilisez le processus suivant.
  1. Obtenez le fichier kubeconfig du cluster TKG.
    kubectl -n custom-ns get secret ccc-cluster-kubeconfig -o jsonpath="{.data.value}" | base64 -d > ccc-cluster-kubeconfig
  2. Créez le fichier 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. Appliquer la stratégie de sécurité de l'espace.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f psp.yaml
  4. Connectez-vous au 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. Répertoriez les espaces de noms.
    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

Partie 6 : synchroniser les rôles SSO vSphere avec le cluster TKG personnalisé

La liaison RoleBinding pour les utilisateurs vCenter Single Sign-On créés dans l'Espaces de noms vSphere doit être synchronisée entre le Superviseur et le cluster TKG pour que les développeurs puissent gérer les charges de travail du cluster.

Ce processus nécessite l'exportation de la liste de liaisons RoleBinding existante à partir du Superviseur, la collecte des liaisons RoleBinding disposant du rôle « modifier » et la création du fichier sync-cluster-edit-rolebinding.yaml, puis l'application au cluster TKG à l'aide de son fichier kubeconfig.
  1. Collectez les liaisons RoleBinding existantes à partir du Superviseur.
    kubectl get rolebinding -n custom-ns  -o yaml
  2. Dans la liste d'objets RoleBindings renvoyée, identifiez ceux dont le roleRef.name est égal à « edit ».
    Par exemple : 
    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. Créez un fichier nommé sync-cluster-edit-rolebinding.yaml pour ajouter toutes les liaisons RoleBinding supplémentaires autres que la valeur par défaut [email protected]. Par exemple :
    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]
    Note : Dans le champ metadata.name, le rôle d'utilisateur est précédé de vmware-system-auth-sync- pour tous les utilisateurs. Les entrées metadata.name et subjects.name devront être modifiées pour tous les rôles autres que les rôles par défaut.
  4. Appliquez la configuration sync-cluster-edit-rolebinding.yaml pour synchroniser les liaisons RoleBindings.
    KUBECONFIG=ccc-cluster-kubeconfig kubectl apply -f sync-cluster-edit-rolebinding.yaml