Ingress and egress are not one decision with two names. They are two address planes, owned by different objects, failing in different ways, and audited by different teams, and Objective 3.3 separates them on purpose. A candidate who has only ever ticked boxes in the namespace creation wizard will lose points here, because almost all of the evaluation happened at Supervisor enablement, weeks before any namespace existed.

Ingress and egress as two separate address planes

Most people learn ingress first because it is visible. Someone deploys a Service of type LoadBalancer, an address appears in the EXTERNAL-IP column, a browser reaches the application, and that feels like the whole networking story. Egress is invisible by design. A pod opens a connection to an Oracle listener or a corporate proxy, something rewrites the source address on the way out, and nothing in the pod ever knows. Both planes draw from address ranges you sized once, but they scale on completely different multipliers.

Ingress scales with exposed Services. Twelve namespaces running two exposed Services each consume twenty four addresses, and a team that discovers Ingress objects and starts fronting six applications behind one controller drops that number back to twelve. Ingress consumption is elastic and it responds to application design. Egress scales with namespaces, and on NSX segment networking the default is one SNAT address per namespace whether that namespace runs one pod or four hundred. Egress consumption is rigid and it responds only to how many tenants you onboard.

That asymmetry is the whole objective in one sentence. Study material tends to treat the ingress range as the important one because it is the one people run out of in a lab where every demo is a LoadBalancer Service. On a production estate with tenant onboarding as the growth driver, egress is what pins you, and egress is also what your security team keeps in a firewall rule, which means changing it is a change ticket rather than a config edit. Evaluate the two planes with different questions: for ingress, ask how many applications will be exposed and whether anyone will consolidate behind Ingress objects; for egress, ask how many tenants you will onboard in three years and whether each one truly needs a distinct source address.

One naming note that will follow you through Broadcom documentation and CLI output. VKS is the product formerly called TKG Service or TKGS, and the rename is not finished in the plumbing. Namespace and cluster objects, API groups and log paths still carry tkg in many places, so a resource name with tkg in it is not evidence that you are looking at an old product.

flowchart LR
  subgraph IN [Ingress plane, scales with exposed Services]
    A[Client on enterprise network] --> B[Virtual IP from ingress pool]
    B --> C[LoadBalancer Service or Ingress object]
    C --> D[Pod or node endpoint]
  end
  subgraph OUT [Egress plane, scales with namespaces]
    E[Pod in vSphere Namespace] --> F[SNAT rule on the namespace gateway]
    F --> G[Source address from egress pool]
    G --> H[Database or proxy outside the Supervisor]
  end

Namespace exposure paths by networking mode

Part 12 established that a namespace inherits its network model from the Supervisor rather than choosing one. This table is the consequence of that inheritance, expressed as exposure paths instead of models. Keep it next to your design document, because every row is a question a reviewer will eventually ask you, and the last column is the one that decides whether an answer costs a config change or a rebuild.

Two rows in that table carry most of the design weight. Row four is why people choose NSX in the first place, because a distinct source address per namespace is what makes a firewall rule per tenant possible at all. Row seven is why people regret their first Supervisor, because on segment networking the ranges that feed rows one and three are frozen the moment enablement completes. If you want the mechanics of tier 0, tier 1 and project scoping rather than the Supervisor view of them, the NSX series owns that ground and this series does not repeat it.

Egress identity and SNAT address sharing

Egress identity means one thing to a platform engineer and something else to a security engineer, and Objective 3.3 sits exactly on that seam. To a platform engineer it means outbound connectivity works. To a security engineer it means a log line at the perimeter can be attributed to one tenant without asking anyone. NSX segment networking gives you the second interpretation for free by handing every namespace its own SNAT address, and that generosity is precisely what burns through an egress CIDR.

NSX VPC networking changes the shape of that trade. Broadcom documents three subnet access modes inside a VPC: Private subnets, which are the default and are reachable only inside the VPC; External subnets, which draw public or externally routed addresses from the project external IP block and serve LoadBalancer Services, Ingress and the egress of the NSX project; and Private Transit Gateway subnets, which are reachable by workloads in other VPCs inside the same project and which back SNAT on egress of the VPC and for vSphere Pods. NCP builds a VPC for system namespaces in the NSX system project, a separate VPC for Supervisor Services, and an individual VPC per vSphere Namespace whenever a VPC was not supplied at workload domain creation. Read that carefully, because it means the per namespace identity you wanted on segment networking arrives on VPC networking as a routing domain rather than as an address, and a routing domain costs nothing from your routable block.

