Academy/VCAP — VCF VKS (3V0-24.25)/LoadBalancer Service & Avi ALB Integration
This lab targets VCF 9.0

LoadBalancer Service & Avi ALB Integration

VCF 9.0Intermediatevcap-advanced⏱ 120 min

Objectives

  • Expose application via Kubernetes LoadBalancer service; verify Avi virtual service creation.

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for Advanced VCF 9.0 VKS (vSphere Kubernetes Service)

Tasks

Task 1 LoadBalancer Service & Avi ALB Integration

Expose application via Kubernetes LoadBalancer service; verify Avi virtual service creation.

Step 1

Deploy multi-replica application (e.g., nginx).

Step 2

Create Service type=LoadBalancer: kubectl expose deployment nginx --type=LoadBalancer --port=80 --target-port=8080

Step 3

Monitor ALB integration: In Avi UI, verify virtual service auto-created with pool members (pod IPs).

Step 4

Allocate VIP from NSX subnet; verify route advertised via Tier-0 BGP.

Step 5

Test external access: curl ; curl /health Confirm load balancing across pod replicas.

Step 6

Scale deployment: kubectl scale deployment nginx --replicas=5 Verify ALB pool auto-updates.

Step 7

Delete service; confirm ALB virtual service cleanup.

Step 8

Document VIP allocation process, BGP advertisement, and pool management workflow.

Validation Gate

Check: Verify lab completion

Expected: Lab exercise completed successfully

Common Errors

Avi Service Engine not deployed in the correct network segment
Fix: Avi Service Engines must be on a network segment reachable by both the Kubernetes pods and external clients. Misconfigured SE placement causes: pods can reach the VIP but external clients cannot, or vice versa. Verify SE placement network matches the front-end (client-facing) and back-end (pod-facing) connectivity requirements.
LoadBalancer service stuck in 'Pending' state
Fix: A Kubernetes LoadBalancer service in 'Pending' means the LB controller hasn't provisioned a VIP. Common causes: Avi Controller unreachable from Supervisor, IP pool exhausted (no available VIPs), or AKO (Avi Kubernetes Operator) not running. Check AKO pod logs: kubectl logs -n avi-system deployment/ako.
Not configuring health monitors for backend pools
Fix: Without health monitors, Avi sends traffic to unhealthy pods until Kubernetes marks them as NotReady (which can take 30+ seconds). Configure Avi health monitors (HTTP or TCP) with 3-second intervals for faster failure detection.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

Load balancer integration demonstrates application delivery architecture. VCDX panelists test Avi SE placement, VIP allocation, and health monitoring design.

⚠ Known Pitfalls (from Community KB)

Not checking AKO pod logs when LoadBalancer services are stuck in Pending — the answer is always in the AKO logs.
Forgetting health monitors — traffic goes to unhealthy pods for 30+ seconds.
Was this page useful?
Type to search. ↑ ↓ to move, Enter to open, Esc to close.