To install the NSX Application Platform successfully and to activate the NSX features that it hosts, you must prepare the deployment environment so that it meets the minimum required resources.

You must satisfy the prerequisites listed in the following sections before you start deploying the NSX Application Platform.

NSX-T Data Center version requirement

Confirm that the NSX-T Data Center product version you are using is compatible with the NSX Application Platform version that you plan to deploy, along with its related NSX-T Data Center features (NSX Intelligence, NSX Network Detection and Response, NSX Malware Prevention, and NSX Metrics).

The versioning of the NSX-T Data Center features that are hosted on the NSX Application Platform matches the NSX Application Platform version number, and not the NSX-T Data Center product version number.

Important:

In an NSX Federation environment, you can deploy the NSX Application Platform on Local Managers only. You cannot deploy the NSX Application Platform using Global Managers. You can access the NSX Application Platform using a Local Manager only.

To determine which NSX Application Platform version you can deploy with which NSX-T Data Center version, use the following compatibility matrix.

NSX-T Data Center version

Compatible NSX Application Platform version

3.2.x

3.2.0, 3.2.1

Use the following information in determining which documentation to use for your specific NSX Application Platform activation workflow.
  • If you need to install a brand new NSX-T Data Center installation, see the NSX-T Data Center Installation Guide for version 3.2.x or later in the VMware NSX Documentation set for installation instructions.
  • For information about upgrading from an earlier NSX Application Platform version 3.2.x installation, see Upgrade the NSX Application Platform.
  • If you are upgrading from NSX-T Data Center 3.1.x or earlier without NSX Intelligence installed, see the NSX-T Data Center Upgrade Guide in the VMware NSX Documentation set.
  • If you are upgrading from NSX-T Data Center 3.1.x or earlier with an installation of NSX Intelligence 1.2.x or earlier, you must prepare your current NSX Intelligence installation before you upgrade to NSX Intelligence 3.2.x, and NSX-T Data Center 3.2.x. See the Activating and Upgrading VMware NSX Intelligence documentation for version 3.2 in the VMware NSX Intelligence Documentation set.

Valid NSX-T or NSX Data Center license requirement

To deploy the NSX Application Platform, the current NSX Manager session in use must have a valid license in effect during the NSX Application Platform deployment.

See License Requirement for NSX Application Platform Deployment for the list of valid licenses.

Valid NSX-T Data Center user role

To deploy the NSX Application Platform, you must have Enterprise Admin role privileges.

Valid CA-signed certificates

  • If your NSX Manager appliance uses CA-signed certificates with partial chain on the NSX Manager Unified Appliance cluster, you must replace the certificate with a full certificate chain. See VMware Knowledge Base article 78317 for more information.

  • When using multiple NSX Manager appliances, your environment must meet one of the following certificate prerequisites.

    • All the appliances must share the same SSL certificate.

    • A dedicated SSL certificate must be issued for each appliance, where the certificate Common Name (CN) must be unique across all nodes.

    • When using a Virtual IP (VIP), the cluster certificate must either be the same as shared by all individual appliances or must be unique from all the nodes.

Required resources for the Kubernetes cluster

  • VMware supports an NSX Application Platform deployment on a Tanzu Kubernetes Grid (TKG) Cluster on Supervisor or an Upstream Kubernetes cluster.
    Important: Upstream Kubernetes refers to the vanilla, open-source Kubernetes maintained by the Cloud Native Computing Foundation and does not cover any distributions or releases of Kubernetes which are not explicitly listed in the following table.

    For TKG Cluster on Supervisor installation and configuration information, see Installing and Configuring vSphere with Tanzu (version 8.0) or VMware vSphere Documentation website for other versions.

    VMware tested and supports the following versions.

    NSX Application Platform version

    TKG Cluster on Supervisor version

    Upstream Kubernetes cluster version

    3.2.0, 3.2.1
    • 1.17.17, 1.18.19 (See the following Note)

    • 1.19.11, 1.20.7, 1.21.2, 1.21.6

    1.17, 1.18, 1.19, 1.20, 1.21

    Note:

    The NSX Application Platform Scale Up operation is not supported on TKG Cluster on Supervisor versions 1.17.x and 1.18.x. See Failed to Increase the Volume Size of the Data Storage Disk for details.

  • Your infrastructure administrator must configure the TKG Cluster on Supervisor or upstream Kubernetes cluster on which you can deploy the NSX Application Platform and the NSX features that the platform hosts. Enough resources must be allocated to the TKG Cluster on Supervisor or upstream Kubernetes cluster to deploy the NSX Application Platform pods. Because each supported NSX feature has specific resource requirements, determine which of the hosted NSX feature you plan to use.

    See the NSX Application Platform System Requirements topic for details about the supported form factors and their resource requirements.

  • Important: The Kubernetes guest cluster used for the NSX Application Platform must use a default Service Domain of cluster.local. This is the default value and is defined in the cluster configuration:
    settings: network: serviceDomain: cluster.local 
    For NSX Application Platform, do not change this value or set a non-default service domain.
  • Your infrastructure administrator must also install and configure the following infrastructures in advance.

    • Container Network Interface (CNI), such as Antrea, Calico, and Flannel.

    • Container Storage Interface (CSI). You must have an available storage class in the TKG Cluster on Supervisor or upstream Kubernetes cluster to provision dynamic volumes. To scale up the data storage volume, the storage class must support volume resize.

