NSX-T 2.5 What is new for Kubernetes

NSX-T 2.5 was released last week and now we also have the new NSX Container Plugin 2.5 on the market…. VMworld US 2019 is also over with announcements of huge innovations like NSX Intelligence, enhanced security, and improved operability and observability. You can find more information here! I would like to take this opportunity to specifically highlight the new containers capabilities we had been working on for this release.

What is new in NSX Container plugin (NCP)

Simplified UI (Policy API) support

With the introduction of the new intent-based Policy API and corresponding Simplified UI, administrators have seen that objects created by NCP for Kubernetes are not visible in the new UI. Instead they had to go to the Advanced Networking & Security tab that corresponds to the old imperative APIs. Furthermore, all related objects like T0, IP Block, IP Pool had to be created using the Advanced Networking & Security tab. I am happy to announce that from NCP 2.5+ we have a parameter in the NCP configmap (ncp.ini) policy_nsxapi that can be set to True. In that case, NCP will start calling the new intent-based API and all objects will be visible in the simplified UI. Continue reading

NSX-T Integration with Openshift

I am sometimes being approached with questions about NSX-T integration details for Openshift. It seems people are well aware how NSX-T works and integrates with Pivotal Container Service (aka PKS), Pivotal Application Service (PAS formerly known as PCF), and even with vanilla Kubernetes but there is no much information how we integrate with Redhat’s Openshift. This post aims to throw some light on the integration with this platform. In the examples below I am using Openshift Origin (aka OKD) but for a supported solution you need to go with Openshift Enterprise Platform. The same NSX-T instance can be used for providing networking, security, and visibility to multiple Openshift clusters.

Example Topology

In this topology we have a T0 router that connects physical with virtual world. We also have T1 router acting as a default gateway for the Openshift VMs. Those VMs have two vNICs each. One vNIC is connected to Management Logical Switch for accessing the VMs. The second vNIC is connected to a disconnected Logical Switch and is used by nsx-node-agent to uplink the POD networking. The LoadBalancer used for configuring Openshift Routes plus all project’s T1 routers and Logical Switches are created automatically later when we Continue reading

NSX-T Automation with Terraform

Do you want to maintain your network and security infrastructure as a code? Do you want to automate NSX-T? One more option has been just added for you!

Following my previous post about NSX-T: OpenAPI and SDKs you might have figured out how easy it is to generate different language bindings for NSX-T. Thankfully to this, we have generated Go Lang NSX-T SDK that we use as a foundation of the new NSX-T Terraform provider.

Terraform is an open-source infrastructure as a code software by HashiCorp. It allows creation, modification, and deletion of an infrastructure using a high-level configuration files that can be shared between team members, treated as a code, edited, reviewed, and versioned. These configuration files are written in HCL(HashiCorp Configuration Language) which is actually JSON with some fine-tuning. Plain JSON can be also used.

There are several important components in Terraform:

1. Providers are responsible for managing the lifecycle of the resources: create, read, update, delete. The Providers usually require some sort of configuration to provide authentication, endpoint URLs, etc. By default, resources are matched with the provider with the start of the name. For example, a resource nsxt_logical_switch is associated with provider called nsxt.

Example of Continue reading

NSX-T Automation with Terraform

Do you want to maintain your network and security infrastructure as a code? Do you want to automate NSX-T? One more option has been just added for you! Following my previous post about NSX-T: OpenAPI and SDKs you might have figured out how easy it is to generate different language bindings for NSX-T. Thankfully to this, we... Read more →

NSX-T: OpenAPI and SDKs

Nowadays everything is about automation. Organizations are moving away from the traditional static infrastructure to full automation and here the need of NSX is significant. There are many use-cases for NSX, but the common in all of them is that they all need to be automated.

VMware is investing heavenly for different tools to ease the automation aspect of NSX but in order to take full advantage of it one need to understand what happens under the hood. It is also important if someone wants to build their own custom automation tool or CMP (Cloud Management Platform). Many existing solutions like Openstack, Kubernetes, vRO and so on automate NSX-T using different plugins. In fact, those plugins are sending REST API calls to NSX Manager in order to automate logical topology CRUD(Create, Read, Update, Delete) operations.

Based on our experience we decided that NSX-T APIs will be based on JSON format following OpenAPI standard. The use of Open APIs is to enable third party developers to build applications and services around NSX-T by standardising on how REST APIs are described. This means one can use standard tools like Swagger to read and use those APIs. Below is a quick example from my Mac on Continue reading