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 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.
Clusters basés sur TKC (hérités)
- Ces clusters sont des objets Kubernetes de type TanzuKubernetesCluster.
Clusters basés sur un plan (hérités)
- Ces clusters sont des objets Kubernetes de type Cluster.

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.

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 l'infrastructure…	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.0/vSphere 8 with Tanzu
Superviseur	CAPW (propriétaire)	vSphere	Objets `TanzuKubernetesCluster`	vSphere 6.7, 7 et 8 with Tanzu
cluster de gestion autonome	CAPA (OSS)	AWS	Objets `Cluster` basés sur une classe	(à venir)
	CAPA (OSS)	AWS	Objets `AWSCluster` basés sur un plan	TKG v1.6 et versions antérieures
	CAPZ (OSS)	Azure	Objets `Cluster` basés sur une classe	(à venir)
	CAPZ (OSS)	Azure	Objets `AzureCluster` basés sur un plan	TKG v1.6 et versions antérieures
	CAPV (OSS)	vSphere	Objets `Cluster` basés sur une classe	(à venir)
	CAPV (OSS)	vSphere	Objets `VSphereCluster` basés sur un plan	TKG v1.6 et versions antérieures

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 l'interface de ligne de commande 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 de…	et modèles de configuration à partir de…	Instructions
Interface de ligne de commande 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 l'interface de ligne de commande 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 l'interface de ligne de commande Tanzu, avec `tanzu config set env.`	Définies dans le shell ; enregistrées dans le fichier de configuration de la CLI Tanzu global, `_{/.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:`