Networking and VLAN attachment
Give each project an isolated VPC, with controlled paths to public services and existing datacenter networks.
Kube-DC creates a VPC for each project and connects it to the uplinks, address space, and VLANs managed by your datacenter team. Tenants can expose services without gaining control of the underlying network fabric.
Per-project VPCs
Every project receives its own VPC and private subnet at creation. The software-defined network does not configure private routes between projects by default. A service becomes reachable from another project only when it is deliberately exposed or the operator adds a route. Pods, VMs, and managed-cluster workers in the same project share the project network and can reach one another directly.
Address model
| Object | What it does |
|---|---|
| Shared egress IP | Every project gets outbound connectivity through a shared external address |
| External IP (EIp) | A dedicated external address, allocated automatically per LoadBalancer service or explicitly for a purpose |
| Floating IP (FIp) | Maps an external address to an individual VM — inbound and outbound — without a load balancer |
Address pools are defined by the platform team from your ranges; tenants consume them within quota.
Exposing services
Two documented paths, chosen per service:
- HTTPS route (recommended for web/API/gRPC): one annotation on a
LoadBalancerService publishes it at a hostname with a TLS certificate issued by the platform's configured issuer — no ingress controller for tenants to run, no certificate handling. Uses the platform's gateway, your routable address pools and DNS. - Direct LoadBalancer (any TCP/UDP): the Service receives a dedicated external IP for protocols and ports beyond HTTP.
Managed-cluster API endpoints follow the same model: private in-VPC by default, public HTTPS through the platform gateway on request.
VLAN attachment: layer-2 into your datacenter
Where the datacenter fabric trunks delegated VLANs to the platform nodes and the operator configures the bridge and VLAN pools, a project's network can be bridged onto an existing datacenter VLAN.
- Per-organization VLAN pools: the platform team delegates ranges of VLAN IDs to organizations; tenants allocate segments from their pool self-service, without tickets and without being able to touch another organization's VLANs.
- Workloads — VMs and pods — gain a leg on the physical segment: lab instruments, storage networks, legacy systems, partner links, anything that expects layer-2 adjacency.
- Addressing on the attached segment is yours: static, your DHCP, or platform-managed.

Traffic control
- Egress restrictions and allowlists are operator-configured platform controls — tenants request exceptions; the platform team owns the policy.
- Network boundaries are a property of the VPC layer: they are not tenant-configurable objects inside a project.
- North-south exposure happens through the objects above — an address or route a tenant deliberately created.
Responsibilities
| Concern | Your platform team | Tenant |
|---|---|---|
| Fabric, uplinks, address ranges, VLAN delegation | ✅ | — |
| VPC creation and isolation | ✅ automatic | — |
| Egress policy and allowlists | ✅ | requests exceptions |
| Service exposure (LBs, routes, FIPs) | Mechanisms provided | ✅ configures per service |
| VLAN segment allocation from the org pool | Pool delegation | ✅ self-service within pool |
| DNS for published hostnames | Platform zone provided | ✅ own domains via CNAME |