Fichiers de configuration de vSphere avec un cluster superviseur

Cette rubrique explique comment utiliser un fichier de configuration plat ou une spécification d'objet de style Kubernetes pour configurer un cluster de charge de travail Tanzu Kubernetes Grid (TKG) avant de le déployer sur vSphere 8 avec Tanzu. Pour configurer un cluster de charge de travail pour le déploiement sur vSphere avec un cluster de gestion autonome, reportez-vous à la section Fichiers de configuration de vSphere avec un cluster de gestion autonome.

Pour obtenir des informations générales sur la configuration des clusters de charge de travail à l'aide de fichiers de configuration et de spécifications d'objets, reportez-vous à la section Fichiers de configuration et spécifications d'objet.

Pour utiliser les fonctionnalités de cluster de charge de travail spécifiques à vSphere qui nécessitent une configuration en dehors du fichier de configuration ou de la spécification d'objet du cluster, reportez-vous à la section Clusters sur vSphere.

Présentation

Pour configurer un cluster de charge de travail avant de le déployer sur vSphere with Tanzu, créez un fichier de spécification d'objet de style Kubernetes si vous configurez un cluster basé sur une classe, ou un fichier de configuration de cluster si vous configurez un cluster TKC. Lorsque vous transmettez l'un de ces fichiers à l'option -f de tanzu cluster create, la CLI Tanzu utilise les informations de configuration définies dans le fichier pour vous connecter à votre compte vSphere et créer les ressources que le cluster utilisera.

Pour configurer :

Pour plus d'informations sur les types de cluster ci-dessus, reportez-vous à la section Types de clusters de charge de travail.

Configurer un cluster basé sur une classe déployé par un superviseur

Pour configurer un cluster de charge de travail pour le déploiement sur vSphere 8 with Tanzu :

  1. Créez ou adaptez une spécification d'objet Cluster. La documentation de vSphere 8 contient des exemples de spécifications d'objets Cluster à utiliser :

    Définissez les types de machines virtuelles, l'échelle et d'autres configurations de cluster de base dans le bloc topology du fichier de spécification. Pour plus d'informations sur le bloc topology, reportez-vous aux sections Objet de cluster basé sur une classe et structure de topologie et Variables de topologie ClusterClass ci-dessous.

  2. (Facultatif) Pour personnaliser les attributs qui ne peuvent pas être définis dans l'objet Cluster lui-même, par exemple les paramètres d'interface de conteneur à usage unique dans l'infrastructure du cluster, reportez-vous à la section Configurer les paramètres de l'infrastructure à usage unique.

Objet de cluster basé sur une classe et structure de topologie

Les paramètres de niveau supérieur configurables dans un objet Cluster de type tanzukubernetescluster sont les suivants. Reportez-vous à la section Variables de topologie de cluster pour connaître les variables que vous pouvez configurer :

spec:
  clusterNetwork
    apiServerPort
    services
      cidrBlocks
    pods
      cidrBlocks
    serviceDomain
  controlPlaneEndpoint
    host
    port
  topology
    class
    version
    rolloutAfter
    controlPlane
      metadata
      replicas
      nodeDrainTimeout
      nodeDeletionTimeout
      machineHealthCheck
        maxUnhealthy
        nodeStartupTimeout
        unhealthyConditions
    workers
      machineDeployments
        metadata
        - class
        name
        failureDomain
        replicas
        nodeDrainTimeout
        nodeDeletionTimeout
        machineHealthCheck
          maxUnhealthy
          nodeStartupTimeout
          unhealthyConditions
        variables
          name
          value
  variables
    name
    value

Ces champs sont définis dans la spécification de type d'objet Cluster : cluster_types.go.

  • Champs facultatifs : Pour chaque champ, le paramètre json: indique si le champ est facultatif. Les champs facultatifs ont le paramètre omitempty.
  • Les structures imbriqués par référence dans la spécification de type sont mises en retrait dans la spécification d'objet YAML. Par exemple, la structure Topology contient *Workers dans la spécification de type, de sorte que workers est mis en retrait sous topology dans la spécification d'objets.