Before you evaluate any of this on your own estate, pin down what you are actually running. Design questions on this exam are answered against a stated configuration, and the same is true of a real design review.

Now the failure that teaches the objective. On a lab Supervisor built with NSX segment networking and a deliberately mean ingress CIDR, I created namespaces until the pool was gone and then asked for one more exposed Service.

Two things about that output matter for the exam. First, EXTERNAL-IP sitting at pending forever is an allocation failure, not a health failure, and it never resolves on its own. Second, the Reason string SyncLoadBalancerFailed comes from upstream Kubernetes, while the tail of the Message is written by NCP or AKO and its exact wording moves between builds, so memorise the Reason and treat the Message as a hint. Trace it back the way this series always does: the object that failed is a Service in a namespace, but the object that caused the failure is the Supervisor, because the ingress CIDR was set at enablement and no namespace can widen it.

Address budget arithmetic on the reference estate

Design arguments about ingress and egress collapse into agreement the moment somebody counts. So I counted. Same reference estate, same twelve namespaces, two LoadBalancer Services in each, rebuilt four ways, and I recorded only one number: how many externally routable addresses the estate consumed once everything was green.

Ingress is a constant twenty four in all four rows because two exposed Services per namespace is two exposed Services per namespace regardless of who allocates the address. Everything that moves in that chart is egress, and it moves in units of one per namespace. Put that against a realistic range and the arithmetic gets uncomfortable fast. A slash 27 egress CIDR carries thirty two addresses, of which roughly thirty are usable once the range is realised, so a slash 27 caps you near thirty namespaces on segment networking no matter how generous your ingress range is. A slash 26 doubles that to about sixty two. Nobody thinks of the smaller field as the limiting one, and that is exactly why it limits people.

Zonal deployments add a second kind of arithmetic that candidates confuse with this one. Broadcom documents that namespace resources on a three zone Supervisor are drawn from all three underlying vSphere clusters in equal parts, so dedicating 300 MHz of CPU takes 100 MHz from each cluster. That splitting applies to compute, not to addresses. A namespace on a three zone Supervisor still consumes one egress address, not three. Exam items like putting those two facts next to each other and seeing whether you multiply the wrong one.

Here is where the popular advice is wrong. Nearly every walkthrough tells you to give each namespace its own routable egress address so security can attribute outbound traffic, and that advice made sense when segment networking was the only NSX option. On VPC networking it is the expensive default. Put namespace egress on a Private Transit Gateway subnet, let the VPC boundary carry tenant identity, and do attribution at the centralised transit gateway where you have the VPC context anyway. Same audit answer, twelve fewer routable addresses in my test, and an address block you can hand back to the network team.

Exam focus for objective 3.3

Objective checkpoint

Ingress and egress call for this estate

My pick for the reference estate is NSX VPC networking, with External subnets used only where something is genuinely published to the enterprise and Private Transit Gateway subnets carrying namespace to namespace traffic and VPC egress. Tenant identity comes from the VPC boundary rather than from a routable address, which is the same audit story at lower address cost, and the connectivity profile and IP blocks stay editable at project level instead of freezing at Supervisor enablement. What I would avoid on a greenfield build is NSX segment networking chosen out of familiarity, because it hands you a distinct egress address per namespace that feels like a feature right up to the day the CIDR runs dry and the repair is a rebuild. If you are on vSphere networking with Avi and cannot move yet, accept that you have no per namespace source identity and solve attribution with policy and logging instead of pretending the address plane will give it to you.

Tonight, in your own lab, do one thing: count. Write down your ingress range, your egress range, your current namespace count and your current count of exposed Services, then divide. If either quotient says you have fewer than two years of headroom at your real onboarding rate, you have found the design decision this objective is actually about, and you have found it while it is still a spreadsheet rather than a rebuild. Readers who want the product level walkthrough underneath all of this rather than the exam view of it should sit the VKS complete guide alongside this series, and anyone who arrived here from a Tanzu Kubernetes Grid Integrated estate should read the TKGI to VKS guide first, because migration reshapes an address plan in ways an exam never will. Part 14 walks the enablement process itself, which is where every range discussed here gets committed.

References

• Supervisor Architecture with VCF Networking with VPC, VMware Cloud Foundation 9.0, Broadcom TechDocs
• Configuring and Managing vSphere Namespaces, VMware Cloud Foundation 9.0, Broadcom TechDocs
• VMware Cloud Foundation VKS Administrator Exam Guide, 3V0-24.25, Broadcom

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts