Concepts & architecture¶

This page explains the moving parts of zPodFactory and how a zPod is laid out, so the rest of the documentation reads easily.

Glossary¶

Architecture¶

zPodFactory is built upon the following various opensource projects:

The project is composed of the following sub-projects:

• zPod API: The zPod API is the core component of the project. It's the main entry point to interact with the project. It's a REST API that exposes the main functionalities of the project. It's the only component that is publicly exposed. It is the central component that controls and orchestrates everything in this framework. It will take care of any requests, manage and store information, and orchestrate/schedule flows onto the zPod Engine for execution.

• zPod SDK: The zPod SDK is generated from the FastAPI OpenAPI JSON schema. It's a Python SDK that allows clients to interact with the API without using pure REST API calls.

• zPod CLI: The zPod CLI is a wrapper around the zPod API which is used to manage, configure and operate everything required to run zPods. It is based on the Typer framework.
• zpodweb: The official Web UI for zPodFactory. Deployed automatically with the appliance on port 8500, it provides dashboards, zPod management, network topology diagrams, and visual administration of components, profiles, endpoints, and settings. See the Web UI guide.
• zPod Engine: The zPod Engine is the core component responsible for the deployment of the nested environment. It uses the Prefect workflow orchestration engine to handle scheduling and execution of all flows and their child tasks.
• zPod Library: This is a storage location that encompasses the zPodLibrary component metadata and downloaded templates/binaries. These files will be managed by the embedded download engine.

Everything runs in Docker containers, through a Docker Compose application stack.

Layers¶

A zPod is built in layers, nested inside each other:

• Physical hosting environment (blue): the vSphere, NSX and storage zPods are deployed on, an endpoint. Each zPod gets its own NSX T1, connected to the endpoint's T0, and an overlay segment that trunks every VLAN.
• Layer 1 VMs (orange), managed by zPodFactory: the VMs it deploys on the endpoint, in a vApp named after the zPod. zcore (.2) is the zPod's core appliance: DNS and DHCP, the NFS filer for the nested hosts, routing of the tagged VLANs, and zboxapi. The ESXi hosts (.11 and up) are the nested hypervisors.
• Layer 2 VMs (green), managed by the zPod owner: what runs on the nested hosts, usually a nested vCenter (.10) with NSX, VCD, Aria and so on, plus anything the owner builds: overlay networks, edges, their own VMs.

The zPod owner has full control inside their zPod, since its password is the admin password of every component, while the zPod's networking keeps each zPod isolated from the others and from the physical environment. Breaking a zPod never affects the rest of the lab.

NSX networking¶

Every zPod gets its own NSX T1, connected to the endpoint's T0, and its own Geneve segment, an 802.1Q trunk carrying the native VLAN untagged and VLANs 0–4094 tagged. The zPodFactory appliance sits on its own management network.

How the T1 is laid out depends on the endpoint's network driver:

• nsxt (recommended): one T1 per zPod, named after it, such as zPod-c-tier1 (zPod c in the diagram). This is the driver most deployments use.
• nsxt_projects: extended capabilities on top of nsxt. Each zPod gets its own NSX Project, for multi-tenancy, and zPods attached to an ENet share one project and its T1, each with its own segment (zPods a and b). Projects need NSX 4.1.1 or later. This driver has not been tested recently, so it is not recommended for new endpoints.

Routing is kept under control by three guardrails, numbered in the diagram:

1. Only each zPod's /24 reaches the T0: the native /26 lives on the T1, and VLANs 64, 128 and 192 are routed to zcore by T1 static routes. zPodFactory sets them; users cannot change them.
2. zPod owners add their own VLANs on zcore. They stay inside the zPod (with masquerade for egress) unless a superadmin advertises them: zPodFactory checks the whole fabric for overlaps first, then adds a T1 static route to zcore. See Networks.
3. On nsxt_projects endpoints, the project boundary isolates each zPod, or each ENet, from the others.

zPod networks¶

Each zPod gets one /24 from the endpoint's supernet, carved into four /26 networks. For a zPod test with 10.96.42.0/24:

All four are advertised upstream through the T0. The tagged VLANs make it easy to put nested host TEPs, edge TEPs or uplinks on separate networks. zcore also carries VLANs 10, 20 and 30 (172.16.10/20/30.0/24) for nested VCF.

Beyond these, a zPod owner can add their own VLAN networks on zcore, optionally with egress, and a superadmin can advertise them to the NSX fabric. See Networks.

A zPod as a physical rack¶

A zPod behaves like a physical rack you own, which makes it a good place to design, test or learn a datacenter architecture:

What runs on the hosts, how the VLANs are used, and which storage is added is up to the zPod owner, without touching the rest of the lab.