Skip to main content

vSphere with Tanzu (VKS) integration with NSX-T Part-2

 vSphere with Tanzu (VKS) integration with NSX-T Part-2


vSphere with Tanzu (VKS) integration with NSX-T Part-2

Introduction

In the first part of this series, we enabled vSphere with Tanzu on a compute cluster. This allowed developers to use this cluster to run K8s and container-based applications. Vsphere with Tanzu is using the functionality of NSX-T as a networking solution, vSAN as storage solution and so on.

In this part of the blog, we will set up a new Namespace for developers. Developers have two options. They can deploy their container-based application using a vSphere Pod. Alternatively, they can create a K8s cluster on top of a Namespace. In this blog, we will limit the resources a Namespace can use.

Diagram

To deploy, Kubernetes on the vsphere cluster, we have provisioned three ESXi hosts. These hosts are connected to DSwitch (vDS) on uplink-1 (vmnic0), uplink-2 (vmnic1) and are prepared for NSX-T consumption. The compute cluster is already enabled for vSphere HA (default settings), and DRS (fully automated). An edge is already deployed “SA-EDGE-01“. A Tier-0 (K8s-Tier-0) is already deployed. It is connected to the physical environment via BGP. All routes are redistributed to the physical router. For storage purposes, a vSAN (OSA) datastore has been created to provider storage to the K8s Pods

In the first blog, we already enabled the workload management via vSphere client. A cluster of three supervisor cluster has been deployed and a VIP is assigned to to this cluster. NSX-T native load balancing is being used to load balance traffic to this cluster.

NB: In the upcoming part, we will validate the prerequisites required. This will enable workload management for the VI workload domain via SDDC manager.

Configuration

Before we continue, we need to verify the creation of supervisor cluster. To verify, navigate to the Workload Management > Clusters. Cluster SA-Compute-01 is already enabled for vSphere with Tanzu or VMware Kubernetes services (VKS). The supervisor cluster is accessible via IP address 192.168.30.33 or by FQDN resolving to this IP address.

Let’s create our first Namespace “namespace-01“. To create a namespace, navigate to Workload Management > Namespaces, and click on Create Namespace.

A new namespace will be created on top of compute cluster “SA-Compute-01“, and give a name to the namespace “namespace-01”.

Our first namespace “namespace-01” has been created.

Now is the right time to give our developer team access to the Namespace. They can start creating their container-based application using vSphere Pod. They can also build a Kubernetes-based cluster, using either VKS (VMware Kubernetes Services) or Tanzu Kubernetes Grid Service. To add permission, Click on Add Permissions.

Now, lets storage policies vSphere Pod or K8s cluster can use. To add the storage policies, Click on Add Storage.

K8s Storage Policy is our SPBM (Storage based policy management) with FTT=1, Raid=1 policy on the vSAN datastore.

We can enforce limits on CPU, memory, and storage that a namespace will consume. Nevertheless, in this series, we are not enforcing any limits to our newly created namespace.

At last we need to allocate a VM class to our namespace. We can assign multiple VM classes to.a namespace. This VM class will be used by VKS to provide size to K8s worker and control node.

In our lab, we selected best-effort-small VM class for our namespace “namespace-01” due to resource constraints.

Until now, we successfully enabled “Workload Management” and built our first namespace “namespace-01“.

We haven’t configured any vSphere Pod and VKS cluster on our namespace. We will provision our vSphere Pod in our upcoming part of this series.

Let’s verify the same namespace using Kubectl command line interface.

Summary

In the first part of this series, we enabled vSphere with Tanzu on a compute cluster. This allowed developers to use this cluster to run K8s and container-based applications. Vsphere with Tanzu leverages the functionality of NSX-T as a networking solution, vSAN as storage solution and so on.

In this part, we successfully created our first namespace called namespace-01. We also provided necessary permissions, storage policies, VM classes, and resource limits. We can also add content library to our VM class.

In upcoming parts, we will provision vSphere pods, TKG cluster, allowing Harbor repository, and our first application using K8s. We will also verify the requirements from SDDC manager to allow VMware Kubernetes services on VI workload domain.

Comments

Popular posts from this blog

Step-by-Step Explanation of Ballooning, Compression & Swapping in VMware

 🔹 Step-by-Step Explanation of Ballooning, Compression & Swapping in VMware ⸻ 1️⃣ Memory Ballooning (vmmemctl) Ballooning is the first memory reclamation technique used when ESXi detects memory pressure. ➤ Step-by-Step: How Ballooning Works  1. VMware Tools installs the balloon driver (vmmemctl) inside the guest OS.  2. ESXi detects low free memory on the host.  3. ESXi inflates the balloon in selected VMs.  4. Balloon driver occupies guest memory, making the OS think RAM is full.  5. Guest OS frees idle / unused pages (because it believes memory is needed).  6. ESXi reclaims those freed pages and makes them available to other VMs. Why Ballooning Happens?  • Host free memory is very low.  • ESXi wants the VM to release unused pages before resorting to swapping. Example  • Host memory: 64 GB  • VMs used: 62 GB  • Free: 2 GB → ESXi triggers ballooning  • VM1 (8 GB RAM): Balloon inflates to 2 GB → OS frees 2 GB → ESXi re...

ESXi Host Troubleshooting Checklist

  🛠️ ESXi Host Troubleshooting Checklist (With Complete Log Locations) ✅ 1. Host Status & Connectivity Check host state in vCenter (Connected / Not Responding / Disconnected) Review CPU, RAM, and datastore usage Validate HA/DRS recommendations ✅ 2. Hardware Health Monitor hardware sensors (CPU, DIMMs, fans, PSU, RAID) Check RAID controller logs via vendor tools View hardware status in: vCenter → Monitor → Hardware Health DCUI → Hardware Status ✅ 3. Network Validation Verify vSwitches, Port Groups, NIC teaming, VLAN tagging Check vmkernel ports (mgmt, vMotion, iSCSI, vSAN) Test reachability using: Shell vmkping < IP > Show more lines Validate physical NIC status and link speed ✅ 4. Storage & Datastore Checks Confirm datastore accessibility Rescan storage adapters (iSCSI/FC/NFS) Validate multipathing (Round Robin / Fixed / MRU) Check datastore latency with esxtop ✅ **5. Critical Logs & Their Locations (Full List) Here are key ESXi log files that every VMware adm...
  vCenter Troubleshooting Tips, Common Issues & Log Locations 🚀 1. General Troubleshooting Approach A. Check service health first For vCenter Server Appliance (VCSA): Shell https : / / < vcenter - FQDN > : 5480 Show more lines Go to Services → Health to verify: vCenter Server ESXi hosts vSphere Client DNS, NTP, DB connections vpxd, vpxd-svcs, vsphere-ui B. DNS & NTP checks vCenter is highly dependent on correct DNS & time sync. Check: Shell nslookup < vcenter - fqdn > nslookup < esxi - host - fqdn > Show more lines Time drift > 5 minutes causes: Login failures vpxd crashes PSC authentication issues C. Check storage/database health Slow DB/storage = UI slow, tasks hung. For VCSA: Shell df - h du - sh / storage / log / * / var / log Show more lines Free up space if partitions hit >80%. D. Restart critical services safely On VCSA: Shell service - control - - status service - control - - stop - - all service - control - - start - - all ...