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

 

Gérer les pools de nœuds de différents types de VM

Cette rubrique explique comment créer, mettre à jour et supprimer des pools de nœuds dans un cluster de charge de travail. Les pools de nœuds permettent à un cluster de charge de travail unique de contenir et de gérer différents types de nœuds, afin de prendre en charge les besoins de différentes applications.

Par exemple, un cluster peut utiliser des nœuds avec une capacité de stockage élevée pour exécuter une banque de données, et des nœuds plus fins pour traiter des demandes d'application.

Remarque

Vous ne pouvez pas créer de pools de nœuds dans des clusters à nœud unique.
Pour créer et utiliser des pools de nœuds dans des clusters de charge de travail créés par vSphere with Tanzu, vous devez exécuter vSphere v7.0 U3 ou version ultérieure.
Si vous utilisez vSphere with Tanzu, vos clusters vSphere with Tanzu doivent utiliser l'API v1alpha2 pour exécuter correctement les commandes node-pool. Pour plus d'informations, consultez la documentation de vSphere with Tanzu.

À propos des pools de nœuds

Les pools de nœuds définissent les propriétés des ensembles de nœuds worker utilisés par un cluster de charge de travail.

Certaines propriétés de pool de nœuds dépendent des options de machine virtuelle disponibles dans l'infrastructure sous-jacente, mais tous les pools de nœuds de toutes les infrastructures de cloud partagent les propriétés suivantes :

  • name : identifiant unique du pool de nœuds, utilisé pour les opérations telles que les mises à jour et la suppression.
  • replicas : nombre de nœuds dans le pool, qui partagent tous les mêmes propriétés.
  • labels : paires clé/valeur définies comme métadonnées sur les nœuds, pour faire correspondre les charges de travail aux nœuds du pool. Pour obtenir des informations supplémentaires et des exemples d'étiquettes, reportez-vous à la section Labels and Selectors de la documentation Kubernetes.

Pour les clusters de charge de travail sur vSphere, les clusters de gestion autonomes par défaut suivent les règles d'anti-affinité pour déployer les nœuds worker de pool de nœuds et les nœuds de plan de contrôle sur différents hôtes ESXi. Pour désactiver les règles d'anti-affinité pour le placement des nœuds, reportez-vous à la section Désactiver les règles d'anti-affinité.

Tous les clusters de charge de travail sont créés avec un premier pool de nœuds d'origine. Lorsque vous créez des pools de nœuds supplémentaires pour un cluster, comme décrit ci-dessous, le premier pool de nœuds fournit des valeurs par défaut pour les propriétés non définies dans les nouvelles définitions de pool de nœuds.

Répertorier les pools de nœuds

Pour inspecter les pools de nœuds actuellement disponibles dans un cluster, exécutez :

tanzu cluster node-pool list CLUSTER-NAME

La commande renvoie une liste de tous les pools de nœuds du cluster et l’état des réplicas dans chaque pool de nœuds.

Créer un pool de nœuds

Pour créer un pool de nœuds dans un cluster :

  1. Créez un fichier de configuration pour le pool de nœuds. Reportez-vous à la section Exemple de configuration pour obtenir un exemple de fichier de configuration.

    Pour obtenir la liste complète des propriétés de configuration, reportez-vous à la section Propriétés de configuration.

  2. Créez le pool de nœuds défini par le fichier de configuration :

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    Options :

    • --namespace spécifie l'espace de noms du cluster. La valeur par défaut est default.
    • (Clusters hérités (Legacy clusters)) --base-machine-deployment spécifie l'objet MachineDeployment de base à partir duquel créer le pool de nœuds.
      • Définissez cette valeur en tant qu'identifiant de MachineDeployment tel qu'il est répertorié dans la sortie de tanzu cluster get sous Details.
      • La valeur par défaut est la première des objets MachineDeployment du groupe de nœuds worker du cluster, représentés en interne comme workerMDs[0].

Exemple de configuration

Voici un exemple de configuration pour votre infrastructure sous-jacente.

Configuration vSphere
Outre les propriétés name, replicas et labels requises ci-dessus, les fichiers de configuration des pools de nœuds sur vSphere peuvent inclure un bloc vsphere, afin de définir des propriétés facultatives spécifiques à la configuration des machines virtuelles sur vSphere.

