Deploying NSX Application Platform – Part One: Introduction

NSX Intelligence was introduced in NSX-T 2.5, which is a utility that performs flow monitoring inside NSX as well as providing recommendations for micro-segmentation security policies. Prior to NSX-T 3.2, NSX Intelligence was deployed to your vSphere environment by way of an OVA.

IN NSX-T 3.2, NSX Intelligence is now part of the NSX Application Platform (NAPP), which is a microservices solution that resides upon a Kubernetes (K8s) cluster. NAPP provides the following features for NSX-T 3.2 environments:

  • NSX Intelligence
  • NSX Network Detection and Response
  • NSX Malware Prevention
  • NSX Metrics

In the near future, we hope to spend time with each of these features and their specific uses, but for now, we’d like to focus on the deployment of NAPP itself. If you wish, you may look here for a breakdown of each of these features and the services which they provide.

Wait… I have to utilize Kubernetes?

NAPP requires a Kubernetes (K8s) cluster in your environment. While K8s has been widely adopted by the world at-large, there are environments where it is not utilized today, leaving some NSX-T users in a pinch.

Our intent in the upcoming series of posts is to cover what a person can do who wants to leverage NAPP, but lacks any K8s in their existing environment. As such, we’ve made the following presumptions about your environment:

NAPP itself (via the K8s platform upon which it resides) works great with the ‘NSX Advanced Load Balancer‘, but we did not want it to appear as if utilizing this technology was mandatory for a successful NAPP deployment.

In short, our intent is to show how one can deploy NAPP utilizing only vSphere, without mandating the purchase of VMware Tanzu or utilization of ‘NSX Advanced Load Balancer‘ instances.

NAPP requirements

Let’s take a brief look at what is required to deploy NAPP, followed by a brief explanation of each component:

  1. A 3.2 NSX-T installation
  2. A Harbor repository with the chart repository service and a CA-signed certificate
  3. A Kubernetes workload cluster
  4. NAPP Docker Images and Helm Charts

1. A 3.2 NSX-T Installation with appropriate licensing

An existing installation of NSX-T 3.2 is a requirement to deploy and utilize NAPP. Of particular interest for an NAPP deployment is the K8s workload cluster that hosts NAPP does not have to be installed on an NSX-T prepared host/cluster. For instance, you might have a vSphere environment that doesn’t have NSX-T installed upon it; NAPP components (living in the K8s workload cluster) can reside here without issue, provided they are routable in your environment.

In addition, please note the official licensing requirements for NAPP from VMware. We’ll post them here for your ease of reading:

To deploy the NSX Application Platform, the minimum license edition required is NSX Data Center Enterprise Plus, NSX-T Enterprise Plus, or an equivalent license that includes an add-on license. For example, you can use an NSX Data Center Advanced license with an NSX Advanced Threat Prevention Add-On license. 

For the purposes of our series, will will be operating from a NSX-T 3.2 deployment licensed with the NSX Data Center Enterprise Plus license.

2. A Harbor repository with the chart repository service and a CA-signed certificate

*********UPDATE*********

Shortly before this post went public, VMware announced the availability of their public Harbor repository for the purposes of deploying NAPP. The Helm Repository and Docker registry URLs are:

As long as your environment can reach the above URLs (and, obviously, as long as it’s allowed by your internal security posture), you won’t need to deploy your own Harbor instance; you’ll simply point your NSX-T manager at these URLs when deploying NAPP.

The advantage to you is two fold: 1) You will not need to stand up your own Harbor repository and 2) you will not need to download the NAPP components tgz file, as you’ll be fetching these components directly from the VMware Harbor repository during your NAPP installation.

If you cannot or will not utilize these public offerings, then you will need your own Harbor repository. For that information, please read on…

***************************************

In order to deploy the containerized NAPP components to a K8s cluster, they must first be placed in a location that both the NSX-T Manager and the K8s cluster can reach. Harbor provides this service for us; it’s a well established repository solution designed to fulfill this exact need.

While we will cover this in much greater depth in the next post, the Harbor deployment that we will utilize must :

  • 1) be installed with the chart repository service and
  • 2) utilize a CA signed certificate.

The chart repository requirement itself is fairly straightforward; some of the components utilized to deploy NAPP are Helm charts, which are functionally blue prints that docker and other container runtimes utilize to deploy containers in a specific fashion. The Harbor repository must be installed with the ability to store Helm charts.

Both NSX-T and the K8s workload cluster nodes will communicate with a Harbor repository via HTTPS to fetch the NAPP components for deployment. Like any browser communicating via HTTPS, a certificate from the Harbor server is presented to the client for verification. The expectation is that both the NSX-T manager (via helm) as well as the K8s workload nodes (via docker ) will be able to verify that the certificate presented has been signed by a trusted authority.

If you attempt to use a self-created CA (such as described here in the Harbor installation instructions), neither the NSX-T manager nor the K8s workload nodes will be able to accept the certificate, as it is signed by an unknown CA. While there certainly are ways to import your CA certificate to your K8s workload nodes (see here for an example of how to do it using VMware Tanzu), there is no officially supported way to do so for the NSX-T manager itself.

Since we do not recommend taking an unsupported action upon your NSX-T manager, we instead suggest you utilize a CA signed certificate that has been issued and signed by a publicly trusted certificate authority. For lab purposes, many people utilize certificates provided by Let’s Encrypt to meet this requirement.

3. NAPP Docker Images and Helm Charts

You will need to download a bundle of the NAPP Docker images and Helm charts from the VMware Customer Connect portal. All of the required materials are bundled together in a single tgz file; as of this writing, this file is in excess of 23 GB, so you may want to factor the time in to download this before getting started.

4. A Kubernetes workload cluster

Lastly, we’ll need a K8s workload cluster where the NAPP components will be installed. You may have noticed that we keep using the phrase K8s “workload” cluster. Depending upon the K8s solution that you utilize, you may have what is referred to as a K8s “management” cluster, which is utilized to provision K8s “workload” clusters. These “workload” clusters are where your containerized applications will reside.

Wrap Up

We’ll be going through some of these topics very specifically in the coming posts, but to reiterate, our intent is to provide an individual the ability to deploy and use NAPP without:

  • 1) an existing K8s environment
  • 2) Tanzu licensing
  • 3) NSX Advanced Load Balancer licensing.

With that being said, the components that we will be utilizing are:

  • a vSphere environment to host NAPP on K8s
  • a 3.2 NSX-T environment, which will deploy/consume NAPP
  • a Harbor repository running on a Linux VM
  • VMware Tanzu Community edition (which provides our K8s workload cluster for NAPP)
  • MetalLB (which provides K8s service load balancing features)

As we close today’s post, we assume that you already have NSX-T 3.2 up and working, and you have a vSphere environment identified that will host your future Harbor registry and VMware Tanzu Community edition K8s clusters.

In our next post, we will discuss deploying Harbor for NAPP. See you soon!

Leave a comment