Nsx on The IT Hollow

vSphere 7 with Tanzu - Getting Started Guide

Tue, 14 Jul 2020 14:16:18 +0000

VMware released the new version of vSphere with functionality to build and manage Kubernetes clusters. This series details how to deploy, configure, and use a lab running vSphere 7 with Kubernetes enabled.

The instructions within this post are broken out into sections. vSphere 7 requires pre-requisites at the vSphere level as well as a full NSX-T deployment. Follow these steps in order to build your own vSphere 7 with Kubernetes lab and start using Kubernetes built right into vSphere.

Enable Workload Management

Tue, 14 Jul 2020 13:44:36 +0000

This post focuses on enabling the workload management components for vSphere 7 with Kubernetes. It is assumed that the vSphere environment is already in place and the NSX-T configuration has been deployed.

To enable workload management, login to your vCenter as the administrator@vsphere.local account. Then in the Menu, select Work

Within the Workload Management screen, click the ENABLE button.

The first screen in the wizard, will list your compatible vSphere clusters. These clusters must have HA and DRS enabled in fully automated mode. If you are missing clusters, make sure you have ESXi hosts on version 7 with HA and DRS enabled. You’ll also need a Distributed switch on version 7 for these clusters.

vSphere 7 with Kubernetes Environment and Prerequisites

Tue, 14 Jul 2020 13:42:33 +0000

This post describes the lab environment we’ll be working with to build our vSphere 7 with Kubernetes lab and additional prerequisites that you’ll need to be aware of before starting. This is not the only topology that would work for vSphere 7 with Kubernetes, but it is a robust homelab that would mimic many production deployments except for the HA features. For example, we’ll only install one (singular) NSX Manager for the lab where in a production environment would have three.

Tier-0 Gateway

Tue, 14 Jul 2020 13:39:41 +0000

This post will review the deployment and configuration of a Tier-0 gateway to provide north/south routing into the NSX-T overlay networks.

The Tier-0 (T0) gateway is where we’ll finally connect our new NSX-T backed overlay segments to the physical network through an NSX-T Edge which was previously deployed.

The Tier-0 gateway will connect directly to a physical VLAN and on the other side to our T1 router deployed in the previous post. From there, we should have all the plumbing we need to route to our hosts and begin using NSX-T to do some cooler stuff. In the end, the network topology will look something like this:

Tier-1 Gateway and NSX Segments

Tue, 14 Jul 2020 13:36:56 +0000

This post will focus on deploying our first NSX Gateway/Router and setting up our overlay segments. Before you can start these steps, the Edge nodes should be up and running so that they can support the Tier-1 gateways.

NSX uses two types of routers/gateways. We’ll start by using a Tier-1 (T1) router. These routers are usually used to pass traffic between NSX overlay segments. We could create NSX segments without any routers, but it would require a router to pass traffic between these segments so we will create a T1 router first.

Deploy NSX-T Edge Nodes

Tue, 14 Jul 2020 13:26:22 +0000

NSX-T Edge nodes are used for security and gateway services that can’t be run on the distributed routers in use by NSX-T. These edge nodes do things like North/South routing, load balancing, DHCP, VPN, NAT, etc. If you want to use Tier0 or Tier1 routers, you will need to have at least 1 edge node deployed. These edge nodes provide a place to run services like the Tier0 routes. When you first deploy an edge, its like an empty shell of a VM until these services are needed.

NSX Pools, Zones, and Nodes Setup

Tue, 14 Jul 2020 13:23:46 +0000

In the previous post we deployed an NSX Manager. Now it’s time to start configuring NSX so that we can build cool routes, firewall zones, segments, and all the other NSX goodies. And even if we don’t want to build some of these things, we’ll need this setup for vSphere 7 with Kubernetes.

Add an IP Pool

The first thing we’ll setup is an IP Pool. As you might guess, an IP Pool is just a group of IP Addresses that we can use for things. Specifically, we’ll use these IP Addresses to assign Tunnel Endpoints (Called TEPs previously called VTEPs in NSX-V parlance) to each of our ESXi hosts that are participating in the NSX Overlay networks. The TEP becomes the point in which encapsulation and decapsulation takes place on each of the ESXi hosts. Think of it this way, when encapsulated traffic needs to be routed to a VM on a host, what IP Address do we need to send the traffic to, so that it can reach that VM. This is the TEP. We need to setup a TEP on each host, and the IP Addresses for these TEPs come from an IP Pool. Since I have three hosts, and expect to deploy 1 edge nodes, I’ll need a TEP Pool with at least 4 IP Addresses. Size your environment appropriately.

NSX Installation

Tue, 14 Jul 2020 13:18:52 +0000

This post will focus on getting the NSX-T Manager deployed and minimally configured in the lab. NSX-T is a pre-requisite for configuring vSphere 7 with Kubernetes as of the time of this writing.

Deploy the NSX Manager

The first step in our build is to deploy the NSX Manager from an OVA template into our lab. The NSX Manager is the brains of the solution and what you’ll be interacting with as a user. Each time you configure a route, segment, firewall rule, etc., you’ll be communicating with the NSX Manager. Download and deploy the OVA into your vSphere lab.

NSX Issues After Replacing VMware Self-Signed Certs

Mon, 13 Mar 2017 14:05:58 +0000

Recently, I’ve been going through and updating my lab so that I’m all up to date with the latest technology. As part of this process, I’ve updated my certificates so that all of my URLs have the nice trusted green logo on them. Oh yeah, and because it’s more secure.

I updated my vSphere lab to version 6.5 and moved to the vCenter Server Appliance (VCSA) as part of my updates. However, after I replaced the default self-signed certificates I had a few new problems. Specifically, after the update, NSX wouldn’t connect to the lookup service. This is particularly annoying because as I found out later, if I’d have just left my self-signed certificates in tact, I would never have had to deal with this. I thought that I was doing the right thing for security, but VMware made it more painful for me to do the right thing. I’m hoping this gets more focus soon from VMware.

vRealize Automation 7 - Deploy NSX Blueprints

Wed, 09 Mar 2016 15:10:20 +0000

In the previous post we went over how to get the basics configured for NSX and vRealize Automation integration. In this post we’ll build a blueprint and deploy it! Let’s jump right in and get started.

Blueprint Designer

Login to your vRA tenant and click on the Design Tab. Create a new blueprint just like we have done in the past posts. This time when you are creating your blueprint, click the NSX Settings tab and select the Transport zone. I’ve also added a reservation policy that can help define with reservations are available for this blueprint.

vRealize Automation 7 - NSX Initial Setup

Mon, 07 Mar 2016 15:01:03 +0000

Its time to think about deploying our networks through vRA. Deploying servers are cool, but deploying three tiered applications in different networks is cooler. So lets add VMware NSX to our cloud portal and get cracking.

The first step is to have NSX up and running in your vSphere environment. Once this simple task is complete, a Distributed Logical Router should be deployed with an Uplink interface configured. The diagram below explains what needs to be setup in vSphere prior to doing any configurations in vRealize Automation. A Distributed Logical Router with a single uplink to an Edge Services Gateway should be configured first, then any new networks will be built through the vRealize Automation integration. While the section of the diagram that is manual, will remain roughly the same throughout, the section handled by vRealize Automation will change often, based on the workloads that are deployed. Note: be sure to setup some routing between your Provider Edge and the DLR so that you can reach the new networks that vRA creates.

vRealize Automation 6 with NSX – Firewall

Mon, 30 Nov 2015 15:08:27 +0000

So far we’ve talked a lot about using our automation solution to automate network deployments with NSX. But one of the best features about NSX is how we can firewall everything! Lucky for us, we can automate the deployment of specific firewall rules for each of our blueprints as well as deploying brand new networks for them.

Use Case: There are plenty of reasons to firewall your applications. It could be for compliance purposes or just a good practice to limit what traffic can access your apps.

vRealize Automation 6 with NSX – Load Balancing

