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.
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.
Pour configurer un cluster de charge de travail pour le déploiement sur vSphere 8 with Tanzu :
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.
(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.
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
dans le référentiel de structure Tanzu : cluster_types.go.
json:
indique si le champ est facultatif. Les champs facultatifs ont le paramètre omitempty
.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.class
du 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
.
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
:
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,
|
|
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
Remarquesi 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
etNO_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.
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).