Internet access requirement

Ensure that your NSX-T Data Center system can access the public VMware-hosted registry and repository where you can obtain the packaged NSX Application Platform Helm chart and Docker images. The direct Internet access is only required during the installation and upgrade operations. This access is limited to the outbound access on TCP Port 443 (HTTPS) to https://projects.registry.vmware.com for the purpose of accessing the NSX Application Platform installation Helm charts and Docker images. No inbound access or permanent outbound access is required.

The outbound Internet access is required for both the NSX-T Data Center Unified Appliance VMs and NSX Application Platform guest cluster worker nodes.

If you configured your NSX-T Data Center environment to use an Internet proxy server using the System > General Settings > Internet Proxy Server tab, note that the NSX Application Platform can not be deployed using an Internet proxy server. If your Kubernetes cluster does not have access to the Internet or you have security restrictions, see the next optional requirement for an optional Private container registry with chart repository service.

(Optional Requirement) Private container registry with chart repository service

To simplify the NSX Application Platform deployment process, use the VMware-hosted registry and repository. This deployment process uses an outbound connection only and does not retain customer data.

(Optional) If your Kubernetes cluster does not have access to the Internet or you have security restrictions, your infrastructure administrator must set up a private container registry with a chart repository service. Use this private container registry to upload the NSX Application Platform Helm charts and Docker images required to deploy the NSX Application Platform. VMware used Harbor to validate the deployment process that uses a private container registry, however, the NSX Application Platform deployment is standards-based. See Upload the NSX Application Platform Docker Images and Helm Charts to a Private Container Registry for details.

(Optional Requirement) URL for a private container registry

If you are using a private container registry, obtain from your infrastructure administrator the URL for that registry. You use this URL during the deployment process.

Required Kubernetes configuration file

You must also obtain the Kubernetes configuration file from your infrastructure administrator. You need the kubeconfig file during the NSX Application Platform deployment for the NSX Manager to securely access your TKG Cluster on Supervisor or upstream Kubernetes cluster. The kubeconfig file must have all the privileges to access all the resources of the TKG Cluster on Supervisor or upstream Kubernetes cluster.

Important:

The default kubeconfig file in a VMware vSphere® with Tanzu Kubernetes Guest Cluster contains a token which expires after ten hours by default. While this expired token does not impact functionality, it results in a warning message regarding out-of-date credentials. To avoid the warning, before you deploy the NSX Application Platform on a TKG Cluster on Supervisor, work with your infrastructure administrator to create a long-lived token you can use during the platform deployment. See Generate a TKG Cluster on Supervisor Configuration File with a Non-Expiring Token for details on how to extract the token.

Required Service Name or Interface Service Name (FQDN)

During the NSX Application Platform deployment, you provide a fully qualified domain name (FQDN) for the Service Name text box in an NSX-T Data Center 3.2.0 deployment or for the Interface Service Name text box in an NSX-T Data Center 3.2.1 or later deployment.

The Service Name or Interface Service Name value is used as the HTTPS endpoint to connect to the NSX Application Platform.

To obtain the FQDN value, use one of the following workflows.

  • You must configure FQDN with a static IP address in the DNS server before the NSX Application Platform deployment. The TKG Cluster on Supervisor or upstream Kubernetes cluster infrastructure must be able to assign a static IP address. The following are the supported Kubernetes environments.

    • MetalLB - an external load balancer for upstream Kubernetes cluster.

    • VMware Tanzu® Kubernetes for VMware vSphere® 7.0 U2 and VMware vSphere 7.0 U3 with NSX-T Data Center.

    • VMware vSphere with Tanzu using vSphere networking. See the VMware vSphere document, Enable Workload Management with vSphere Networking, for more information.

  • If you have the External DNS installed (see the Kubernetes SIGs - External DNS webpage), you only have to provide the FQDN when prompted for a Service Name. Your Kubernetes infrastructure automatically configures the FQDN with a dynamic IP address in the DNS server.

    The Workload Control Plane (WCP) with External DNS installed is the supported Kubernetes environment.

Required Messaging Service Name (for NSX-T Data Center 3.2.1 or later deployments)

The Messaging Service Name value is an FQDN for the HTTPS endpoint that is used to receive the streamlined data from the NSX-T Data Center data sources.

Required ports and protocols

Verify that the required ports on your Kubernetes cluster host are open for the NSX Application Platform to access. See the VMware Ports and Protocols webpage.

Required communication from your Kubernetes cluster nodes

Confirm that the Kubernetes cluster nodes you are using can reach the NSX Manager appliance.

System times synchronization requirement

Synchronize the system times on the TKG Cluster on Supervisor or upstream Kubernetes cluster nodes and the NSX Manager appliance.