This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Clusters de charge de travail

Cette rubrique décrit les différents types de clusters de charge de travail créés par Tanzu Kubernetes Grid (TKG) et la manière dont ils sont configurés et créés.

Types de cluster de charge de travail : basés sur une classe, TKC et basés sur un plan

Tanzu Kubernetes Grid héberge trois types différents de clusters de charge de travail :

  • Clusters basés sur une classe
    • Ces clusters sont des objets Kubernetes de type Cluster.
    • Ils constituent un nouveau type de cluster ajouté dans vSphere with Tanzu 8 et TKG 2.x
    • Ils disposent d'une topologie de base définie dans un bloc spec.topology.
      • Par exemple, nombre et type de nœuds worker et de plan de contrôle
    • Ils héritent la configuration de la valeur spec.topology.class.
      • Cela fait référence à un objet ClusterClass.
      • Sur le superviseur, la class par défaut est tanzukubernetescluster.
      • Sur un cluster de gestion autonome, la valeur par défaut class est tkg-INFRASTRUCTURE-default-VERSION, par exemple, tkg-vsphere-default-v1.0.0.
    • Ils peuvent être créés à l'aide du superviseur dans vSphere with Tanzu 8 ou à l'aide d'un cluster de gestion TKG v2.x autonome sur vSphere 6.7, 7 et 8 sans superviseur, sur AWS ou sur Azure
  • Clusters basés sur TKC (hérités)
    • Ces clusters sont des objets Kubernetes de type TanzuKubernetesCluster.
    • Ils peuvent être créés à l'aide d'un cluster superviseur sur vSphere 7 ou par le superviseur sur vSphere 8 à des fins héritées
  • Clusters basés sur un plan (hérités)
    • Ces clusters sont des objets Kubernetes de type Cluster.
    • Ils peuvent être créés à l'aide d'un cluster de gestion TKG v2.x ou v1.x autonome sur vSphere 6.7, 7 et 8 sans superviseur, sur AWS ou sur Azure

Notez que les clusters basés sur une classe avec class: tanzukubernetescluster, tous en minuscules, sont différents des clusters basés sur TKC, qui ont le type d'objet TanzuKubernetesCluster.

Les clusters basés sur une classe sont conçus pour remplacer les deux autres types de clusters, en présentant la même API aux deux types de cluster de gestion : Superviseurs et clusters de gestion autonomes.

Important

Tanzu Kubernetes Grid v2.4.x est la dernière version de TKG qui prend en charge la création de clusters de charge de travail TKG sur AWS et Azure. La possibilité de créer des clusters de charge de travail TKG sur AWS et Azure sera supprimée dans la version v2.5 de Tanzu Kubernetes Grid. Pour plus d'informations, reportez-vous à la section Obsolescence des clusters de gestion et de charge de travail TKG sur AWS et Azure des Notes de mise à jour de VMware Tanzu Kubernetes Grid v2.4.

Types de cluster et API de cluster

Pour créer et gérer des clusters de charge de travail, les clusters de gestion exécutent le logiciel d'API de cluster :

  • API de cluster : logiciel Kubernetes open source pour la création et la gestion de clusters Kubernetes.
  • Logiciel de fournisseur d'API de cluster qui s'exécute sur des infrastructures cloud ou physiques spécifiques en tant qu'interface pour prendre en charge l'API de cluster.
    • La plupart des projets des logiciels de fournisseur d'API de cluster sont open source, mais certains sont propriétaires.

Le tableau suivant mappe les types de clusters de gestion et de charge de travail aux fournisseurs d'API de cluster qu'ils utilisent :

TKG avec… utilise le fournisseur d'API de cluster… sur… pour créer et gérer des clusters de charge de travail de type… dans les versions de produit…
Superviseur CAPW (propriétaire) vSphere Objets Cluster basés sur une classe TKG 2.x et vSphere with Tanzu 8
Objets TanzuKubernetesCluster vSphere with Tanzu 7 et 8
Cluster de gestion autonome CAPA (OSS) AWS Objets Cluster basés sur une classe TKG v2.x
Objets AWSCluster basés sur un plan TKG v2.x et v1.x
CAPZ (OSS) Azure Objets Cluster basés sur une classe TKG v2.x
Objets AzureCluster basés sur un plan TKG v2.x et v1.x
CAPV (OSS) vSphere Objets Cluster basés sur une classe TKG v2.x
Objets VSphereCluster basés sur un plan TKG v2.x et v1.x

Types de clusters et compatibilité avec la CLI Tanzu

Les différentes versions de la CLI Tanzu fournies avec différentes versions de Tanzu Kubernetes Grid permettent de créer différents types de clusters selon que vous utilisez le superviseur sur vSphere 8, un cluster superviseur sur vSphere 7 ou un cluster de gestion autonome sur vSphere 6.7, 7 et 8 sans superviseur, sur AWS, ou sur Azure.

