Skip to main content

Networking, VLAN attachment, and BGP

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, VLANs, and routed networks managed by your datacenter team. Tenants can expose services and use delegated connectivity 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​

ObjectWhat it does
Shared egress IPEvery 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 LoadBalancer Service 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.
Kube-DC VLAN allocation table showing physical segments delegated to an Organization and assigned to Projects
Platform operators delegate physical segments to an Organization; its administrators can then assign or reassign those allocations to Projects without changing the underlying fabric.
Datacenter VLAN allocation and assignmentA platform administrator allocates VLAN 4014 to Organization acme. An Organization administrator assigns the allocated segment to Project production. The Organization administrator can later unassign that Project attachment and assign the same Organization-owned segment to Project staging.assignPHYSICAL SEGMENT DELEGATIONPlatform adminallocatesVLAN 4014physicalsegmentOrganizationacme ownsallocationProject attachmentproductionreversible
Platform administrators allocate a physical segment to an Organization; Organization administrators then attach, detach, and later reattach that allocation to one of their Projects.

Routed networks: BGP into existing routing domains​

Where platform nodes can reach an external router or firewall, Kube-DC can attach selected project VPCs to an operator-defined routed network. Managed gateway replicas establish eBGP, advertise only project CIDRs, and accept only prefixes approved by your platform team. Organization administrators attach a delegated routed network; peers, ASNs, and route policy remain platform-owned.

Project VPC connected to an approved remote network with BGPWorkloads in Project production use VPC 10.0.0.0/24. The Project VPC router sends approved remote destinations through two managed routing gateway replicas in active and standby mode. Those gateways exchange the Project CIDR and approved prefix 198.51.100.0/24 over eBGP with an external router or firewall. Other traffic continues through the Project's existing default gateway to the Internet. If no managed gateway has a healthy approved route, remote-destination traffic fails closed instead of falling through to the Internet path.eBGPapproved routePROJECT VPC TO AN APPROVED REMOTE NETWORKPROJECT PRODUCTION · VPC 10.0.0.0/24KUBE-DC ROUTINGROUTED DOMAINWorkloadsPods + VMsVPC routerapproved routesdefault separateBGP pairtwo replicasactive · standbyEdge peerrouter / FWmanaged policyRemote CIDR198.51.100.0/24Default pathexisting gatewayInternetSNAT unchangedSeparate paths by destinationApproved remote destinations fail closed; other traffic keeps the default Internet path.
A whole Project VPC—not a second workload interface—reaches only operator-approved remote prefixes through redundant managed gateways. BGP remains platform-managed, while the Project's default Internet path stays unchanged.
  • Two gateway replicas provide active/standby forwarding and failover.
  • Route maps, maximum-prefix limits, default-route rejection, and optional peer authentication bound what can enter or leave the platform.
  • If no healthy gateway has an approved route, that destination fails closed; the project's normal Internet egress remains separate.

BGP connectivity is enabled and qualified per deployment because transit VLANs, addressing, timers, and external-router behavior belong to the datacenter network design.

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​

ConcernYour platform teamTenant
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 poolPool delegation✅ self-service within pool
BGP peers, approved prefixes and transit network✅attaches delegated routed networks
DNS for published hostnamesPlatform zone provided✅ own domains via CNAME