Cette rubrique explique comment configurer un cluster de charge de travail avant de le déployer sur vSphere avec un cluster de gestion autonome. Pour configurer un cluster de charge de travail pour le déploiement sur vSphere with Tanzu, reportez-vous à la section Configuration du cluster pour vSphere avec superviseur. Pour obtenir des informations générales sur la configuration des clusters de charge de travail, reportez-vous à la section Configurer des clusters de charge de travail.
Pour configurer un cluster de charge de travail avant de le déployer sur vSphere, créez un fichier de configuration de cluster ou un fichier de spécification d'objet de style Kubernetes. 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. Par exemple, vous pouvez spécifier les tailles standard pour les machines virtuelles de nœud de plan de contrôle et worker ou configurer explicitement les tailles de CPU, de mémoire et de disque pour les nœuds de plan de contrôle et worker. Si vous utilisez des modèles d'image personnalisée, vous pouvez identifier le modèle à utiliser pour créer des machines virtuelles de nœud.
Pour obtenir la liste complète des options que vous devez spécifier lors du déploiement de clusters de charge de travail sur vSphere, reportez-vous à la Référence de variable de fichier de configuration.
Pour créer un fichier de configuration de cluster, vous pouvez utiliser le modèle dans la section Modèle de cluster de travail ci-dessous. Après avoir créé le fichier de configuration, passez à la section Créer des clusters de charge de travail.
Le modèle ci-dessous inclut toutes les options pertinentes pour le déploiement de clusters de charge de travail sur vSphere. Vous pouvez copier ce modèle et le mettre à jour pour déployer des clusters de charge de travail sur vSphere.
Les marques de commentaire sont supprimées pour les options obligatoires. Elles sont ajoutées pour les paramètres facultatifs. Les valeurs par défaut sont incluses le cas échéant.
À l'exception des options décrites dans les sections sous le modèle, la manière dont vous configurez les variables des clusters de charge de travail spécifiques à vSphere est identique pour les clusters de gestion et les clusters de charge de travail. Pour plus d'informations sur la configuration des variables, reportez-vous aux sections Déployer des clusters de gestion à partir d'un fichier de configuration et Configuration du cluster de gestion pour vSphere.
#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------
# CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
# CLUSTER_API_SERVER_PORT: # For deployments without NSX Advanced Load Balancer
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none
#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------
# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# VSPHERE_NUM_CPUS: 2
# VSPHERE_DISK_GIB: 40
# VSPHERE_MEM_MIB: 4096
# VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
# VSPHERE_CONTROL_PLANE_DISK_GIB: 40
# VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
# VSPHERE_WORKER_NUM_CPUS: 2
# VSPHERE_WORKER_DISK_GIB: 40
# VSPHERE_WORKER_MEM_MIB: 4096
# CONTROL_PLANE_MACHINE_COUNT:
# WORKER_MACHINE_COUNT:
# WORKER_MACHINE_COUNT_0:
# WORKER_MACHINE_COUNT_1:
# WORKER_MACHINE_COUNT_2:
#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------
#VSPHERE_CLONE_MODE: "fullClone"
VSPHERE_NETWORK: VM Network
# VSPHERE_TEMPLATE:
# VSPHERE_TEMPLATE_MOID:
# VSPHERE_WINDOWS_TEMPLATE: ""
# IS_WINDOWS_WORKLOAD_CLUSTER: false
# VIP_NETWORK_INTERFACE: "eth0"
VSPHERE_SSH_AUTHORIZED_KEY:
VSPHERE_USERNAME:
VSPHERE_PASSWORD:
# VSPHERE_REGION:
# VSPHERE_ZONE:
# VSPHERE_AZ_0:
# VSPHERE_AZ_1:
# VSPHERE_AZ_2:
VSPHERE_SERVER:
VSPHERE_DATACENTER:
VSPHERE_RESOURCE_POOL:
VSPHERE_DATASTORE:
VSPHERE_FOLDER:
# VSPHERE_STORAGE_POLICY_ID
# VSPHERE_WORKER_PCI_DEVICES:
# VSPHERE_CONTROL_PLANE_PCI_DEVICES:
# VSPHERE_IGNORE_PCI_DEVICES_ALLOW_LIST:
# VSPHERE_CONTROL_PLANE_CUSTOM_VMX_KEYS:
# VSPHERE_WORKER_CUSTOM_VMX_KEYS:
# WORKER_ROLLOUT_STRATEGY: "RollingUpdate"
# VSPHERE_CONTROL_PLANE_HARDWARE_VERSION:
# VSPHERE_WORKER_HARDWARE_VERSION:
VSPHERE_TLS_THUMBPRINT:
VSPHERE_INSECURE: false
# VSPHERE_CONTROL_PLANE_ENDPOINT: # Required for Kube-Vip
# VSPHERE_CONTROL_PLANE_ENDPOINT_PORT: 6443
# VSPHERE_ADDITIONAL_FQDN:
AVI_CONTROL_PLANE_HA_PROVIDER: false
#! ---------------------------------------------------------------------
#! NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------
# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"
#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------
ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------
# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: false
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""
# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""
# TKG_PROXY_CA_CERT: ""
ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------
ENABLE_AUTOSCALER: false
# AUTOSCALER_MAX_NODES_TOTAL: "0"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m"
# AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m"
# AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m"
# AUTOSCALER_MIN_SIZE_0:
# AUTOSCALER_MAX_SIZE_0:
# AUTOSCALER_MIN_SIZE_1:
# AUTOSCALER_MAX_SIZE_1:
# AUTOSCALER_MIN_SIZE_2:
# AUTOSCALER_MAX_SIZE_2:
#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------
# ANTREA_NO_SNAT: false
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_PROXY_ALL: false
# ANTREA_PROXY_NODEPORT_ADDRS: ""
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "30s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_KUBE_APISERVER_OVERRIDE:
# ANTREA_TRANSPORT_INTERFACE:
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_MULTICAST_IGMPQUERY_INTERVAL: "125s"
# ANTREA_TUNNEL_TYPE: geneve
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_ENABLE_BRIDGING_MODE: false
# ANTREA_DISABLE_TXCHECKSUM_OFFLOAD: false
# ANTREA_DNS_SERVER_OVERRIDE: ""
# ANTREA_MULTICLUSTER_ENABLE: false
# ANTREA_MULTICLUSTER_NAMESPACE: ""
Si vous déployez le cluster sur vSphere et que vous utilisez l'équilibrage de charge Kube-Vip par défaut pour l'API du plan de contrôle du cluster, vous devez spécifier son point de terminaison en définissant VSPHERE_CONTROL_PLANE_ENDPOINT. Si vous utilisez NSX Advanced Load Balancer (ALB), ne définissez pas VSPHERE_CONTROL_PLANE_ENDPOINT, sauf si vous avez besoin que le point de terminaison du plan de contrôle soit une adresse spécifique. Si c'est le cas, utilisez une adresse statique dans la plage réseau VIP du profil IPAM ALB de NSX que vous avez ajoutée manuellement au pool d'adresses IP statiques.
Deux clusters, y compris le cluster de gestion et le cluster de charge de travail, ne peuvent pas avoir la même adresse VSPHERE_CONTROL_PLANE_ENDPOINT.
Reportez-vous aux sections ci-dessous pour obtenir des exemples de configurations de cluster avancées sur vSphere :
Si vous utilisez une image OVA personnalisée unique pour chaque version de Kubernetes afin de déployer des clusters sur un système d'exploitation, importez le fichier OVA dans vSphere, puis spécifiez-le pour tanzu cluster create avec l'option --tkr.
Toutefois, si vous utilisez plusieurs images OVA personnalisées pour la même version de Kubernetes, la valeur --tkr est alors ambiguë. Cela se produit lorsque les fichiers OVA pour la même version de Kubernetes :
make build-node-ova-vsphere-ubuntu-1804, make build-node-ova-vsphere-photon-3 et make build-node-ova-vsphere-rhel-7.Pour résoudre cette ambiguïté définissez l'option VSPHERE_TEMPLATE sur l'image OVA souhaitée avant d'exécuter tanzu cluster create :
Si le nom de l'image du modèle OVA est unique, définissez VSPHERE_TEMPLATE uniquement sur le nom de l'image.
Si plusieurs images partagent le même nom, définissez VSPHERE_TEMPLATE sur le chemin d'inventaire complet de l'image dans vCenter. Ce chemin d'accès suit le format /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE, où :
MY-DC est le centre de données contenant l'image du modèle OVA.MY-FOLDER-PATH est le chemin d'accès à l'image à partir du centre de données, comme indiqué dans la vue VM et modèles (VMs and Templates) de vCenter.MY-IMAGE est le nom de l'image.Par exemple :
VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"
Vous pouvez déterminer manuellement le chemin d'accès complet à l'inventaire vCenter de l'image ou utiliser l'interface de ligne de commande govc :
govc. Pour obtenir des instructions d'installation, reportez-vous au référentiel govmomi sur GitHub.govc pour accéder à votre instance de vCenter :
export GOVC_USERNAME=VCENTER-USERNAMEexport GOVC_PASSWORD=VCENTER-PASSWORDexport GOVC_URL=VCENTER-URLexport GOVC_INSECURE=1govc find / -type m et recherchez le nom de l'image dans la sortie, qui répertorie les objets en fonction de leurs chemins d'inventaire complets.Pour plus d'informations sur les images OVA personnalisées, reportez-vous à la section Générer des images de machine.
Vous pouvez spécifier une région et une zone pour votre cluster de charge de travail afin de l'intégrer à des balises de région et de zone configurées pour vSphere CSI (Cloud Storage Interface). Pour les clusters qui couvrent plusieurs zones, cela permet aux nœuds worker de trouver et d'utiliser le stockage partagé, même s'ils s'exécutent dans des zones sans espace de stockage (par exemple, dans un réseau d'accès radio (RAN) de télécommunication).
Pour déployer un cluster de charge de travail avec des balises de région et de zone qui activent le stockage partagé avec vSphere CSI :
Créer des balises sur l'instance de vCenter Server :
k8s-region et k8s-zone.Suivez les étapes de la page Créer une balise pour créer des balises dans la région et les catégories de zones du centre de données, comme indiqué dans ce tableau :
| Catégorie | Balises |
|---|---|
k8s-zone |
zone-azone-bzone-c |
k8s-region |
region-1 |
Créez les balises correspondantes sur les clusters et le centre de données en suivant les étapes de la page Attribuer ou supprimer une balise comme indiqué dans le tableau.
| Objets vSphere | Balises |
datacenter |
region-1 |
cluster1 |
zone-a |
cluster2 |
zone-b |
cluster3 |
zone-c |
Pour activer des régions et des zones personnalisées pour le pilote CSI d'un cluster de charge de travail vSphere, définissez les variables VSPHERE_REGION et VSPHERE_ZONE dans le fichier de configuration du cluster sur les balises ci-dessus. Par exemple :
VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a
Lorsque la CLI Tanzu crée un cluster de charge de travail avec ces variables définies, elle désigne chaque nœud de cluster avec les clés de topologie failure-domain.beta.kubernetes.io/zone et failure-domain.beta.kubernetes.io/region.
Exécutez tanzu cluster create pour créer le cluster de charge de travail, comme décrit dans la section Déployer des clusters de charge de travail.
Après avoir créé le cluster, et avec le contexte kubectl défini sur le cluster, vous pouvez vérifier les étiquettes de région et de zone en effectuant l'une des opérations suivantes :
Exécutez kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region et vérifiez que la sortie répertorie les nœuds de cluster.
Exécutez kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}' et vérifiez que la région et la zone sont activées sur vsphere-csi.
Pour plus d'informations sur la configuration de vSphere CSI, reportez-vous à la section Pilote vSphere Pilote - Déploiement avec topologie.
Tanzu Kubernetes Grid peut exécuter des clusters de charge de travail sur plusieurs comptes de fournisseurs d'infrastructure. Par exemple, pour fractionner l'utilisation du cloud entre différentes équipes ou appliquer différents profils de sécurité aux charges de travail de production, de préparation et de développement.
Pour déployer des clusters de charge de travail sur un autre compte vSphere différent de celui utilisé pour déployer le cluster de gestion, procédez comme suit :
Définissez le contexte de kubectl sur votre cluster de gestion :
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
Où MY-MGMT-CLUSTER est le nom de votre cluster de gestion.
Créez un fichier secret.yaml avec le contenu suivant :
apiVersion: v1
kind: Secret
metadata:
name: SECRET-NAME
namespace: CAPV-MANAGER-NAMESPACE
stringData:
username: VSPHERE-USERNAME
password: VSPHERE-PASSWORD
Où :
SECRET-NAME est un nom que vous attribuez à la clé secrète client.CAPV-MANAGER-NAMESPACE est l'espace de noms dans lequel l'espace capv-manager est en cours d'exécution. Défaut : capv-system.VSPHERE-USERNAME et VSPHERE-PASSWORD sont des informations d'identification de connexion qui permettent d'accéder à l'autre compte vSphere.Utilisez le fichier pour créer l'objet Secret :
kubectl apply -f secret.yaml
Créez un fichier identity.yaml avec le contenu suivant :
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
name: EXAMPLE-IDENTITY
spec:
secretName: SECRET-NAME
allowedNamespaces:
selector:
matchLabels: {}
Où :
EXAMPLE-IDENTITY est le nom à utiliser pour l'objet VSphereClusterIdentity.SECRET-NAME est le nom que vous avez donné à la clé secrète client ci-dessus.Utilisez le fichier pour créer l'objet VsphereClusterIdentity :
kubectl apply -f identity.yaml
Le cluster de gestion peut désormais déployer des clusters de charge de travail sur l'autre compte. Pour déployer un cluster de charge de travail sur le compte :
Créez un manifeste de cluster en exécutant tanzu cluster create --dry-run.
Modifiez la définition VSphereCluster dans le manifeste pour définir la valeur spec.identityRef.name de son objet VSphereClusterIdentity sur le nom EXAMPLE-IDENTITY que vous avez créé ci-dessus :
...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
name: new-workload-cluster
spec:
identityRef:
kind: VSphereClusterIdentity
name: EXAMPLE-IDENTITY
...
Exécutez la commande kubectl apply -f my-cluster-manifest.yaml pour créer le cluster de charge de travail.
Après avoir créé le cluster de charge de travail, connectez-vous à vSphere avec les informations d'identification de l'autre compte. Vous devriez alors le voir en cours d'exécution.
Pour plus d'informations, reportez-vous à la section Gestion des identités dans le référentiel vSphere du Fournisseur d'API de cluster.
Pour permettre à un cluster de charge de travail d'utiliser un cluster de banques de données au lieu d'une banque de données unique, configurez une stratégie de stockage qui cible toutes les banques de données du cluster de banques de données comme suit :
Créez une balise et associez-la aux banques de données correspondantes :
Datastore est un type d'objet associable pour la catégorie.Suivez les étapes de la section Créer une stratégie de stockage de machines virtuelles pour le placement basé sur des balises pour créer une stratégie de stockage basée sur des balises.
Dans le fichier de configuration du cluster :
VSPHERE_STORAGE_POLICY_ID sur le nom de la stratégie de stockage créée à l'étape précédente.VSPHERE_DATASTORE n'est pas défini. Un paramètre VSPHERE_DATASTORE remplacerait le paramètre de la stratégie de stockage.Pour déployer un cluster de charge de travail avec des nœuds worker Windows, créez une image de machine personnalisée, déployez le cluster et convertissez-le en cluster de charge de travail hybride. L'utilisation d'un cluster de charge de travail hybride évite l'utilisation de nœuds Linux de plan de contrôle pour planifier des charges de travail réelles.
Ajoutez un paramètre OSImage dans le cluster de gestion qui pointe vers le modèle lorsque vous avez créé une image de machine Windows. Utilisez l'exemple de fichier YAML suivant pour ajouter le paramètre OSImage.
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
name: v1.24.9---vmware.1-tkg.1-windows
spec:
image:
ref:
template: /dc0/vm/windows-2019-kube-v1.24.9+vmware.1-tkg.1
version: v1.24.9+vmware.1-tkg.1-windows
type: ova
kubernetesVersion: v1.24.9+vmware.1
os:
arch: amd64
name: windows
type: windows
version: "2019"
Ajoutez la version de TKR à spec.osImages pour que la résolution TKR et la validation du Webhook se produisent correctement. Utilisez la commande suivante pour ajouter la version de TKR à spec.osImages.
$ kubectl get tkr v1.24.9---vmware.x-tkg.x -o yaml
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
name: v1.24.9---vmware.x-tkg.x
spec:
bootstrapPackages:
# Keep the other packages listed here.
- name: tkg-windows.tanzu.vmware.com.x.x.x-vmware.1
osImages:
# Keep the other images listed here.
- name: v1.24.9---vmware.1-tkg.1-windows
Sur la TKR, activez le module tkg-windows en ajoutant un nouvel élément dans spec.bootstrapPackages. Le module est disponible dans le référentiel officiel avec tanzu package available list tkg-windows.tanzu.vmware.com. Voici un exemple d'une TKR en fonctionnement :
Déployez le cluster Windows en suivant la procédure décrite dans l'une des sections ci-dessus ou en exécutant la commande suivante.
tanzu cluster create WINDOWS-CLUSTER --file CLUSTER-CONFIG.yaml -v 9
Où : * WINDOWS-CLUSTER est le nom du cluster Windows. * CLUSTER-CONFIG est le nom du fichier de configuration.
Convertissez-le en cluster de charge de travail hybride. Vous pouvez créer un cluster hybride à partir d'un cluster Windows existant. La ClusterClass créée à partir du module initial contient des définitions Windows et Linux workers.machineDeployments.
Rechercher l'objet Cluster. L'objet Cluster porte le même nom que le cluster de charge de travail créé dans l'espace de noms par défaut du cluster de gestion.
$ kubectl get cluster
Ajoutez la nouvelle classe de déploiement de machines tkg-worker à l'objet de cluster. Assurez-vous que l'annotation est correcte afin que TKG puisse rechercher l'objet OSImage.
Vous pouvez ajouter la nouvelle spécification à spec.workers.machineDeployments de manière semblable à l'exemple suivant :
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: WINDOWS-CLUSTER
spec:
workers:
machineDeployments:
- class: tkg-worker
metadata:
annotations:
run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
name: md-0-l
replicas: 1
- class: tkg-worker-windows
metadata:
annotations:
run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
name: md-0
replicas: 1
Les nœuds sont étiquetés et rejetés avec les informations du système d'exploitation dans Étiquettes, annotations et rejets connus.
RemarqueLa sauvegarde et la restauration des clusters de charge de travail Windows ne sont pas prises en charge.
Vous pouvez utiliser la CLI Tanzu pour convertir un fichier de configuration de cluster en fichier de spécification d'objet de style Kubernetes pour un cluster de charge de travail basé sur une classe sans déployer le cluster. Pour créer le fichier, transmettez l'option --dry-run à tanzu cluster create et enregistrez la sortie dans un fichier. Utilisez les mêmes options et le même --file de configuration que vous utiliseriez pour créer le cluster. Par exemple :
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
Passez à la section Créer des clusters de charge de travail. Après avoir déployé un cluster de charge de travail sur vSphere, vous devez configurer les adresses IP de son point de terminaison de plan de contrôle et de ses nœuds pour qu'elles soient statiques, comme décrit dans la section Configurer les réservations DHCP pour le point de terminaison de plan de contrôle et tous les nœuds (vSphere uniquement).
