Clusters sur vSphere

Les sections suivantes décrivent comment configurer des clusters de charge de travail Tanzu Kubernetes Grid (TKG) pour utiliser des fonctionnalités spécifiques à vSphere avec un cluster de gestion autonome. Les fonctionnalités ne sont pas entièrement configurables dans le fichier de configuration plat du cluster ou dans la spécification d'objet de style Kubernetes.

Pour plus d'informations sur la configuration des clusters de charge de travail sur vSphere à l'aide de fichiers de configuration et de spécifications d'objet, reportez-vous aux sections suivantes :

Déployer un cluster avec une image OVA personnalisée

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 :

Ont différents systèmes d'exploitation, créés par exemple par make build-node-ova-vsphere-ubuntu-1804, make build-node-ova-vsphere-photon-3 et make build-node-ova-vsphere-rhel-7.
Portent le même nom, mais résident dans des dossiers vCenter différents.

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 :
1. Installez govc. Pour obtenir des instructions d'installation, reportez-vous au référentiel govmomi sur GitHub.
2. Définissez des variables d'environnement pour govc pour accéder à votre instance de vCenter :
  - export GOVC_USERNAME=VCENTER-USERNAME
  - export GOVC_PASSWORD=VCENTER-PASSWORD
  - export GOVC_URL=VCENTER-URL
  - export GOVC_INSECURE=1
3. Exécutez govc 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.

Déployer un cluster avec des balises de région et de zone pour CSI

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 :
1. Créez des catégories de balises sur vCenter Server conformément à la page Créer et modifier une catégorie de balises. Par exemple, k8s-region et k8s-zone.
2. Suivez les étapes de la page Créer et modifier une balise vSphere 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-a
  zone-b
  zone-c
  
  k8s-region region-1

Catégorie	Balises
`k8s-zone`	`zone-a` `zone-b` `zone-c`
`k8s-region`	`region-1`

Créez les balises correspondant aux clusters et au centre de données en suivant les étapes de la section Attribuer ou supprimer une balise vSphere, 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 Créer un cluster basé sur un plan ou TKC.
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.

Clusters sur différents comptes vSphere

Tanzu Kubernetes Grid peut exécuter des clusters de charge de travail sur plusieurs comptes de plate-forme cible. 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.

Déployer un cluster qui utilise un cluster de banques de données

Remarque
Cette fonctionnalité ne fonctionne pas comme prévu si vous balisez plusieurs banques de données dans un cluster de banques de données comme base de la stratégie de stockage d'un cluster de charge de travail, ce cluster n'utilise qu'une seule des banques de données.

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 :
1. Suivez les procédures décrites dans la section Balises vSphere pour créer des catégories de balises sur vCenter Server. Assurez-vous que Datastore est un type d'objet associable pour la catégorie.
2. Suivez les autres procédures de Balises vSphere pour créer une balise dans la catégorie créée à l'étape précédente et pour associer la nouvelle balise à toutes les banques de données appartenant au cluster de banques de données.
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 :
- Définissez VSPHERE_STORAGE_POLICY_ID sur le nom de la stratégie de stockage créée à l'étape précédente.
- Assurez-vous que VSPHERE_DATASTORE n'est pas défini. Un paramètre VSPHERE_DATASTORE remplacerait le paramètre de la stratégie de stockage.

Déployer un cluster de charge de travail dans un environnement avec plusieurs systèmes d'exploitation

Pour déployer un cluster de charge de travail dans un environnement avec plusieurs systèmes d'exploitation et des nœuds worker Windows et Linux, créez une image de machine Windows personnalisée, déployez un cluster de charge de travail Windows, puis ajoutez un MachineDeployment Linux pour convertir le cluster de charge de travail Windows uniquement en cluster avec plusieurs systèmes d'exploitation.

Les clusters avec plusieurs systèmes d'exploitation peuvent héberger des charges de travail Windows et Linux, tout en exécutant des composants TKG Linux sur les nœuds worker auxquels ils appartiennent.

Créez une image de machine Windows en suivant toutes les procédures décrites dans Images de machine personnalisées Windows.
Créez un fichier YAML, par exemple, win-osimage.yaml pour ajouter une image OSImage dans le cluster de gestion qui pointe vers le modèle généré lorsque vous avez créé une image de machine Windows.

