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.
RemarquePour 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 commandesnode-pool
. Pour plus d'informations, consultez la documentation de vSphere with Tanzu.
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.
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.
Pour créer un pool de nœuds dans un cluster :
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.
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
.--base-machine-deployment
spécifie l'objet MachineDeployment
de base à partir duquel créer le pool de nœuds.
MachineDeployment
tel qu'il est répertorié dans la sortie de tanzu cluster get
sous Details
.MachineDeployment
du groupe de nœuds worker du cluster, représentés en interne comme workerMDs[0]
.Voici un exemple de configuration pour votre infrastructure sous-jacente.
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.
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'instanceCes 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
RemarqueLes 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.
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'instanceSi 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
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.
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 :
|
[]object | Toutes | Toutes | Volumes à utiliser pour les nœuds. |
tkr :
|
objet | basé sur TKC | Toutes | Nom du TKR à utiliser pour le pool de nœuds. Par exemple, v1.24.10—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). |
workerClass |
string | Basé sur une classe | Toutes | Requis pour les clusters basés sur une classe. workerClass provenant de la ClusterClass que vous souhaitez que le pool de nœuds utilise. |
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 . |
Pour attribuer une charge de travail à un pool de nœuds :
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.kubectl apply -f
.Pour réattribuer une charge de travail à un pool de nœuds différent :
nodeSelector
vers la nouvelle valeur.kubectl apply -f
.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.
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.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.
Ouvrez le fichier de configuration du pool de nœuds que vous souhaitez mettre à jour.
Si vous augmentez ou diminuez le nombre de nœuds dans ce pool de nœuds, mettez à jour le nombre après replicas
.
Si vous ajoutez des étiquettes, mettez-les en retrait en dessous de labels
. Par exemple :
labels:
key1: value1
key2: value2
Enregistrez le fichier de configuration du pool de nœuds.
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.
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.
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 :
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.
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"
]
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"
]}]'