Mon, 09 Nov 2015 15:19:10 +0000

If you’re building a multi-machine blueprint or multi-tiered app, there is a high likelihood that at least some of those machines will want to be load balanced. Many apps require multiple web servers in order to provide additional availability or to scale out. vRealize Automation 6 coupled with NSX will allow you to put some load balancing right into your server blueprints.

Just to set the stage here, we’re going to deploy an NSX Edge appliance with our multi-machine blueprint and this will load balance both HTTPs and HTTP traffic between a pair of servers.

vRealize Automation 6 with NSX - NAT

Mon, 02 Nov 2015 15:10:54 +0000

You’re network isn’t fully on IPv6 yet? Ah, well don’t worry you’re certainly not alone, in fact you’re for sure in the majority. Knowing this, you’re probably using some sort of network address translation (NAT). Luckily, vRealize Automation can help you deploy translated networks as well as routed and private networks with a little help from NSX.

A quick refresher here, a translated network is a network that remaps an IP Address space from one to another. The quickest way to explain this is a public and a private IP Address. Your computer likely sits behind a firewall and has a private address like 192.168.1.50 but when you send traffic to the internet, the firewall translates it into a public IP Address like 143.95.32.129. This translation can be used to do things like keeping two servers on a network with the exact same IP Address.

vRealize Automation 6 with NSX - Routed Networks

Mon, 26 Oct 2015 14:00:28 +0000

Any corporate network thats larger than a very small business is likely going to have a routed network already. Segmenting networks improves performance and more importantly used for security purposes. Many compliance regulations such as PCI-DSS state that machines need to be segmented from each other unless there is a specific reason for them to be on the same network. For instance your corporate file server doesn’t need to communicate directly with your CRM database full of credit card numbers. The quickest way to fix this is to put these systems on different networks but this can be difficult to manage in a highly automated environment. Developers might need to spin up new applications which may need to be on different network segments from the rest of the environment. Its not very feasible to assume we can now spin up test and delete hundred of machines each day, but need the network team to manually create new network segments and tear them down each day. That wouldn’t be a nice thing to do to your network team.

vRealize Automation 6 with NSX - Private Networks

Mon, 19 Oct 2015 14:05:45 +0000

Of the types of networks available through NSX, private networks are the easiest to get going because they don’t require any NSX edge routers to be in place. Think about it, the NSX edge appliance is used to allow communication with the physical network which we won’t need for a private network.

A quick refresher here, a private network is a network that is not connected to the rest of the environment. Machines that are on the private network can communicate with each other, but nothing else in the environment. Its simple, think of some machines connected to a switch and the switch isn’t connected to any routers. The machines connected to the switch can talk to each other, but thats it.

Software Defined Networking with vRealize Automation and NSX

Mon, 12 Oct 2015 14:30:53 +0000

This is a series of posts helping you get familiarized with how VMware’s vRealize Automation 6 can leverage VMware’s NSX product to provide software defined networking. The series will show you how to do some basic setup of NSX as well as how to use Private, Routed and NAT networks all from within vRA.

vRealize Automation 6 with NSX - NSX Setup

vRealize Automation 6 with NSX - Private Networks

vRealize Automation 6 with NSX - Routed Networks

vRealize Automation 6 with NSX - NAT

vRealize Automation 6 with NSX - Load Balancing

vRealize Automation 6 with NSX - Firewall

vRealize Automation 6 with NSX - Initial Setup of NSX

Mon, 12 Oct 2015 14:00:22 +0000

Before we can start deploying environments with automated network segments, we need to do some basic setup of the NSX environment.

NSX Manager Setup

It should be obvious that you need to setup NSX Manager, deploy controllers and do some host preparation. These are basic setup procedures just to use NSX even without vRealize Automation in the middle of things, but just as a quick review:

Install NSX Manager and deploy NSX Controller Nodes

NSX Manager setup can be deployed from an OVA and then you must register the NSX Manager with vCenter. After this is complete, deploy three NSX Controller nodes to configure your logical constructs.