L'API du Service Tanzu Kubernetes Grid fournit des valeurs par défaut intelligentes et un groupe d'options pour personnaliser les clusters Tanzu Kubernetes. Reportez-vous aux exemples pour provisionner des clusters de différents types avec différentes configurations et personnalisations pour répondre à vos besoins.

YAML minimal pour le provisionnement d'un cluster Tanzu Kubernetes

L'exemple suivant de YAML constitue la configuration minimale requise pour appeler le Service Tanzu Kubernetes Grid et provisionner un cluster Tanzu Kubernetes qui utilise tous les paramètres par défaut.

Les caractéristiques de l'exemple minimal de YAML sont les suivantes :
  • La version de Version de Tanzu Kubernetes, répertoriée comme v1.19, est résolue sur la distribution la plus récente correspondant à cette version mineure, par exemple v1.19.7+vmware.1-tkg.1.xxxxxx. Reportez-vous à la section Vérifier la compatibilité du cluster Tanzu Kubernetes pour la mise à jour.
  • La classe de machine virtuelle best-effort-<size> n'a aucune réservation. Pour plus d'informations, consultez Classes de machine virtuelle pour des clusters Tanzu Kubernetes.
  • Le cluster n'inclut pas de stockage persistant pour les conteneurs. Si nécessaire, il est défini dans spec.settings.storage. Reportez-vous à l'exemple de stockage ci-dessous.
  • Certaines charges de travail, telles que Helm, peuvent nécessiter spec.settings.storage.defaultClass. Reportez-vous à l'exemple de stockage ci-dessous.
  • La section spec.settings.network n'est pas spécifiée. Cela signifie que le cluster utilise les paramètres réseau par défaut suivants :
    • CNI par défaut : antrea
    • CIDR d'espace par défaut : 192.168.0.0/16
    • CIDR de services par défaut : 10.96.0.0/12
    • Domaine de service par défaut : cluster.local
    Note : La plage d'adresses IP par défaut pour les espaces est 192.168.0.0/16. Si ce sous-réseau est déjà utilisé, vous devez spécifier une plage CIDR différente. Reportez-vous aux exemples de réseaux personnalisés ci-dessous. 
apiVersion: run.tanzu.vmware.com/v1alpha1      #TKGS API endpoint
kind: TanzuKubernetesCluster                   #required parameter
metadata:
  name: tkgs-cluster-1                         #cluster name, user defined
  namespace: tgks-cluster-ns                   #vsphere namespace
spec:
  distribution:
    version: v1.20                             #Resolves to latest TKR 1.20
  topology:
    controlPlane:
      count: 1                                 #number of control plane nodes
      class: best-effort-medium                #vmclass for control plane nodes
      storageClass: vwt-storage-policy         #storageclass for control plane
    workers:
      count: 3                                 #number of worker nodes
      class: best-effort-medium                #vmclass for worker nodes
      storageClass: vwt-storage-policy         #storageclass for worker nodes

Cluster avec des disques séparés et paramètres de stockage

L'exemple de YAML suivant montre comment provisionner un cluster avec des disques et des paramètres de stockage distincts pour le plan de contrôle du cluster et les nœuds worker.

L'utilisation de la séparation des disques et des paramètres de stockage pour les données à taux de variation élevée permet de minimiser la capacité supplémentaire de lecture-écriture liée à l'utilisation de clones liés, parmi d'autres avantages. Il existe deux cas d'utilisation principaux :
  • Personnaliser les performances de stockage sur les nœuds du plan de contrôle de la base de données ETCD
  • Personnaliser la taille du disque pour les images de conteneur sur les nœuds worker

L'exemple présente les caractéristiques suivantes :

  • Les paramètres spec.topology.controlPlane.volumes spécifient le volume distinct de la base de données ETCD.
  • Les paramètres spec.topology.workers.volumes spécifient le volume distinct des images de conteneur.
  • Le chemin mountPath: /var/lib/containerd des images de conteneur est pris en charge pour Tanzu Kubernetes versions 1.17 et ultérieures.
