Conditions préalables au déploiement de NSX Application Platform

Pour installer correctement NSX Application Platform et activer les fonctionnalités de NSX qu'il héberge, vous devez préparer l'environnement de déploiement afin qu'il réponde aux ressources minimales requises.

Vous devez remplir les conditions préalables répertoriées dans les sections suivantes avant de commencer à déployer NSX Application Platform.

Version requise de NSX

Vérifiez que la version du produit NSX que vous utilisez est compatible avec la version de NSX Application Platform que vous prévoyez de déployer, ainsi que ses fonctionnalités NSX associées (NSX Intelligence, NSX Network Detection and Response, Protection contre les programmes malveillants NSX et Mesures NSX).

Le contrôle des versions des fonctionnalités NSX qui sont hébergées sur NSX Application Platform correspond au numéro de version de NSX Application Platform et non au numéro de version du produit NSX.

Important :

Dans un environnement NSX fédération, vous pouvez déployer NSX Application Platform sur des Gestionnaire local uniquement. Vous ne pouvez pas déployer NSX Application Platform à l'aide de Gestionnaire global. Vous pouvez accéder à NSX Application Platform uniquement à l'aide d'un Gestionnaire local.

Pour déterminer quelle version de NSX Application Platform vous pouvez déployer avec quelle version de NSX, utilisez la matrice de compatibilité suivante.

Version de NSX	Version de NSX Application Platform compatible
3.2.x	3.2.0, 3.2.1, 4.0.1
4.0.0.1	3.2.1, 4.0.1
4.0.1	4.0.1

Utilisez les informations suivantes pour déterminer la documentation à utiliser pour votre workflow d'activation NSX Application Platform spécifique.

Pour effectuer une nouvelle installation de NSX, reportez-vous au Guide d'installation de NSX pour la version 3.2 ou une version ultérieure dans l'ensemble de documentation de VMware NSX pour connaître les instructions d'installation.
Pour plus d'informations sur la mise à niveau à partir d'une installation de NSX Application Platform version 3.2.x, reportez-vous à la section Mettre à niveau NSX Application Platform.
Si vous effectuez une mise à niveau à partir de NSX 3.1.x ou version antérieure sans NSX Intelligence installé, reportez-vous au Guide de mise à niveau de NSX dans la documentation VMware NSX.
Si vous effectuez une mise à niveau à partir de NSX 3.1.x ou version antérieure avec une installation de NSX Intelligence 1.2.x ou version antérieure, vous devez préparer votre installation de NSX Intelligence actuelle avant d'effectuer la mise à niveau vers NSX Intelligence 3.2.x ou version ultérieure et NSX 3.2.x ou version ultérieure. Reportez-vous à la documentation Activation et mise à niveau de VMware NSX Intelligence pour la version 3.2 ou ultérieure dans la documentation de VMware NSX Intelligence.

Licence NSX ou NSX Data Center valide

Pour déployer NSX Application Platform, la session NSX Manager actuelle en cours d'utilisation doit avoir une licence valide en vigueur lors du déploiement de NSX Application Platform.

Reportez-vous à la section Conditions requises de licence pour le déploiement de NSX Application Platform pour obtenir la liste des licences valides.

Rôle d'utilisateur NSX valide

Pour déployer NSX Application Platform, vous devez disposer des privilèges de rôle d'administrateur d'entreprise.

Certificats signés par une autorité de certification valide

Si votre dispositif NSX Manager utilise des certificats signés par une autorité de certification avec une chaîne partielle sur le cluster de dispositifs unifiés de NSX Manager, vous devez remplacer le certificat par une chaîne de certificats complète. Pour plus d'informations, consultez l'article 78317 de la base de connaissances VMware.
Lorsque vous utilisez plusieurs dispositifs NSX Manager, votre environnement doit répondre à l'une des conditions préalables de certificat suivantes.
- Tous les dispositifs doivent partager le même certificat SSL.
- Un certificat SSL dédié doit être émis pour chaque dispositif dans lequel le nom commun (CN) du certificat doit être unique sur tous les nœuds.
- Lors de l'utilisation d'une adresse IP virtuelle (VIP), le certificat du cluster doit être le même que celui partagé par tous les dispositifs individuels ou doit être unique à partir de tous les nœuds.

Ressources requises pour le cluster Kubernetes

