Eight vCPUs and 32 GB of RAM. That is the smallest NSX Edge node Broadcom permits underneath a Supervisor, and getting it wrong does not give you a slow application, it gives you a Supervisor that never finishes enabling.
Three sizing decisions hiding inside one objective
Broadcom writes this objective as a single phrase about load balancer size, and candidates read it as a single question. It is three. First, which load balancer model your workload network permits, which Part 6 settled and this Part will not restate. Second, how large the thing running that load balancer is, meaning an NSX Edge form factor, an Avi Controller size and Service Engine group, or the count of Foundation Load Balancer virtual machines. Third, how many virtual IP addresses the pool you handed it can actually issue.
Only the second one is what most people mean by sizing, and it is the one Broadcom is asking about. Miss the third and you get a stranded Supervisor with plenty of spare capacity and no addresses to hand out, which is a different failure with an almost identical symptom.
Every part of this decision is a Supervisor decision, not a cluster decision. You pick the load balancer model and its size before Supervisor activation, and after that every vSphere Namespace, every VKS cluster control plane endpoint and every Service of type LoadBalancer inside those clusters draws from the same pool. A VKS cluster that will not finish provisioning is almost never a cluster problem. It is a Supervisor that cannot get a virtual server allocated on your behalf. One naming note while we are in this territory: VKS is the product formerly called TKG Service or TKGS, and when you go looking at the load balancer objects backing a workload cluster you will still see tkg in the generated names. Broadcom renamed the product, not the object naming.
Sizing knobs per load balancer model
Each of the three models exposes a completely different knob, and that asymmetry is what scenario items are built on. Print this one. It is the first of two reference artifacts in this Part and it answers the only question that matters when a scenario tells you the estate is short on load balancer capacity: what, specifically, do you enlarge.
| Model | What you actually size | Broadcom floor | Shared with non Supervisor workloads | Resize in place |
|---|---|---|---|---|
| Foundation Load Balancer | Appliance count and arm topology: one arm with one NIC, one arm with two NICs, or two arm with three NICs | Two or three routable distributed port groups, prepared manually before activation | No | Availability only, one VM to two VMs active and passive |
| NSX Load Balancer | Edge node form factor, plus load balancer service size small, medium, large or extra large | Edge nodes at minimum large form factor, 8 vCPU and 32 GB | No | Scale Edges up or out, which means redeploying nodes |
| Avi Load Balancer | Controller size, controller disk, and Service Engine group scale out per virtual service | Three node controller cluster recommended; single node only at small size and only via a KB procedure | Yes, Avi also fronts traditional VM workloads | Service Engines yes, Controller no, there is no CPU or memory hot add |
Two rows on that table deserve a second look. Foundation Load Balancer and NSX Load Balancer both refuse to serve anything other than Supervisor and the services Supervisor manages, so capacity you buy for them is capacity you cannot amortise across the rest of the estate. Avi is the only model where an oversized deployment earns its keep elsewhere, and that changes the cost conversation more than any feature comparison does.
Avi Controller sizing is where hard numbers exist, so learn these rather than a vague sense that bigger is better. Allocations below come from the 30.1.1 reference and are the ones a design question will lean on.
| Controller size | CPU and memory | Base processes | Log analytics | Service Engine scale |
|---|---|---|---|---|
| Essentials | 4 CPU, 24 GB | 15 GB | 9 GB | 0 to 10, capped at 100 virtual services |
| Small | 6 CPU, 32 GB | 19 GB | 13 GB | 0 to 100 |
| Medium | 10 CPU, 32 GB | 19 GB | 13 GB | 100 to 200 |
| Large | 16 CPU, 48 GB | 24 GB | 24 GB | 200 to 400 |
Notice that Small and Medium carry identical memory and identical analytics allocations. Four extra cores are the entire difference, and they double the Service Engine ceiling from 100 to 200. That is unusually good value in a sizing table, and it is the answer to the most common real world question about Avi in a VKS estate: if you are anywhere near 100 Service Engines, go to Medium and stop thinking about it.
Disk is a separate axis and it is sized by virtual service count rather than by controller size. Broadcom’s guidance is 80 GB total for 100 virtual services without full logs, 216 GB for 1,000, and 736 GB for 5,000, with metrics alone consuming roughly 32 MB per virtual service. Default controller OVA disk must be raised to 128 GB before deployment. I have watched more Avi Controllers fall over from a full metrics database than from CPU pressure, and the symptom is not obvious: analytics stop updating, then the user interface starts timing out, and the load balancing data plane keeps working perfectly the whole time, which is exactly why nobody suspects the controller.
Supervisor functions that break when the load balancer runs short
Here is the artifact worth returning to, and the reason this Part exists. Objective 3.1 asks about implication, which means Broadcom wants you to reason from a shortfall to a symptom. Every row below is a Supervisor function that consumes load balancer capacity, and every symptom is one I have watched a platform team misdiagnose at least once.
| Supervisor function | What it consumes | Symptom when capacity runs out | Where to look first |
|---|---|---|---|
| Supervisor activation | One virtual server for the control plane endpoint | Enablement stalls at Configuring and never reaches Running | vCenter Workload Management status, then Edge node usage |
| vSphere Namespace creation | Network objects and, on segment networking, a tier 1 with load balancer attachment | Namespace shows created in vCenter but never becomes usable | NSX Manager alarms on the Edge cluster |
| VKS cluster provisioning | One virtual server per cluster control plane endpoint | Cluster sits in Provisioning with control plane nodes up and no reachable API server | kubectl get cluster and the virtual server list |
| Service of type LoadBalancer | One virtual server and one virtual IP each | EXTERNAL-IP stays pending and a SyncLoadBalancerFailed event repeats | kubectl describe svc on the affected Service |
| Supervisor add on services | At least one virtual server each, Harbor included | Service installs but its endpoint never publishes, so image pulls fail estate wide | Supervisor Services pane, then the service namespace |
| Cluster and Supervisor upgrades | Transient extra capacity while old and new endpoints coexist | Rolling update wedges partway with no obvious node level error | Remaining credit on the Edge node during the window |
Usage discovery and a sizing walkthrough for the reference estate
Reference estate this series has carried since Part 3 is one vCenter, one workload domain, three vSphere Zones across three clusters, NSX with VPC networking, Avi in the load balancing path and vSAN behind two storage policies. Last Part we pinned the container network interface and the trusted CA bundle. Now we count what the load balancer is being asked to carry, because a sizing answer without a current usage figure is a guess wearing a suit.
Start on the Kubernetes side, because that is where the shortfall shows up first and where you have credentials already. Read the password from an environment variable rather than typing it, on the exam and in production both.
Fourth row is the failure, and it is the one worth practising because it looks like an application problem and is not.
Nothing in that output names a size. You have to go and ask the Edge node how full it is, and this next call is the single most useful command in the whole objective. Field names in the response move between NSX releases, so read the shape rather than memorising keys.
Seventy nine percent on a large Edge node, with three zones and a documented plan to add four more VKS clusters this quarter. Each of those clusters costs one virtual server for its control plane before a single application is deployed, and the applications the platform team has queued add eleven more. That is 53 virtual servers against a ceiling this node will not reach, and the fix is not a bigger load balancer service size, it is a second pair of Edge nodes. Scaling out beats scaling up here because Edge form factor cannot be changed under a running Supervisor without a redeploy, and a redeploy of the node hosting your Supervisor endpoint is an outage.
War story, and it cost a customer a weekend. A platform team I was helping in March had a management cluster under memory pressure, so when they built the workload domain they deployed three NSX Edge nodes at medium form factor, 4 vCPU and 8 GB each, reasoning that their traffic volumes were tiny and a medium Edge would be generous. Traffic volumes were tiny. That was never the constraint. Supervisor enablement reached the point of publishing its control plane endpoint and sat there, and vCenter reported Configuring for two hours with no error worth reading. We spent another three hours chasing certificates and DNS before someone opened the Broadcom design requirement and read VCF-SUP-NLB-REQD-CFG-003, which states plainly that Edge nodes must be at least large form factor because NSX load balancers take fixed resource allocations on the Edge. Redeploying three Edge nodes at large, re-establishing the tier 0 peering and reactivating the Supervisor took nine hours end to end. Decision we reversed: we stopped sizing Edge nodes from expected throughput and started sizing them from the Supervisor requirement first, throughput second. Nobody on that team has built a medium Edge since.
One honest inconsistency to carry into the exam room rather than be surprised by. Avi product documentation names four controller sizes, Essentials, Small, Medium and Large. VCF 9.1 design library, describing the controller deployed and lifecycled by VCF Operations, lists Small, Large and X-Large instead. Both are current, they describe different deployment paths, and neither is a typo. If an item gives you controller size options, take your cue from whether the scenario deploys Avi through VCF Operations or standalone.
Exam focus for objective 3.1
Objective checkpoint
1. A workload domain runs NSX segment networking on three Edge nodes at medium form factor. Supervisor activation stalls indefinitely at Configuring. What is the most likely cause?
Answer: Edge nodes are below the minimum large form factor required for the NSX Load Balancer. Reasoning: NSX load balancers take fixed resource allocations on the Edge, and Broadcom states large as the floor for Supervisor, so no amount of traffic tuning helps.
2. An estate must front 140 Service Engines and the current Avi Controller is Small. Which change is required, and what is the operational cost?
Answer: Move to a Medium Controller, which means a redeploy. Reasoning: Small tops out at 100 Service Engines and Medium covers 100 to 200, but there is no CPU or memory hot add for the Controller, so size is not adjustable in place.
3. A team wants one load balancer to serve both Supervisor workloads and a set of traditional virtual machines, and the workload network is NSX VPC. Which model satisfies this?
Answer: Avi Load Balancer. Reasoning: NSX Load Balancer and Foundation Load Balancer are both documented as not shared with non Supervisor workloads, and Foundation Load Balancer is restricted to VLAN networking regardless.
Sizing call for this estate
For the reference estate, which is NSX VPC networking with Avi in the path, my call is a three node Avi Controller cluster at Medium with 256 GB of disk per node, and Service Engine groups scaled out rather than up. Medium costs four cores more than Small and buys a Service Engine ceiling of 200 instead of 100, which is the difference between a sizing decision you make once and a redeploy you schedule in eighteen months. Option to avoid is Essentials. It looks attractive for a lab, it caps at 100 virtual services and 10 Service Engines, and every estate I have seen start there has outgrown it inside a year with no in place upgrade path.
If you run NSX Load Balancer instead, the call is simpler and less negotiable: large Edge nodes, always, and scale out to more Edge pairs rather than trying to scale a node up. Foundation Load Balancer stays where it belongs, on VLAN networking, in a two virtual machine active and passive pair, for estates that will never grow past a handful of namespaces.
Do this tonight before you read the next Part: run the lb-node-usage call against every Edge node carrying a Supervisor, write down the virtual server count and the usage percentage, then add up the clusters and Services your roadmap says you will add in the next two quarters. If that total lands above 75 percent of current capacity, you have a design action, not a monitoring alert. Underlying component mechanics live in the VKS Series and the NSX Series if you need to go a level deeper on either.
References
- Supervisor NSX Load Balancer Model, VMware Cloud Foundation 9.0, Broadcom TechDocs
- Supervisor Foundation Load Balancer Model, VMware Cloud Foundation 9.0, Broadcom TechDocs
- Avi Load Balancer Controller Sizing, VMware Validated Solutions, Broadcom TechDocs
- Scaling Load Balancer Resources, VMware NSX, Broadcom TechDocs
About The Author
DrJha