apiVersion: run.tanzu.vmware.com/v1alpha1      
kind: TanzuKubernetesCluster                   
metadata:
  name: tkgs-cluster-5                         
  namespace: tgks-cluster-ns                   
spec:
  distribution:
    version: v1.20                            
  topology:
    controlPlane:
      count: 3                                 
      class: best-effort-medium                 
      storageClass: vwt-storage-policy
      volumes:
        - name: etcd
          mountPath: /var/lib/etcd
          capacity:
            storage: 4Gi       
    workers:
      count: 3                                 
      class: best-effort-medium                 
      storageClass: vwt-storage-policy        
      volumes:
        - name: containerd
          mountPath: /var/lib/containerd
          capacity:
            storage: 16Gi

Cluster avec un réseau Antrea personnalisé

Le YAML suivant montre comment provisionner un cluster Tanzu Kubernetes avec des plages réseau personnalisées pour le CNI Antrea.
  • Étant donné que des paramètres réseau personnalisés sont appliqués, le paramètre cni.name est requis, même si le CNI Antrea par défaut est utilisé.
    • Nom du CNI : antrea
    • CIDR des espaces personnalisés : 193.0.2.0/16
    • CIDR de services personnalisés : 195.51.100.0/12
    • Domaine de service personnalisé : managedcluster.local
  • Les blocs CIDR personnalisés spécifiés ne peuvent pas chevaucher le Cluster superviseur. Pour plus d'informations, consultez Paramètres de configuration des clusters Tanzu Kubernetes utilisant Service Tanzu Kubernetes Grid v1alpha1 API.
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: tkg-cluster-3-antrea
  namespace: tkgs-cluster-ns
spec:
  distribution:
    version: v1.20
  topology:
    controlPlane:
      class: guaranteed-medium
      count: 3
      storageClass: vwt-storage-policy
    workers:
      class: guaranteed-medium
      count: 5
      storageClass: vwt-storage-policy
  settings:
    network:
      cni:
        name: antrea                       #Use Antrea CNI
      pods:
        cidrBlocks:
        - 193.0.2.0/16                     #Must not overlap with SVC
      services:
        cidrBlocks:
        - 195.51.100.0/12                  #Must not overlap with SVC
      serviceDomain: managedcluster.local

Cluster avec un réseau calibré personnalisé

Le YAML suivant explique comment provisionner un cluster Tanzu Kubernetes avec un réseau Calico personnalisé. 
apiVersion: run.tanzu.vmware.com/v1alpha1    
kind: TanzuKubernetesCluster                 
metadata:
  name: tkgs-cluster-2                                
  namespace: tkgs-cluster-ns                     
spec:
  distribution:
    version: v1.20                              
  topology:
    controlPlane:
      count: 3                                                        
      class: guaranteed-large                  
      storageClass: vwt-storage-policy        
    workers:
      count: 5                                                      
      class: guaranteed-xlarge                           
      storageClass: vwt-storage-policy      
  settings:
    network:
      cni:
        name: calico                           #Use Calico CNI for this cluster
      services:
        cidrBlocks: ["198.51.100.0/12"]        #Must not overlap with SVC
      pods:
        cidrBlocks: ["192.0.2.0/16"]           #Must not overlap with SVC
      serviceDomain: managedcluster.local

Cluster avec classes de stockage et classe par défaut pour les volumes persistants