Version de CLI Version de TKG Créer des clusters basés sur une classe avec… Créer des clusters basés sur un plan avec… Créer TanzuKubernetesClusters avec…
Cluster de gestion autonome Superviseur sur vSphere 8 Cluster superviseur sur vSphere 7 Cluster de gestion autonome Superviseur sur vSphere 8 Cluster superviseur sur vSphere 7 Cluster de gestion autonome Superviseur sur vSphere 8 Cluster superviseur sur vSphere 7
v0.90.1* 2.3.0 ✓ ✓ x ✓ ✓ x x ✓ x
v0.29.0 2.2.0 ✓ ✓ x ✓ ✓ x x ✓ x
v0.28.1 2.1.1 ✓ ✓ x ✓ ✓ x x ✓ x
v0.25.4 1.6.1 x ✓ x ✓ ✓ x x ✓ ✓
v0.25.0 1.6.0 x ✓ x ✓ ✓ x x ✓ ✓
v0.11.x 1.5.x x x x ✓ x x x x ✓

* Pour obtenir la liste des versions de CLI compatibles avec Tanzu Kubernetes Grid v2.4, reportez-vous à la Matrice d'interopérabilité des produits.

Sous-composants d’objet de cluster de charge de travail

Les clusters basés sur une classe présentent la hiérarchie de haut niveau suivante des types d'objets. Les objets sous-jacents KubeAdmControlPlane et MachineDeployment ont les mêmes types, mais sont généralement des objets différents :

  • Cluster : nombre et type de nœuds de plan de contrôle et worker définis par le bloc topology dans la spécification
    • KubeAdmControlPlane : définit les nœuds de plan de contrôle (control plane)
      • Objet de machine spécifique à IaaS : par exemple, vSphereMachine, AWSMachine ou DockerMachine
      • Machine : objet générique pour la machine virtuelle de nœud
      • KubeAdmConfig : configuration de Kubernetes, notamment la version de Kubernetes, le référentiel d'images, les hooks antérieurs et postérieurs au déploiement, etc.
    • MachineDeployment : définit les nœuds worker
      • Objet de machine spécifique à IaaS
      • Machine
      • KubeAdmConfig

Pour plus d'informations, reportez-vous à la page CustomResourceDefinitions relationships du site The Cluster API Book.

Méthodes de création de clusters de charge de travail

En fonction de votre environnement installé, vous pouvez créer des clusters de charge de travail Tanzu Kubernetes Grid de plusieurs manières : avec la CLI Tanzu, Tanzu Mission Control et kubectl.

Le diagramme suivant décrit comment les utilisateurs peuvent créer différents types de clusters de charge de travail sur différentes infrastructures :

Utilisation du… pour créer un… récupère les valeurs de configuration à partir de… et les modèles de configuration à partir de… Instructions
CLI Tanzu :
tanzu cluster create		 Cluster de charge de travail basé sur une classe (vSphere) Cluster et spécifications d'objets sous-jacents Utilisateur (par exemple, classycluster.yaml) Créer un cluster basé sur une classe
TanzuKubernetesCluster, cluster de charge de travail (vSphere) Fichier de configuration de cluster,
environnement local, superpositions
(avancé) ytt		 infrastructure-tkg-service-vsphere* (Hérité) Créer un cluster basé sur un plan ou un cluster TKC
Cluster de charge de travail basé sur le plan (vSphere, AWS, Azure) infrastructure-vsphere,
infrastructure-aws,
infrastructure-azure*
Tanzu Mission Control (TMC) TanzuKubernetesCluster ou cluster de charge de travail basé sur un plan Interface utilisateur TMC Cluster de gestion enregistré Provisionnement de clusters de charge de travail
kubectl apply Clusters de charge de travail basés sur une classe ou TanzuKubernetesCluster (vSphere) Cluster et spécifications d'objets sous-jacents Utilisateur (par exemple, classycluster.yaml, tkc.yaml) Création de clusters de charge de travail de manière déclarative

*Répertoires locaux sous .config/tanzu/tkg/providers/

À propos du TKC hérité et de la configuration du cluster basée sur un plan

Lorsque la CLI Tanzu crée un cluster de charge de travail basé sur TKC, elle combine les valeurs de configuration des éléments suivants :

  • Entrée en direct lors de l’appel
    • Entrée de l'interface de ligne de commande
  • Variables d'environnement
  • ~/.config/tanzu/tkg/cluster-config.yaml ou un autre fichier transmis à l'option --file de l'interface de ligne de commande
  • Fichiers de configuration YAML de plan de cluster dans ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere, comme décrit dans la section Fichiers de configuration de plan ci-dessous.
  • Autres fichiers de configuration YAML non basés sur un plan sous ~/.config/tanzu/tkg/providers

L'entrée en direct applique des valeurs de configuration qui sont uniques à chaque appel. Les variables d'environnement les transmettent sur une session de terminal, et les fichiers de configuration et les superpositions les appliquent indéfiniment. Vous pouvez personnaliser les clusters à l'aide de l'une de ces sources, avec des recommandations et des mises en garde décrites ci-dessous.

Reportez-vous à la section Priorité des valeurs de configuration pour savoir comment la CLI tanzu dérive des valeurs de configuration de cluster spécifiques à partir de ces sources multiples où elles peuvent être en conflit.