La classe - class et les options variables sont définies dans la classe de cluster de l'objet Cluster qui est définie comme valeur spec.topology.classdu cluster. Par exemple, dans vSphere with Tanzu, il s'agit d'un objet ClusterClass nommé tanzukubernetescluster, qui est différent d'un objet TanzuKubernetesCluster, comme expliqué dans la section Types de cluster de charge de travail.

Les variables configurables incluent vmClass, storageClass, proxy, nodeLabels, extensionCert et beaucoup d'autres, comme indiqué dans la section Variables de topologie ClusterClass ci-dessous. Ces variables configurent et remplacent les paramètres dans les objets qui sous-tendent l'objet de cluster tels que les objets KubeAdmConfig et Machine.

Variables de topologie ClusterClass

La classe de cluster tanzukubernetescluster, par défaut ClusterClass pour les clusters de charge de travail TKG sur vSphere with Tanzu, prend en charge les variables suivantes définies dans topology.variables et topology.workers.machineDeployments.variables. Les paramètres variables spécifiques aux déploiements de machines, tels que les pools de nœuds, remplacent les paramètres globaux.

Ces variables configurent et remplacent les paramètres des objets qui sous-tendent l'objet de cluster tels que les paramètres vmClass, storageClass et proxy définis dans les objets KubeAdmConfig et Machine. Cela permet aux utilisateurs de configurer un cluster entièrement dans la spécification d'objet de Cluster sans avoir à modifier les spécifications d'objets de niveau inférieur :

  • clusterEncryptionConfigYaml
  • controlPlaneVolumes
  • defaultRegistrySecret
  • defaultStorageClass
  • extensionCert
  • nodePoolLabels
  • nodePoolTaints
  • nodePoolVolumes
  • ntp
  • proxy
  • storageClass
  • storageClasses
  • TKR_DATA
  • trust
  • user
  • vmClass

Les rubriques suivantes de la documentation de vSphere 8 décrivent la reconfiguration d'un cluster en cours d'exécution en modifiant ses paramètres storageClass et vmClass :

Configurer un cluster TKC déployé par le superviseur (hérité)

Pour créer un fichier de configuration de cluster pour un cluster de charge de travail TKC (hérité) sur vSphere 8, vous pouvez copier un fichier de configuration existant d'un déploiement précédent dans vSphere with Tanzu et le mettre à jour. Vous pouvez également créer un tout nouveau fichier en utilisant un modèle vide.

Pour configurer un cluster de charge de travail déployé par un superviseur vSphere with Tanzu, définissez des variables pour définir les classes de stockage, les classes de machine virtuelle, le domaine de service, l'espace de noms et d'autres valeurs requises avec lesquelles créer votre cluster. Le tableau suivant répertorie les variables que vous pouvez inclure dans le fichier de configuration d’un cluster basé sur TKC. Vous pouvez également les définir comme variables d’environnement local.