VMware prend en charge un déploiement de NSX Application Platform sur un cluster Tanzu Kubernetes Grid (TKG) du superviseur ou d'un cluster Kubernetes en amont.

Important : Kubernetes en amont fait référence à l'instance de Kubernetes Vanilla open source gérée par Cloud Native Computing Foundation et ne couvre pas les distributions ou versions de Kubernetes qui ne sont pas explicitement répertoriées dans le tableau suivant.

Pour obtenir des informations sur l'installation et la configuration du cluster TKG sur le superviseur, reportez-vous à la section Installation et configuration de vSphere with Tanzu (version 8.0) ou au site Web de la documentation de VMware vSphere pour les autres versions.

VMware a testé et prend en charge les versions suivantes.

Version de NSX Application Platform	Version du cluster TKG sur le superviseur	Version de cluster Kubernetes en amont
3.2.0, 3.2.1	1.17 - 1.21	1.17 1.21
4.0.1	1.20 - 1.22	1.20 - 1.24

Votre administrateur d'infrastructure doit configurer le cluster Kubernetes en amont sur lequel vous pouvez déployer NSX Application Platform et les fonctionnalités de NSX que la plate-forme héberge. Suffisamment de ressources doivent être allouées au cluster Kubernetes que vous utilisez pour déployer les espaces NSX Application Platform. Étant donné que chaque fonctionnalité NSX prise en charge a des besoins en ressources spécifiques, déterminez la fonctionnalité NSX hébergée que vous prévoyez d'utiliser.

Reportez-vous à la rubrique Configuration système requise pour NSX Application Platform pour plus d'informations sur les facteurs de forme pris en charge et leurs besoins en ressources.
Important : Le cluster invité Kubernetes utilisé pour NSX Application Platform doit utiliser un domaine de service par défaut cluster.local. Il s'agit de la valeur par défaut définie dans la configuration du cluster :
```
settings: network: serviceDomain: cluster.local 
```
Pour NSX Application Platform, ne modifiez pas cette valeur ou définissez un domaine de service non défini par défaut.
Votre administrateur d'infrastructure doit également installer et configurer les infrastructures suivantes à l'avance.
- CNI (Container Network Interface), telle qu'Antrea, Calico ou Flannel.
- Container Storage Interface (CSI). Pour provisionner des volumes dynamiques, vous devez disposer d'une classe de stockage disponible dans le cluster Kubernetes que vous utilisez. Pour monter en puissance le volume de stockage de données, la classe de stockage doit prendre en charge le redimensionnement de volume.

Exigence d'accès à Internet

Assurez-vous que votre système NSX peut accéder au registre et au référentiel publics hébergés sur VMware où vous pouvez obtenir les images de docker et le graphique Helm NSX Application Platform fournis. L'accès direct à Internet n'est requis que lors des opérations d'installation et de mise à niveau. Cet accès est limité à l'accès sortant sur le port TCP 443 (HTTPS) pour https://projects.registry.vmware.com afin d'accéder aux graphiques Helm de NSX Application Platform et aux images Docker. Aucun accès entrant ou sortant permanent n'est requis.

L'accès Internet sortant est requis pour les machines virtuelles NSX Unified Appliance et les nœuds worker du cluster invité NSX Application Platform.

Si vous avez configuré votre environnement NSX pour utiliser un serveur proxy Internet à l'aide de l'onglet Système > Paramètres généraux > Serveur proxy Internet, notez que NSX Application Platform ne peut pas être déployé à l'aide d'un serveur proxy Internet. Si votre cluster Kubernetes n'a pas accès à Internet ou si vous avez des restrictions de sécurité, consultez les exigences facultatives suivantes pour un registre de conteneur privé avec un service de référentiel de graphiques.

(Exigence facultative) Registre de conteneur privé avec service de référentiel de graphiques

Pour simplifier le processus de déploiement de NSX Application Platform, utilisez le registre et le référentiel hébergés sur VMware. Ce processus de déploiement utilise une connexion sortante uniquement et ne conserve pas les données client.

(Facultatif) Si votre cluster Kubernetes n'a pas accès à Internet ou si vous avez des restrictions de sécurité, votre administrateur d'infrastructure doit configurer un registre de conteneur privé avec un service de référentiel de graphiques. Utilisez ce registre de conteneur privé pour télécharger les graphiques Helm et les images Docker NSX Application Platform requis pour déployer NSX Application Platform. VMware utilise Harbor pour valider le processus de déploiement qui utilise un registre de conteneur privé. Toutefois, le déploiement de NSX Application Platform est basé sur des normes. Reportez-vous à Télécharger les images Docker et les graphiques Helm NSX Application Platform dans un registre conteneur privé pour plus de détails.