Exemple de définition de pool de nœuds pour un cluster vSphere :

    name: tkg-wc-oidc-md-1
    replicas: 4
    labels:
      key1: value1
      key2: value2
    vsphere:
      memoryMiB: 8192
      diskGiB: 64
      numCPUs: 4
      datacenter: dc0
      datastore: iscsi-ds-0
      storagePolicyName: name
      folder: vmFolder
      resourcePool: rp-1
      vcIP: 10.0.0.1
      template: templateName
      cloneMode: clone-mode
      network: network-name

Les valeurs non définies dans le bloc vsphere héritent des valeurs du premier pool de nœuds du cluster.

Pour la valeur vcIP, les pools de nœuds de cluster de charge de travail doivent s'exécuter dans le même vCenter que le plan de contrôle du cluster.

Pour les clusters déployés par un superviseur vSphere with Tanzu, définissez storageClass, tkr et vmClass. Pour obtenir plus d'informations sur ces propriétés, reportez-vous à la section API TanzuKubernetesCluster v1alpha3 - Annotée dans la documentation de vSphere with Tanzu.

Par défaut, les clusters de charge de travail sur vSphere sont déployés en suivant les règles d'anti-affinité qui répartissent les nœuds du plan de contrôle et les nœuds worker dans chaque pool de nœuds entre plusieurs hôtes ESXi. Pour désactiver ou réactiver les règles d'anti-affinité, reportez-vous à a section Désactiver les règles d'anti-affinité (vSphere) ci-dessous.

Configuration AWS
Outre les propriétés name, replicas et labels, les fichiers de configuration des pools de nœuds sur AWS prennent en charge les propriétés facultatives suivantes :
  • az : Zone de disponibilité
  • nodeMachineType : Type d'instance

Ces paramètres peuvent être omis, auquel cas leurs valeurs sont héritées du premier pool de nœuds du cluster.

Exemple de définition de pool de nœuds pour un cluster AWS :

name: tkg-aws-wc-np-1
replicas: 2
az: us-west-2b
nodeMachineType: t3.large
labels:
  key1: value1
  key2: value2
Remarque

Les pools de nœuds de cluster de charge de travail sur AWS doivent se trouver dans la même zone de disponibilité que le cluster de gestion autonome.

Configuration Azure
Outre les propriétés name, replicas et labels ci-dessus, les fichiers de configuration des pools de nœuds sur Microsoft Azure prennent en charge les propriétés facultatives suivantes :
  • az : Zone de disponibilité
  • nodeMachineType : Type d'instance

Si les paramètres sont omis, leurs valeurs héritent du premier pool de nœuds du cluster.

Exemple de définition de pool de nœuds pour le cluster Azure :

name: tkg-azure-wc-np-1
replicas: 2
az: 2
nodeMachineType: Standard_D2s_v3
labels:
  key1: value1
  key2: value2

Propriétés de configuration

Le tableau suivant répertorie toutes les propriétés que vous pouvez définir dans un fichier de configuration de pool de nœuds pour les clusters de charge de travail.

Remarque

Vous ne pouvez pas ajouter les propriétés labels, az, nodeMachineType ou les propriétés vSphere à un pool de nœuds existant ni les modifier. Pour modifier ces propriétés, vous devez créer un pool de nœuds dans le cluster avec les propriétés souhaitées, migrer les charges de travail vers le nouveau pool de nœuds et supprimer l'instance d'origine.

Nom Type Objet de cluster Fournisseur Remarques
name string Toutes Toutes Nom du pool de nœuds à créer ou à mettre à jour.
replicas entier Toutes Toutes Nombre de nœuds dans le pool de nœuds.
az string Toutes TKG sur AWS ou Azure Zone de disponibilité dans laquelle placer les nœuds.
nodeMachineType string Toutes TKG sur AWS ou Azure instanceType ou vmSize pour le nœud dans AWS et Azure, respectivement.
labels map[string]string Toutes Toutes Étiquettes à définir sur le nœud à l'aide de kubeletExtraArgs (‐‐node-labels).
vmClass string Toutes Toutes Nom d'une vmClass de Kubernetes. Correspond à la lvmClass définie dans le cluster TKC. Cette classe définit le CPU et la mémoire disponibles pour le nœud. Pour répertorier les classes de machine virtuelle disponibles, exécutez la commande kubectl describe virtualmachineclasses.
storageClass string Toutes Toutes Nom d'un kubernetes StorageClass à utiliser pour le pool de nœuds. Cette classe s'applique aux disques qui stockent les systèmes de fichiers racine des nœuds. Pour répertorier les classes de stockage disponibles, exécutez la commande kubectl describe storageclasses.
volumes :
  • name, chaîne
  • mountPath, chaîne
  • capacity, corev1.ResourceList
  • storageClass, chaîne
 []object Toutes Toutes Volumes à utiliser pour les nœuds.