L'exemple de YAML suivant montre comment provisionner un cluster avec des classes de stockage pour le provisionnement dynamique de réclamation de volume persistant et une classe de stockage par défaut.
  • Le paramètre spec.settings.storage.classes spécifie deux classes de stockage pour le stockage persistant des conteneurs du cluster.
  • spec.settings.storage.defaultClass est spécifié. Certaines applications nécessitent une classe par défaut. Par exemple, si vous souhaitez utiliser Helm ou Kubeapps comme defaultClass, qui est référencé par de nombreux diagrammes.
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: default-storage-spec
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      count: 3
      class: best-effort-medium
      storageClass: vwt-storage-policy
    workers:
      count: 3
      class: best-effort-medium
      storageClass: vwt-storage-policy
  distribution:
    version: v1.20
  settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["198.51.100.0/12"]
      pods:
        cidrBlocks: ["192.0.2.0/16"]
      serviceDomain: "tanzukubernetescluster.local"
    storage:
      classes: ["gold", "silver"]              #Array of named PVC storage classes
      defaultClass: silver                     #Default PVC storage class

Cluster avec un serveur proxy

Vous pouvez utiliser un serveur proxy avec un cluster Tanzu Kubernetes individuel en appliquant la configuration du serveur proxy au manifeste du cluster.

Notez les caractéristiques suivantes :

  • La section spec.settings.network.proxy spécifie la configuration de proxy HTTP(s) pour ce cluster Tanzu Kubernetes.
  • La syntaxe des deux valeurs de serveur proxy est http://<user>:<pwd>@<ip>:<port>.
  • Les points de terminaison spécifiques ne sont pas automatiquement mis en proxy, notamment localhost et 127.0.0.1, ainsi que les CIDR d'espace et de service pour les clusters Tanzu Kubernetes. Vous n'avez pas besoin de les inclure dans le champ noProxy.
  • Le champ noProxy accepte un groupe de CIDR à ne pas mettre en proxy. Obtenez les valeurs requises à partir du réseau de charge de travail sur le Cluster superviseur. Reportez-vous à l'image dans la section Paramètres de configuration des clusters Tanzu Kubernetes utilisant Service Tanzu Kubernetes Grid v1alpha1 API.
  • Si un proxy global est configuré sur TkgServiceConfiguration, ces informations de proxy sont propagées au manifeste du cluster après le déploiement initial du cluster. La configuration du proxy global est ajoutée au manifeste du cluster uniquement si aucun champ de configuration de proxy n'est présent lors de la création du cluster. En d'autres termes, la configuration par cluster est prioritaire et la configuration du proxy global est prioritaire. 
apiVersion: run.tanzu.vmware.com/v1alpha1    
kind: TanzuKubernetesCluster                 
metadata:
  name: tkgs-cluster-with-proxy                                
  namespace: tkgs-cluster-ns                     
spec:
  distribution:
    version: v1.20                              
  topology:
    controlPlane:
      count: 3                                                        
      class: guaranteed-medium                  
      storageClass: vwt-storage-policy        
    workers:
      count: 5                                                      
      class: guaranteed-xlarge                           
      storageClass: vwt-storage-policy       
  settings:
    storage:
      classes: ["gold", "silver"]              
      defaultClass: silver                     
    network:
      cni:
        name: antrea 
      pods:
        cidrBlocks:
        - 193.0.2.0/16
      services:
        cidrBlocks:
        - 195.51.100.0/12           
      serviceDomain: managedcluster.local
      proxy:
        httpProxy: http://10.186.102.224:3128  #Proxy URL for HTTP connections
        httpsProxy: http://10.186.102.224:3128 #Proxy URL for HTTPS connections
        noProxy: [10.246.0.0/16,192.168.144.0/20,192.168.128.0/20] #SVC Pod, Egress, Ingress CIDRs

Cluster avec certificats personnalisés pour TLS

