VxPlanet

Welcome back!!! We are at Part 2 of the blog series on NSX Application Platform Automation Appliance (NAPP-AA). In the previous article, we discussed about the NAPP topology deployed by the automation appliance and the deployment of automation appliance into the management vSphere cluster. If you missed it, please check it out below:

Part 1 : Topology and Appliance Deployment – https://vxplanet.com/2024/04/16/nsx-application-platform-automation-appliance-napp-aa-part-1-topology-and-appliance-deployment/

In this blog post, we will deploy the first NAPP instance of the compute workload domain NSX manager cluster onto the TKGS guest cluster on the vSphere management cluster.

Let’s get started:

Deploying NAPP instance using the NAPP Automation Appliance

As stated earlier in Part 1, we will deploy the NAPP components of the NSX managers belonging to the VCF compute clusters into the VCF management workload domain. As such, the NAPP automation appliance configures the management workload cluster as a Supervisor cluster, deploys the TKGS guest cluster which is consumed by NAPP on the NSX compute workload domains.

VxDC01-C01-MGMT is our management vSphere cluster (that will be hosting NAPP components) and VxDC01-C02-Compute is the compute cluster managed by NSX.

Let’s login to the NAPP automation console and start the NAPP deployment wizard.

We will connect to the management workload domain vCenter and select the management cluster “VxDC01-C01-MGMT” , datastore and the storage policy. For this blog post , let’s use the default vSAN storage policy. Optionally we could create custom storage policies in vCenter based on datastore selection to be used for TKGS clusters. This storage policy selected here will map as storage class in the supervisor cluster and on the TKGS guest clusters.

In Part 1, we discussed the NAPP topology and the requirement for three networks. We have already provisioned the below networks with a pool of IP addresses as below:

• Management network (VxDC01-C01-VDS01-MGMT-V1001) – 172.16.10.0/24
• Workload network (VxDC01-C01-VDS01-GenWorkloads-V1005) – 172.16.50.0/24
• VIP network (VxDC01-C01-VDS01-VIP-V1009) – 172.16.90.0/24

Currently, only HAProxy is supported as the load balancer option. As discussed previously, HAProxy load balancer will be deployed in a three leg configuration with interfaces attached to management, workload and VIP networks respectively.

Currently, the maximum number of NAPP instances supported by the NAPP automation appliance is two. Based on the instance count, the tool automatically recommends the IP pool ranges for the workload and VIP networks.

A pool of 5 consecutive IP addresses are required for the management network. This is for the supervisor control plane VMs and it’s lifecycle management. Based on the instance count, the tool suggests the IP pool range required for the workload network where the TKGS guest clusters will be attached.

Since the NSX manager nodes and the TKGS guest clusters (on the workload network) in my home lab have internet access, we will choose the VMware public repository as the source for NAPP components.

Now let’s create the NAPP instance definition.

NAPP instance name must be unique, and this will be used for supervisor namespaces and TKGS guest clusters. Instance name once set, cannot be changed.

Let’s specify the NSX manager details of the compute workload domain. The tool can only deploy NAPP version 4.1.2 and above. Only Advanced form factor is supported for NAPP, starting version 4.1.2.

Let’s start with the minimum configuration for TKGS cluster, ie with 3 control plane nodes and 3 worker nodes. Up to 8 worker nodes are supported (which will be a requirement when we do NAPP scale-out).

Two DNS records need to be pre-created and has to be resolvable. The IP addresses for the DNS entries will be suggested by the workflow (taken from the VIP pool). VIP for these endpoints will be created on the HAProxy load balancer.

• NAPP HTTPS endpoint : vxdc01-cwld01-napp.vxplanet.int
• NAPP Kafka messaging endpoint : vxdc01-cwld01-napp-stream.vxplanet.int

Once the instance definition is created, we can proceed to the pre-checks.

The tool suggests firewall requirements for a successful NAPP deployment. Make sure the rules are in place if the traffic traverses a firewall. As we don’t have any firewall in the homelab, lets skip this step.

The deployment phase happens in two stages:

• Stage 1 – Deploy the supervisor cluster and TKGS guest cluster on the management workload domain
• Stage 2 – Enable NAPP for the NSX instance in the compute workload domain

Stage 1 – Deploy the supervisor cluster and TKGS guest cluster on the management workload domain

Click Deploy to start Stage 1 – Deploy Supervisor cluster and TKGS guest cluster.

This process will take a while to complete. A good time to have a coffee and once we are back this should be completed.

Now let’s verify the deployment from the management workload domain vCenter.

We see that the supervisor cluster with HAProxy is deployed, a supervisor namespace for NAPP instance is created and the TKGS guest cluster for NAPP instance is also deployed.

Let’s verify the supervisor cluster configuration status, Kubernetes status and node health from the Workload management pane.

HAProxy is configured as the load balancer with the specified VIP ranges.

Management and workload networks have been configured correctly with the assigned IP ranges.

A vCenter content library has been created and associated to the supervisor namespace with the necessary TKRs uploaded.

Let’s connect to the supervisor cluster, switch the context to the supervisor namespace and verify we have the storage class, TKRs and necessary VM Classes for the TKGS cluster.

And finally confirm the status of the TKGS guest cluster deployed by the automation appliance:

Stage 2 – Enable NAPP for the NSX instance in the compute workload domain

Click Deploy to start Stage 2 – NAPP instance deployment for the NSX instance in the compute workload domain

This process will take a while to complete. As the deployment progresses, we see that the below namespaces and the respective pods are created in the TKGS cluster on the management workload domain created in stage 1.

• cert-manager (certificate manager pods)
• projectcontour (contour ingress controller)
• nsxi-platform (core platform components – kafka broker messaging system, zookeeper ensemble, fluentd log collection, postgresql databases etc)

For more detailed information on the deployment steps, please check out my previous article below:

NSX 4.1 Application Platform (NAPP) – Part 2 Deployment

Let’s connect to the TKGS cluster and verify that the core platform pods are up and running.

If we check the haproxy config file at /etc/haproxy/haproxy.cfg on the HAProxy node, we see the VIPs for NAPP endpoints (and also the TKG endpoints) are created successfully.

Finally, lets connect to the NAPP dashboard on the compute workload domain NSX manager and confirm we don’t have any open alarms.

Success!!! NSX Application Platform is now enabled on the compute workload domain and is now available for consumption for NSX advanced security features like NSX Intelligence, Malware Prevention and NDR.

NAPP Diagnostics

NAPP automation appliance also comes with a troubleshooting tool that can give a quick overview of the health of the deployment and perform diagnostic tests to detect any issues with the deployment (currently experimental, but looks very helpful). For eg: it gives information about the status of all the pods in the TKGS cluster hosting NAPP components, the services that are created and the status of persistent volumes.

Clicking on the Diagnostic tab will run a number of tests to identify any issues with the NAPP deployment

Let’s break for now and will meet shortly in Part 3 where we discuss about multiple NAPP instance deployments.

Stay tuned!!!

I hope this article was informative. Thanks for reading.

Continue reading? Here are the other parts of this series:

Part 1 – Topology and Appliance Deployment :
https://vxplanet.com/2024/04/16/nsx-application-platform-automation-appliance-napp-aa-part-1-topology-and-appliance-deployment/

Part 3 – Deploying multiple NAPP Instances :
https://vxplanet.com/2024/04/20/nsx-application-platform-automation-appliance-napp-aa-part-3-deploying-multiple-napp-instances/

Part 4 – NAPP Scale-Out :
https://vxplanet.com/2024/04/20/nsx-application-platform-automation-appliance-napp-aa-part-4-napp-scale-out/

Part 5 – NAPP Upgrade:
https://vxplanet.com/2024/07/06/nsx-application-platform-automation-appliance-napp-aa-part-5-napp-upgrade/

Part 6 – Air-gapped Deployment
https://vxplanet.com/2024/07/07/nsx-application-platform-automation-appliance-napp-aa-part-6-air-gapped-internet-restricted-deployments/