Fichiers de configuration du plan

Le répertoire ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere contient des fichiers de configuration du plan de cluster de charge de travail TKC nommés cluster-template-definition-PLAN.yaml. Les valeurs de configuration de chaque plan proviennent de ces fichiers et des fichiers qu'ils répertorient sous spec.paths :

  • Fichiers de configuration fournis avec la CLI tanzu
  • Fichiers personnalisés que les utilisateurs créent et ajoutent à la liste spec.paths
  • Superpositions ytt que les utilisateurs créent ou modifient pour remplacer les valeurs dans d'autres fichiers de configuration

Fichiers à modifier et fichiers à ne pas modifier

Pour personnaliser des plans de cluster via YAML, modifiez les fichiers sous ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere. Vous devez cependant éviter de modifier d'autres fichiers.

Fichiers à modifier

Les chemins d'accès au fichier de configuration du plan de cluster de charge de travail suivent le format ~/.config/tanzu/tkg/providers/infrastructure-infrastructure-tkg-service-vsphere/VERSION/cluster-template-definition-PLAN.yaml, où :

  • VERSION est la version du module de fournisseur d'API de cluster que la configuration utilise.
  • PLAN est dev, prod ou un plan personnalisé.

Chaque fichier de configuration de plan comporte une section spec.paths qui répertorie les fichiers sources et les répertoires ytt qui configurent le plan de cluster. Par exemple :

apiVersion: providers.tanzu.vmware.com/v1alpha1
kind: TemplateDefinition
spec:
  paths:
    - path: providers/infrastructure-tkg-service-vsphere/v1.1.0/ytt
    - path: providers/ytt
    - path: bom
      filemark: text-plain
    - path: providers/config_default.yaml

Ces fichiers sont traités dans l’ordre indiqué. Si le même champ de configuration est défini dans plusieurs fichiers, le dernier paramètre traité est celui que la CLI tanzu utilise.

Pour personnaliser la configuration de votre cluster, vous pouvez :

  • Créer de nouveaux fichiers de configuration et les ajouter à la liste spec.paths.
    • Il s'agit de la méthode la plus facile.
  • Modifiez les fichiers de superposition ytt existants.
    • Il s'agit de la méthode la plus puissante, pour les personnes qui sont à l'aise avec ytt.

Fichiers à ne pas modifier

VMware déconseille de modifier les fichiers suivants sous ~/.config/tanzu/tkg/providers, à l'exception des instructions suivantes :

  • Fichiers base-template.yaml, dans les répertoires ytt

    • Ces fichiers de configuration utilisent les valeurs du fournisseur d'API du cluster sous Kubernetes SIGs et d'autres projets open source en amont, et il est préférable de les conserver tels quels.
    • Créez plutôt de nouveaux fichiers de configuration ou reportez-vous à la section Clusters et plans de cluster dans Configuration TKC avancée avec ytt pour définir des valeurs dans le fichier overlay.yaml du même répertoire ytt.

  • ~/.config/tanzu/tkg/providers/config_default.yaml - Ajouter uniquement

    • Ce fichier contient les valeurs par défaut à l'échelle du système pour Tanzu Kubernetes Grid.
    • Ne modifiez pas les valeurs existantes dans ce fichier. Vous pouvez cependant ajouter une section User Customizations à la fin.
    • Au lieu de modifier des valeurs dans ce fichier, personnalisez les configurations de cluster dans les fichiers que vous transmettez à l'option --file de tanzu cluster create.

  • ~/.config/tanzu/tkg/providers/config.yaml

    • La CLI tanzu utilise ce fichier comme référence pour tous les fournisseurs présents dans le répertoire /providers et leurs versions par défaut.

Priorité de la valeur de configuration

Lorsque la CLI Tanzu crée un cluster de charge de travail basé sur TKC, elle combine des valeurs de configuration provenant de sources multiples. Si ces sources sont en conflit, elle résout les conflits dans l'ordre de priorité décroissant suivant :

Traitement des couches, classé par priorité décroissante Source Exemples
1. Variables de configuration de cluster définies dans votre environnement local Définies dans le shell. export WORKER_VM_CLASS=best-effort-large
2. Variables de configuration de cluster définies dans la CLI Tanzu, avec tanzu config set env. Définies dans le shell ; enregistrées dans le fichier de configuration de la CLI Tanzu, ~/.config/tanzu/config.yaml. tanzu config set env.WORKER_VM_CLASS best-effort-large
3. Variables de configuration de cluster définies dans le fichier de configuration du cluster Définies dans le fichier transmis à l'option --file de tanzu cluster create. Le fichier est défini par défaut sur ~/.config/tanzu/tkg/cluster-config.yaml. WORKER_VM_CLASS: best-effort-large
4. Valeurs de configuration par défaut d'usine Définies dans providers/config_default.yaml, mais certains champs sont répertoriés sans valeurs par défaut. Ne modifiez pas ce fichier. WORKER_VM_CLASS:
check-circle-line exclamation-circle-line close-line
Scroll to top icon