Part#5 Deploying vSphere Supervisor cluster for VKS with VDS (Foundation load balancer) VCF9.0.1

-

Deploying vSphere Supervisor cluster for VKS with VDS (Foundation load balancer) VCF9.0.1


In this article I will discuss about deploying vSphere supervisor with the option of VDS with Foundation load balancer. If you use vSphere Distributed Switch (VDS) network, you must configure a load balancer to support the network connectivity to workloads from client networks and to load balance traffic between Kubernetes Clusters. The supported load balancer types are Avi Load Balancer, HAProxy and Foundation Load Balancer.VCF 9 introduces VDS‑based Supervisor networking with a built‑in Foundation LB for lightweight scenarios, reducing moving parts for a lab/POC.
I have selected vSphere Distributed Switch (VDS) with the Foundation Load Balancer to minimize footprint while enabling Supervisor control‑plane and service VIPs.

Overview of Foundation Load Balancer:

Foundation LB is designed for baseline Supervisor use cases; it is not a feature‑parity replacement for NSX Advanced Load Balancer. The Foundation Load Balancer (FLB) is embedded in vCenter which is available when you enable a Supervisor with the VLAN Networking model and provides Layer 4 load-balancing services Choose accordingly if you need advanced L7 features. 
Foundation Load balancer supports 2 types of configuration.
1.  Two Arm Configuration
2. One Arm Configuration

In the lab one arm Configuration is used to simplifies VIP delivery for Supervisor API and related services.

Supervisor Enablement:

 
In vCenter, enable Workload Management and choose VDS networking.


Cluster Deployment:

Here cluster deployment is done due to lab space constraints and one cluster only. Give the supervisor name. Choose Cluster Deployment and enable control plane high-availability




Configure Control Plane Storage policy:

Select the storage Policy. For the sake of simplicity I have selected VSAN default storage policy for simplicity. You can create your own Storage policy




Configure Management Network:

Give the IPs of Management Network, Workload network and L3 routing configuration for Supervisor Cluster.





Configure Load balancer Topology:

With a one arm topology, Only one interface is connected to the Workload/Namespace Network.
No multiple subnets, no multi-arm routing, All VIPs (Supervisor API VIP + optional service VIPs are announced on the same VLAN.

I have selected One Arm for the sake of simplicity due to nested lab.




Configure management and Virtual Server Network:

Configure Control Plane size and API Server DNS name:

I have selected small size it varies based on environment. 



Review settings 



You will see the Supervisor start configuring.





Faced the following issue where Kubernetes Node agent gets stuck for hours.




Troubleshooting steps:

To resolve this issue i performed the following.
1. Manual downloaded the vsphere-wcp-depot-embeded from vcenter and moved it to each esx host and then installed the offline vib




2. Validation of VIB installation




3. Restarted WCP service from vCenter



after service restart the issue got resolved and Supervisor status and Host Config status showed running. 




Verification:

Login to Supervisor Cluster:

kubectl.exe vsphere login --server=172.16.30.201 --insecure-skip-tls-verify




Enjoy using VKS !!!

Lessons learnt: 

1. Pick the simplest FLB topology that fits: one‑arm is fastest to deploy; two‑arm adds segmentation but increases routing/VLAN planning.

















IT Professional with wide range of expertise and having 13+ years of extensive experience in Infrastructure Operations, Planning, Design, deployments, upgradation, migrations and consolidations. A technology enthusiast determined to take self-initiatives for driving transformations

Comments

Post a Comment

Popular posts from this blog

Replacing a vSphere 7.x Machine SSL certificate with a Custom Certificate Authority and Integration with NSX-T

-
Image
After replacing the certificate of vCenter with Custom Certificates (which includes certificate(leaf) + sub CA + root CA) then adding compute manager on NSX-T gives error "  Certificate chain of Compute Manager is invalid. Please check Issuer and Subject in the chain.  (Error Code: 90204)"  and sync status between VC and NSX-T manager is down It is because certificate chain is invalid and Certificate chain is being duplicated in the vCenter.  Resolution: Correct the order  you need to follow the following chain              For Machine SSL Certificate Field: It must include  Certificate + subordinate CA + Root CA like this -----BEGIN CERTIFICATE----- MIIFrDCCBJSgAwIBAgITZgAAADAs1zlIBj9VFgABAAAAMDANBgkqhkiG9w0BAQsFADBjMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIZnB0Y2xvdWQxFjAUBgoJkiaJk/IsZAEZFgZpbnNpZGUxGjAYBgNVBAMTEUZQVENMT1VELVNVQi1DQTAxMB4XDTIxMDIyNDAyNTQyNVoXDTI0MDIyNDAyNTQyNVowKzEpMCcGA1UEAxMgc2duMDltMDF2...
Read more

Part#2: Preparing Hosts For Commissioning in VCF9.0.1 and Fixing FQDN/SAN & Certificate Mismatches during VCF Management domain installation

-
Image
Preparing Hosts For Commissioning in VCF9.0.1  and Fixing FQDN/SAN & Certificate Mismatches during VCF Management domain installation In this article our focus is on preparing ESX hosts for commissioning during the deployment of VCF management domain and fixing host failures during the hosts adding in VCF installer caused by certificate SAN/FQDN mismatches and misconfigured host identity. When deploying a VMware Cloud Foundation (VCF) 9.0 management domain, you must prepare a minimum of three ESX hosts to meet the platform’s baseline requirements. This ensures that core management components have sufficient resources and can operate with the expected level of resilience. A brief specification of hosts used in the lab. No. of ESX 03 Host Memory 128GB Storage 06 Disks 1 100GB, 05 of 250 GB Network adapters 04 Nested Hosts Preparation: I am building these ESX hosts in a nested lab environment and done the following 1.  Download the vendor‑supplied ESX installer and upload the...
Read more