(Exigence facultative) URL d'un registre de conteneur privé

Si vous utilisez un registre de conteneur privé, obtenez auprès de votre administrateur d'infrastructure l'URL de ce registre. Vous utilisez cette URL pendant le processus de déploiement.

Fichier de configuration Kubernetes requis

Vous devez également obtenir le fichier de configuration Kubernetes auprès de votre administrateur d'infrastructure. Pour accéder au cluster Kubernetes que vous utilisez en toute sécurité, vous avez besoin du fichier kubeconfig lors du déploiement de NSX Application Platform pour NSX Manager. Pour accéder à toutes les ressources du cluster Kubernetes que vous utilisez, le fichier kubeconfig doit disposer de tous les privilèges.

Important :

Le fichier kubeconfig par défaut d'un cluster invité Kubernetes VMware vSphere^® with Tanzu contient un jeton qui expire par défaut au bout de dix heures. Bien que ce jeton expiré n'affecte pas la fonctionnalité, il génère un message d'avertissement concernant les informations d'identification obsolètes. Pour éviter cet avertissement, avant de déployer NSX Application Platform sur un cluster TKG du superviseur, collaborez avec votre administrateur d'infrastructure pour créer un jeton de longue durée que vous pouvez utiliser lors du déploiement de NSX Application Platform. Pour plus d'informations sur l'extraction du jeton, reportez-vous à la section Générer un cluster TKG sur le fichier de configuration du superviseur avec un jeton sans date d'expiration.

Nom du service ou nom du service d'interface (FQDN) requis

Lors du déploiement de NSX Application Platform, vous fournissez un nom de domaine complet (FQDN) dans la zone de texte Nom du service dans un déploiement NSX 3.2.0 ou dans la zone de texte Nom du service d'interface dans un déploiement NSX 3.2.1 ou versions ultérieures.

La valeur Nom du service ou Nom du service d'interface est utilisée comme point de terminaison HTTPS pour se connecter au NSX Application Platform.

Pour obtenir la valeur FQDN, utilisez l'un des workflows suivants.

Vous devez configurer le nom de domaine complet avec une adresse IP statique dans le serveur DNS avant le déploiement de NSX Application Platform. L'infrastructure du cluster Kubernetes que vous utilisez doit pouvoir attribuer une adresse IP statique. Les environnements Kubernetes pris en charge sont les suivants.
- MetalLB : équilibreur de charge externe pour le cluster Kubernetes en amont.
- VMware Tanzu^® Kubernetes pour VMware vSphere^® 7.0 U2 et VMware vSphere 7.0 U3 avec NSX.
- VMware vSphere with Tanzu à l'aide de la mise en réseau vSphere. Pour plus d'informations, reportez-vous au document VMware vSphere, Activer la gestion de la charge de travail avec la mise en réseau vSphere.
Si le DNS externe est installé (voir la page Web Kubernetes SIGs - External DNS), vous devez uniquement fournir le nom de domaine complet lorsque vous êtes invité à fournir un nom de service. Votre infrastructure Kubernetes configure automatiquement le nom de domaine complet avec une adresse IP dynamique dans le serveur DNS.

Le plan de contrôle de la charge de travail (WCP) avec DNS externe installé est l'environnement Kubernetes pris en charge.

Nom du service de messagerie (pour les déploiements NSX 3.2.1 ou versions ultérieures) requis

La valeur Nom du service de messagerie est un nom de domaine complet pour le point de terminaison HTTPS qui est utilisé pour recevoir les données simplifiées des sources de données NSX.

Ports et protocoles requis

Vérifiez que les ports requis sur votre hôte de cluster Kubernetes sont ouverts pour que NSX Application Platform y accède. Reportez-vous à la page Web VMware Ports and Protocols.

Communication requise à partir de vos nœuds de cluster Kubernetes

Vérifiez que les nœuds de cluster Kubernetes que vous utilisez peuvent atteindre le dispositif NSX Manager.

Exigence de synchronisation des heures système

Synchronisez les heures système sur les nœuds de cluster Kubernetes et le dispositif NSX Manager que vous utilisez.