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 :

  1. 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
  2. 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
  3. 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.

  4. 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.

  5. 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 :

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

    kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
    

    MY-MGMT-CLUSTER est le nom de votre cluster de gestion.

  2. 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.
  3. Utilisez le fichier pour créer l'objet Secret :

    kubectl apply -f secret.yaml
    
  4. 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.
  5. 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 :

  1. Créez un manifeste de cluster en exécutant tanzu cluster create --dry-run.

  2. 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
    ...
    
  3. 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 :

  1. 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.
  2. 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.

  3. 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.

  1. Créez une image de machine Windows en suivant toutes les procédures décrites dans Images de machine personnalisées Windows.
  2. 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.26.8---vmware.2-tkg.1-windows
    spec:
     image:
       ref:
         template: /dc0/vm/windows-2019-kube-v1.26.8
         version: v1.26.8+vmware.2-tkg.1-windows
       type: ova
     kubernetesVersion: v1.26.8+vmware.2
     os:
       arch: amd64
       name: windows
       type: windows
       version: "2019"
    
  3. Exécutez kubectl apply -f win-osimage.yaml pour ajouter l'image OSImage.

  4. Ajoutez la nouvelle OSImage et le module tkg-windows à la TKr que vous souhaitez utiliser pour votre cluster MultiOS afin que la résolution de la TKr et la validation du Webhook se produisent et que les composants Windows puissent être installés.

    Utilisez la commande suivante pour modifier la TKr afin d'ajouter OSImage comme nouvel élément dans les spec.osImages et d'ajouter le module tkg-windows comme nouvel élément dans les spec.bootstrapPackages.

    $ kubectl edit tkr v1.26.8---vmware.2-tkg.1
    

    Le module tkg-windows est disponible dans le référentiel officiel avec la liste tanzu package available list tkg-windows.tanzu.vmware.com. Voici un exemple de TKr fonctionnelle :

    apiVersion: run.tanzu.vmware.com/v1alpha3
    kind: TanzuKubernetesRelease
    metadata:
     name: v1.26.8---vmware.2-tkg.1
    spec:
     bootstrapPackages:
     # Add the tkg-windows package to this list AND keep the other packages already listed here under bootstrapPackages.
     - name: tkg-windows.tanzu.vmware.com.0.30.2+vmware.1
     osImages:
     # Add the Windows OSImage name to this list AND keep the other images already listed here under osImages.
     - name: v1.26.8---vmware.2-tkg.1-windows
    
    Remarque

    Cette modification de la TKr ne sera pas remplacée par le gestionnaire de contrôleur TKr, même si celui-ci rapproche continuellement les TKr du référentiel TKG avec votre référentiel interne, son rapprochement n'entraîne pas de modifications, mais uniquement la création de TKr manquantes

  5. Vérifiez que votre fichier de configuration de cluster MultiOS dispose des paramètres suivants :

    IS_WINDOWS_WORKLOAD_CLUSTER: "true"
    
  6. 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.
  7. 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
    
  8. 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.

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
check-circle-line exclamation-circle-line close-line
Scroll to top icon