tkr :
  • reference, chaîne
 objet basé sur TKC Toutes Nom du TKR à utiliser pour le pool de nœuds. Par exemple, v1.27.5---vmware.2-tkg.2.
tkrResolver string Basé sur une classe Toutes Requis pour les clusters basés sur une classe. Valeur de l'annotation run.tanzu.vmware.com/resolve-os-image de la ressource Cluster.
nodeDrainTimeout metav1.Duration Toutes Toutes Délai d'expiration de purge du nœud.
vsphere objet Toutes Toutes Reportez-vous à la section [Propriétés de configuration (vSphere uniquement)](#vsphere-properties).
workerClass string Basé sur une classe Toutes Requis pour les clusters basés sur une classe. Valeur workerClass provenant de l'objet ClusterClass du cluster que le pool de nœuds doit utiliser.

Propriétés de configuration (vSphere uniquement)

Pour plus d'informations sur les variables de configuration VSPHERE_*, reportez-vous à la section vSphere dans Référence de variable de fichier de configuration.

Nom Type Type de cluster de gestion Remarques
cloneMode string Autonome Identique à VSPHERE_CLONE_MODE.
datacenter string Autonome Identique à VSPHERE_DATACENTER.
datastore string Autonome Identique à VSPHERE_DATASTORE.
storagePolicyName string Autonome Identique à VSPHERE_STORAGE_POLICY_NAME.
taints []corev1.Taint Superviseur Rejets à appliquer au nœud.
folder string Autonome Identique à VSPHERE_FOLDER.
network string Autonome Identique à VSPHERE_NETWORK.
nameservers []string Autonome Identique à VSPHERE_WORKER_NAMESERVERS.
tkgIPFamily string Autonome Identique à TKG_IP_FAMILY.
resourcePool string Autonome Identique à VSPHERE_RESOURCE_POOL.
vcIP string Autonome Identique à VSPHERE_SERVER.
template string Autonome Identique à VSPHERE_TEMPLATE.
memoryMiB integer Autonome Identique à VSPHERE_WORKER_MEM_MIB.
diskGiB integer Autonome Identique à VSPHERE_WORKER_DISK_GIB.
numCPUs integer Autonome Identique à VSPHERE_WORKER_NUM_CPUS.

Attribuer des charges de travail à un pool de nœuds

Pour attribuer une charge de travail à un pool de nœuds :

  1. Dans la ou les ressources de charge de travail Kubernetes qui gèrent vos espaces, définissez nodeSelector sur la valeur de labels que vous avez définie dans votre fichier de configuration de pool de nœuds. Pour plus d'informations sur les ressources de charge de travail Kubernetes, reportez-vous à la section Charges de travail dans la documentation de Kubernetes.
  2. Appliquez votre configuration en exécutant la commande kubectl apply -f.

Pour réattribuer une charge de travail à un pool de nœuds différent :

  1. Dans la ou les ressources de charge de travail Kubernetes qui gèrent vos espaces, mettez à jour la valeur de nodeSelector vers la nouvelle valeur.
  2. Appliquez la mise à jour de votre configuration en exécutant la commande kubectl apply -f.

Mettre à jour les pools de nœuds

Si vous devez uniquement modifier le nombre de nœuds d'un pool de nœuds, utilisez la commande de CLI Tanzu de la section Mettre à l'échelle des nœuds uniquement. Si vous souhaitez ajouter des étiquettes, suivez la procédure décrite dans la section Ajouter des étiquettes et dimensionner des nœuds.

Attention :

Avec ces procédures, ne modifiez pas les étiquettes existantes, la zone de disponibilité, le type d’instance de nœud (sur AWS ou Azure) ou les propriétés de machine virtuelle (sur vSphere) du pool de nœuds. Cela peut avoir un impact grave sur les charges de travail en cours d'exécution. Pour modifier ces propriétés, créez un pool de nœuds avec ces propriétés et réattribuez les charges de travail au nouveau pool de nœuds avant de supprimer celui d'origine. Pour plus d'informations, reportez-vous à la section Attribuer des charges de travail à un pool de nœuds ci-dessus.

Mettre à l'échelle des nœuds uniquement

Pour modifier le nombre de nœuds dans un pool de nœuds, exécutez :

tanzu cluster scale CLUSTER-NAME -p NODE-POOL-NAME -w NODE-COUNT

Où :

  • CLUSTER-NAME est le nom du cluster de charge de travail.
  • NODE-POOL-NAME est le nom du pool de nœuds.
  • NODE-COUNT correspond au nombre de nœuds (nombre entier), qui appartiennent à ce pool de nœuds.

Ajouter des étiquettes et dimensionner des nœuds

Vous pouvez ajouter des étiquettes à un pool de nœuds et dimensionner ses nœuds en même temps au moyen du fichier de configuration du pool de nœuds.

  1. Ouvrez le fichier de configuration du pool de nœuds que vous souhaitez mettre à jour.

  2. Si vous augmentez ou diminuez le nombre de nœuds dans ce pool de nœuds, mettez à jour le nombre après replicas.

  3. Si vous ajoutez des étiquettes, mettez-les en retrait en dessous de labels. Par exemple :

    labels:
  key1: value1
  key2: value2

  4. Enregistrez le fichier de configuration du pool de nœuds.

  5. Dans un terminal, exécutez :

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    Si le CLUSTER-NAME dans la commande et name dans le fichier de configuration correspondent à un pool de nœuds du cluster, cette commande met à jour le pool de nœuds existant au lieu d'en créer un.

Supprimer des pools de nœuds

Pour supprimer un pool de nœuds, exécutez :

tanzu cluster node-pool delete CLUSTER-NAME -n NODE-POOL-NAME

Où CLUSTER-NAME est le nom du cluster de charge de travail et NODE-POOL-NAME est le nom du pool de nœuds.

Vous pouvez également utiliser --namespace pour spécifier l'espace de noms du cluster. La valeur par défaut est default.

Attention :

Réattribuez toutes les charges de travail sur ces nœuds à d'autres pools de nœuds avant d'effectuer cette opération. tanzu cluster node-pool delete ne migre pas les charges de travail des nœuds avant de les supprimer. Pour plus d'informations, reportez-vous à la section Attribuer des charges de travail à un pool de nœuds ci-dessus.

Désactiver les règles d'anti-affichage (vSphere)

Par défaut, les clusters de charge de travail sur vSphere sont déployés en suivant les règles d'anti-affinité qui répartissent les nœuds du plan de contrôle et les nœuds worker dans chaque pool de nœuds entre plusieurs hôtes ESXi. Procédez comme suit pour désactiver ou réactiver les règles d'anti-affinité lors de la création du cluster :

  1. Définissez le contexte kubectl sur le cluster de gestion :

    kubectl config use-context MGMT-CLUSTER-NAME-admin@MGMT-CLUSTER-NAME

    Où MGMT-CLUSTER-NAME est le nom du cluster.

  2. Exécutez kubectl get deployment sur le contrôleur CAPV pour collecter les valeurs args pour son conteneur manager, par exemple :

    kubectl get deployment -n capv-system capv-controller-manager -o=json | jq '.spec.template.spec.containers[] | select(.name=="manager") | .args'
[
  "--leader-elect",
  "--logtostderr",
  "--v=4",
  "--feature-gates=NodeAntiAffinity=true,NodeLabeling=true"
]

  3. Avec la sortie copiée à l'étape précédente, modifiez les valeurs --feature-gates et transmettez la liste d'arguments à une commande kubectl patch qui modifie leurs valeurs dans l'objet. Par exemple, pour définir les portails de fonctionnalité NodeAntiAffinity et NodeLabeling sur false, ce qui désactive les règles d'anti-affinité du nœud :

    kubectl patch deployment -n capv-system capv-controller-manager --type=json -p '[{"op":"replace", "path":"/spec/template/spec/containers/0/args", "value": [
"--leader-elect",
"--logtostderr",
"--v=4",
"--feature-gates=NodeAntiAffinity=false,NodeLabeling=false"
]}]'
check-circle-line exclamation-circle-line close-line
Scroll to top icon