Vous pouvez utiliser l’exemple de fichier YAML suivant. Remplacez la valeur spec.image.ref.template par l'emplacement du modèle Windows que vous avez créé. Le chemin d'accès est spécifique à votre environnement vSphere.
```
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
 name: v1.25.7---vmware.2-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.25.7+vmware.2-tkg.1
     version: v1.25.7+vmware.2-tkg.1-windows
   type: ova
 kubernetesVersion: v1.25.7+vmware.2
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"
```
Exécutez kubectl apply -f win-osimage.yaml pour ajouter l'image OSImage.
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 edit tkr v1.25.7---vmware.2-tkg.1
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
  name: v1.25.7---vmware.2-tkg.1
spec:
  bootstrapPackages:
  # Keep the other packages listed here.
  - name: tkg-windows.tanzu.vmware.com.0.29.0+vmware.1
  osImages:
  # Keep the other images listed here.
  - name: v1.25.7---vmware.2-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 :
Créez une spécification d'objet de cluster basée sur une classe en exécutant la commande suivante :
```
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
```
Où : * WINDOWS-CLUSTER est le nom du cluster Windows. * CLUSTER-CONFIG est le nom du fichier de configuration.

Ajoutez la nouvelle classe de déploiement de machines tkg-worker à l'objet de cluster dans my-cluster-spec.yaml. Assurez-vous que l'annotation est correcte afin que TKG puisse rechercher l'objet OSImage.

Vous pouvez ajouter la nouvelle spécification tkg-worker à spec.workers.machineDeployments comme dans 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

Déployez le cluster avec plusieurs systèmes d'exploitation en exécutant la commande suivante :

tanzu cluster create my-cluster -f my-cluster-spec.yaml

Les nœuds sont étiquetés et rejetés avec les informations du système d'exploitation dans Étiquettes, annotations et rejets connus.

Remarque
La sauvegarde et la restauration des clusters de charge de travail avec plusieurs systèmes d'exploitation ne sont pas prises en charge.

Fiabilité de la CNI Antrea Windows

Le réseau HNS n'est pas persistant sur Windows. Après le redémarrage du nœud Windows, le réseau HNS créé par antrea-agent est supprimé et l'extension Open vSwitch est désactivée par défaut. Par conséquent, après le redémarrage du nœud Windows, supprimez le pont et les ports OVS obsolètes. Vous pouvez utiliser le script d'aide Clean-AntreaNetwork.ps1 pour nettoyer le pont OVS.

Utilisez l’une des méthodes suivantes pour installer le script d’aide :

Installation manuelle
Installation automatisée

Installation manuelle

Pour installer manuellement le script d’aide sur chaque nœud de charge de travail isolé :

Téléchargez le script d'installation Clean-AntreaNetwork.ps1 à partir de cet exemple de code. Le script d'installation téléchargé snippet.ps1 installe Clean-AntreaNetwork.ps1.
Connectez-vous via SSH au nœud et exécutez la commande suivante.
```
powershell snippet.ps1
```

Installation automatisée

Pour créer un objet ClusterClass personnalisé qui installe automatiquement le script d'aide sur chaque nouveau nœud de charge de travail :

Suivez les étapes décrites dans la section Créer une ClusterClass pour créer votre objet ClusterClass personnalisé.
Appliquez le correctif à partir de cet exemple de code à l'aide de l'outil ytt, puis appliquez la spécification sur votre cluster de gestion :
```
ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -
```

Remarques sur la sécurité des groupes de ports distribués

Si vous déployez des clusters Windows ou de plusieurs systèmes d'exploitation, vous devez vous assurer que certaines stratégies de sécurité des groupes de ports distribués sont définies sur Reject. Par exemple, si le mode promiscuité est défini sur Accept, les nœuds peuvent alterner entre les états Ready et NotReady.

Dans vSphere Client, sélectionnez le réseau que vous utilisez pour les nœuds Windows, accédez aux paramètres Commutateur virtuel distribué (Virtual Distributed Switch) > Stratégie de sécurité de groupes de ports distribués (Distributed Portgroup Security Policy) et définissez ces stratégies sur Reject:

Mode promiscuité
Modifications d'adresse MAC
Transmissions forgées