vSphere Foundation Load Balancer (FLB): Architecture, Network Requirements, and FAQ

Products

VMware vSphere Kubernetes Service VMware Cloud Foundation

Issue/Introduction

^{The purpose of this Knowledge Base (KB) article is to provide a centralized, extensible repository of Frequently Asked Questions (FAQs) regarding the VMware vSphere Foundation Load Balancer (FLB).}

^{With the introduction of the Foundation Load Balancer as a natively integrated solution for vSphere with Tanzu, administrators frequently require clarification on its architectural footprint, how it differs from legacy load balancing solutions (such as the HAProxy OVA), and the strict firewall prerequisites required for successful deployment.}

^{This document serves as a living reference guide for vSphere Administrators and Network Security teams planning or managing an FLB deployment. As new inquiries arise, this article will be updated to reflect the latest architectural guidance.}

Environment

^{Foundation load balancer}

^{VCF 9.x}

Resolution

^{1. Architecture & Deployment Footprint}

^{Question: Does FLB deploy as a standalone VM appliance, or is it a service integrated within the Supervisor Cluster?}

^{Answer: The Foundation Load Balancer operates as a standalone VM appliance, but it is completely orchestrated as an integrated solution by vCenter Server.}

^{Unlike a Kubernetes-native ingress controller (which runs as a containerized Pod inside a cluster), the FLB VMs sit outside the Supervisor and Workload clusters directly on the ESXi host, acting as the centralized network gateway.}

^{During the Supervisor enablement process in the vSphere Client, vCenter's internal Lifecycle Manager (specifically the FoundationLoadBalancersSvc) automatically provisions the FLB VM appliances alongside the Supervisor Control Plane VMs. Administrator Action Required: None. You do not manage these VMs directly; they are locked, system-managed appliances that should not be manually modified.}

^{2. Lifecycle Management & Operational Differences}

^{Question: How does FLB functionality and lifecycle management differ from a traditional HAProxy VM deployment?}

^{Answer: The shift from HAProxy to the Foundation Load Balancer represents a transition from a manually managed third-party appliance to a zero-touch, vCenter-managed architectural component.}

^Feature	^{Legacy HAProxy Deployment}	^{Modern Foundation Load Balancer (FLB)}
^{Deployment Mechanism}	^{Manual: Required manually downloading the OVA, deploying to the cluster, configuring network interfaces, and inputting management IPs into the enablement wizard.}	^{Automated (Zero-Touch): Enabled natively via the vSphere UI. vCenter handles the entire deployment and configuration automatically alongside the Supervisor.}
^{Lifecycle & Upgrades}	^{Manual: Upgrading required a separate, manual appliance replacement and configuration migration.}	^{Automated: Upgrades are bundled and orchestrated automatically during standard vCenter and Supervisor lifecycle updates.}
^{IP Address Management (IPAM)}	^{Static: IP assignments were bound strictly to the initial OVA deployment configuration.}	^{Dynamic: Integrates seamlessly with the native IPAM of the Supervisor. When a developer deploys a LoadBalancer Service, the internal API automatically provisions the VIP directly onto the FLB.}
^{High Availability (HA)}	^{Rigid: Relied on a static Active/Passive configuration that was complex to troubleshoot.}	^{Flexible: Supports out-of-the-box architectural sizing (e.g., deploying as a single VM for resource-constrained Edge environments, or highly available pairs for standard production clusters).}

^{3. Network & Firewall Prerequisites}

^{Question: What are the specific port and firewall requirements for FLB?}

^{Answer: Because the FLB sits directly between your corporate network (clients) and the Kubernetes nodes, your firewalls must permit specific traffic flows for both Control Plane API access and backend developer workloads.}

^{To ensure the FLB functions correctly and LoadBalancer services can successfully route traffic, the following network paths must be permitted through your enterprise firewall:}

^{Frontend / Ingress Traffic (Clients to FLB)}

^Source	^Destination	^{Port / Protocol}	^Purpose
^{Corporate Network / End Users}	^{FLB Virtual IPs (VIPs)}	^{TCP 6443}	^{Required for administrators and developers to reach the Kubernetes/Supervisor API.}
^{Corporate Network / End Users}	^{FLB Virtual IPs (VIPs)}	^{TCP 80 / 443}	^{Standard web traffic required to reach the actual containerized applications deployed by developers.}

^{Backend / Egress Traffic (FLB to Kubernetes Nodes)}

^Source	^Destination	^{Port / Protocol}	^Purpose
^{FLB VMs}	^{Supervisor Control Plane VMs}	^{TCP 6443}	^{Required for the load balancer to route API traffic to the Supervisor nodes.}
^{FLB VMs}	^{Workload Cluster Worker Nodes}	^{TCP 30000 - 32767}	^{Crucial: Kubernetes maps LoadBalancer VIPs to backend NodePorts. The FLB must be able to reach any worker node on this high-port range to successfully pass traffic to the underlying pods.}

^{Management & Telemetry Traffic}

^Source	^Destination	^{Port / Protocol}	^Purpose
^{vCenter Server}	^{ESXi Hosts / FLB Mgmt Network}	^{TCP 443}	^{Required for vpxd and the Foundation Load Balancer Service to monitor health, provision, and update the FLB VMs.}

^{Related Information}

^{For further architectural planning and comprehensive standard operating procedures, please review the official Broadcom product documentation:}

^{https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/vsphere-supervisor-installation-and-configuration/deploying-vsphere-supervisor-with-foundation-load-balancer.html (Note: Always reference the specific build version of your vSphere environment for exact requirements).}

^{Note: This is a living document. If you have additional questions regarding FLB architecture that are not covered here, please engage Broadcom Support, and this article will be updated accordingly to assist the broader community.}