Variables requises
Variable Type de valeur ou exemple Description
INFRASTRUCTURE_PROVIDER tkg-service-vsphere Toujours tkg-service-vsphere pour les objets TanzuKubernetesCluster sur vSphere with Tanzu.
CLUSTER_PLAN dev, prod ou un plan personnalisé Définit le nombre de nœuds.
CLUSTER_CIDR Plage CIDR Plage CIDR à utiliser pour les espaces. La plage recommandée est 100.96.0.0/11. Modifiez cette valeur uniquement si la plage recommandée n’est pas disponible.
SERVICE_CIDR Plage CIDR à utiliser pour les services Kubernetes. La plage recommandée est 100.64.0.0/13. Modifiez cette valeur uniquement si la plage recommandée n’est pas disponible.
SERVICE_DOMAIN Domaine Par exemple, my.example.com ou cluster.local s'il n'y a pas de DNS. Si vous prévoyez d'attribuer des noms de domaine complets avec les nœuds, la recherche DNS est requise.
CONTROL_PLANE_VM_CLASS Classe de machine virtuelle standard pour vSphere with Tanzu, par exemple guaranteed-large.
Reportez-vous à la section Utilisation de classes de machine virtuelle avec des clusters TKG sur le superviseur dans la documentation vSphere with Tanzu.
Classe de machine virtuelle pour les nœuds de plan de contrôle
WORKER_VM_CLASS Classe de machine virtuelle pour les nœuds worker
Variables facultatives
Variable Type de valeur ou exemple Description
CLUSTER_NAME String Remplacé par l'argument CLUSTER-NAME transmis à tanzu cluster create.
Ce nom doit respecter les conditions requises en matière de nom d'hôte DNS, comme indiqué dans RFC 952 et modifié dans RFC 1123, et doit comporter 42 caractères ou moins. Note: vous devez fournir un nom unique pour tous les clusters de charge de travail dans tous les espaces de noms. Si vous spécifiez un nom de cluster qui est utilisé dans un autre espace de noms, le déploiement du cluster échoue avec une erreur.
NAMESPACE Espace de noms, défini par défaut sur default. Espace de noms dans lequel déployer le cluster. Pour rechercher l'espace de noms du superviseur, exécutez kubectl get namespaces.
CNI antrea ou calico, défini par défaut sur antrea Interface de mise en réseau de conteneur pour les charges de travail hébergées, Antrea ou Calico.
CONTROL_PLANE_MACHINE_COUNT Entier ; CONTROL_PLANE_MACHINE_COUNT doit être un nombre impair.
Les valeurs par défaut sont 1 pour dev et 3 pour prod, comme défini par CLUSTER_PLAN.
Déployez un cluster de charge de travail avec plus de nœuds de plan de contrôle que la valeur par défaut du plan dev ou prod.
WORKER_MACHINE_COUNT Déployez un cluster de charge de travail avec plus de nœuds worker que la valeur par défaut du plan dev ou prod.
STORAGE_CLASSES Une chaîne vide ““ permet aux clusters d'utiliser n'importe quelle classe de stockage dans l'espace de noms, ou une liste de chaînes de valeurs séparées par des virgules de kubectl get storageclasses (par exemple, “SC-1,SC-2,SC-3”). Classes de stockage disponibles pour la personnalisation du nœud.
DEFAULT_STORAGE_CLASS Chaîne vide ”” pour aucune valeur par défaut ou une valeur de l'interface de ligne de commande comme ci-dessus. Classe de stockage par défaut pour le plan de contrôle ou les travailleurs.
CONTROL_PLANE_STORAGE_CLASS Valeur renvoyée par kubectl get storageclasses Classe de stockage par défaut pour les nœuds de plan de contrôle.
WORKER_STORAGE_CLASS Classe de stockage par défaut pour les nœuds worker.
NODE_POOL_0_NAME String Nom, étiquettes et rejets du pool de nœuds. Un TanzuKubernetesCluster ne peut avoir qu'un seul pool de nœuds.
NODE_POOL_0_LABELS Liste JSON de chaînes, par exemple, [“label1”, “label2”]["label1", "label2"]
NODE_POOL_0_TAINTS Liste JSON de chaînes de paires clé-valeur, par exemple [{“key1”: “value1”}, {“key2”: “value2”}]

Vous pouvez définir les variables ci-dessus en effectuant l’une des opérations suivantes :

  • Incluez-les dans le fichier de configuration du cluster transmis à l'option de CLI Tanzu --file. Par exemple :

    CONTROL_PLANE_VM_CLASS: guaranteed-large
    
  • À partir de la ligne de commande, définissez-les comme variables d'environnement local en exécutant export (sous Linux et macOS) ou SET (sous Windows) sur la ligne de commande. Par exemple :

    export CONTROL_PLANE_VM_CLASS=guaranteed-large
    
    Remarque

    si vous souhaitez configurer des paramètres de proxy uniques pour un cluster de charge de travail, vous pouvez définir TKG_HTTP_PROXY, TKG_HTTPS_PROXY et NO_PROXY comme variables d'environnement, puis utiliser la CLI Tanzu pour créer le cluster. Ces variables sont prioritaires sur votre configuration de proxy existante dans vSphere with Tanzu.

Tâches suivantes

Passez à la section Créer des clusters de charge de travail. Lorsque vous déployez un cluster de charge de travail sur vSphere, vous devez configurer ses réservations DHCP de nœuds et son DNS de point de terminaison, comme décrit dans la section Configurer les réservations DHCP de nœuds et l'enregistrement DNS du point de terminaison (vSphere uniquement).

check-circle-line exclamation-circle-line close-line
Scroll to top icon