De la même manière que vous pouvez spécifier un trust.additionalTrustedCAs dans la spécification TkgServiceConfiguration (voir Paramètres de configuration de Service Tanzu Kubernetes Grid v1alpha1 API), vous pouvez inclure trust.additionalTrustedCAs sous le spec.settings.network dans la spécification TanzuKubernetesCluster. Par exemple : 
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-with-custom-certs-tls
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      count: 3
      class: guaranteed-medium
      storageClass: vwt-storage-profile
    workers:
      count: 3
      class: guaranteed-large
      storageClass: vwt-storage-profile
  distribution:
    version: 1.20.2
  settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["198.51.100.0/12"]
      pods:
        cidrBlocks: ["192.0.2.0/16"]
      serviceDomain: "managedcluster.local"
      trust:
        additionalTrustedCAs:
          - name: custom-selfsigned-cert-for-tkc
            data: |
              LS0aaaaaaaaaaaaaaabase64...

Cluster qui hérite ou non des paramètres globaux de la spécification TkgServiceConfiguration

Note : Les exemples de configurations de cluster suivants nécessitent vCenter Server version 7.0U2a ou ultérieure et un Cluster superviseur de version 1.18.10 ou ultérieure.
Pour provisionner un cluster Tanzu Kubernetes qui hérite d'un paramètre global de la spécification TkgServiceConfiguration, configurez le cluster avec le paramètre global non spécifié ou null.

Par exemple, si vous souhaitez configurer un cluster qui hériterait du paramètre de proxy, vous pouvez utiliser l'une des approches suivantes :

Option 1 : n'incluez pas le paramètre de proxy dans la spécification du cluster : 
...
settings:
  network:
    cni:
      name: antrea
    services:
      cidrBlocks: ["198.51.100.0/12"]
    pods:
      cidrBlocks: ["192.0.2.0/16"]
    serviceDomain: "tanzukubernetescluster.local"
Option 2 : incluez le paramètre de proxy dans la spécification, mais définissez explicitement sa valeur sur null : 
settings:
  network:
    proxy: null

Pour provisionner un cluster Tanzu Kubernetes qui n'hérite pas de la valeur par défaut de la spécification TkgServiceConfiguration, configurez la spécification du cluster avec tous les éléments inclus, mais avec des valeurs vides.

Par exemple, si la spécification TkgServiceConfiguration dispose d'un paramètre de proxy global configuré et que vous souhaitez provisionner un cluster qui n'hérite pas des paramètres de proxy globaux, incluez la syntaxe suivante dans votre spécification de cluster : 
...
settings:
  network:
    proxy:
      httpProxy: ""
      httpsProxy: ""
      noProxy: null

Cluster utilisant une bibliothèque de contenu locale

Pour provisionner un cluster Tanzu Kubernetes dans un environnement isolé, créez un cluster à l'aide de l'image de machine virtuelle synchronisée à partir d'une bibliothèque de contenu locale.

Pour provisionner un cluster à l'aide d'une image de bibliothèque de contenu locale, vous devez spécifier cette image dans la spécification du cluster. Pour la valeur distribution.version, vous pouvez entrer le nom complet de l'image ou, si vous avez conservé le format du nom du répertoire de l'image, vous pouvez le raccourcir pour la version Kubernetes. Si vous souhaitez utiliser un numéro de version complet, remplacez ----- par +. Par exemple, si vous avez une image OVA nommée photon-3-k8s-v1.20.2---vmware.1-tkg.1.1d4f79a, les formats suivants sont acceptables. 
spec:
  distribution:
    version: v1.20

spec:
  distribution:
    version: v1.20.2

spec:
  distribution:
    version: v1.20.2+vmware.1-tkg.1

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
    name: tgks-cluster-9
    namespace: tkgs-cluster-ns
spec:
   topology:
       controlPlane:
           count: 3
           class: best-effort-medium
           storageClass: vwt-storage-policy
       workers:
           count: 3
           class: best-effort-medium
           storageClass: vwt-storage-policy
   distribution:
        version: v1.20.2         
   settings:
        network:
          cni:
              name: antrea 
          services:
             cidrBlocks: ["198.51.100.0/12"]
          pods:
             cidrBlocks: ["192.0.2.0/16"]