Skip to content

Networks and Subnets

Use Networks and Subnets to model your network layout in meltcloud.

Your network team designs the actual segments and configures the network fabric; you model Networks and Subnets in meltcloud, so Machines that are assigned to Subnets (using Network Profiles) configure their interfaces according to the Subnet's settings.

A Network is one logical network, such as a VPC or a VRF. Examples: prod, staging, management, storage.

A Subnet is one segment of a Network. For example, prod-az1, prod-az2 etc. It defines how Machines get an address on it (DHCP or IPAM) and further network configuration (DNS servers, NTP servers, MTU, routes, ...)

Common layouts

In the wild, data center networks usually fall into one of the following categories. Which one you have is usually decided by your network team, long before Kubernetes arrives, so the job here is to recognize yours and model it using Networks and Subnets.

Stretched L2

Stretched L2

This is mostly found in traditional Virtualization-heavy data centers, where L2 needs to span sites, since VMs can be moved between them.

Because both sites shared the same networking settings, you can use a single Network and Subnet for Machines in both sites:

NetworkSubnetCIDRVLANNetwork ProfileMachines
wl-prdwl-prd10.0.10.0/2410prdmachine-prd-az1
machine-prd-az2

If your layout requires multiple Networks, you can of course create further Networks:

Example: Workload and storage networks

NetworkSubnetCIDRVLANNetwork ProfileMachines
workloadworkload10.0.10.0/2410prdmachine-prd-az1
machine-prd-az2
storagestorage10.0.20.0/2420prdmachine-prd-az1
machine-prd-az2

Example: Production and staging networks

NetworkSubnetCIDRVLANNetwork ProfileMachines
prdprd10.0.10.0/2410prdmachine-prd-az1
machine-prd-az2
stgstg10.0.30.0/2430stgmachine-stg-az1
machine-stg-az2

The common attribute of this layout is that Machines on both sites use the same network configuration, so they can use the same single Network Profile, Subnet and Networks.

As Terraform: stretched L2.

Subnet per rack or zone

Subnet per rack

Newer data centers built for container platforms tend to be modelled the way the public clouds are: each rack or availability zone is a failure domain of its own, with its own VLAN and prefix and the fabric routes between them.

For you, this means that Machines in different racks or sites need different network configuration, and thus different Network Profiles, Networks and Subnets.

NetworkSubnetCIDRVLANNetwork ProfileMachines
wl-prdwl-prd-az110.0.10.0/2410prd-az1machine-prd-az1
wl-prdwl-prd-az210.0.20.0/2420prd-az2machine-prd-az2

It's of course also possible to have further Networks:

Example: Workload and storage networks

NetworkSubnetCIDRVLANNetwork ProfileMachines
workloadworkload-az110.0.10.0/2410prd-az1machine-prd-az1
workloadworkload-az210.0.20.0/2420prd-az2machine-prd-az2
storagestorage-az110.0.30.0/2430prd-az1machine-prd-az1
storagestorage-az210.0.40.0/2440prd-az2machine-prd-az2

Example: Production and staging networks

NetworkSubnetCIDRVLANNetwork ProfileMachines
prdprd-az110.0.10.0/2410prd-az1machine-prd-az1
prdprd-az210.0.20.0/2420prd-az2machine-prd-az2
stgstg-az110.0.30.0/2430stg-az1machine-stg-az1
stgstg-az210.0.40.0/2440stg-az2machine-stg-az2

As Terraform: subnet per rack or zone.

Routed to the host

Routed to the host

In some modern setups, routing is extended all the way down to the host: each Machine peers with its leaf switch over BGP.

WARNING

This layout is currently not supported. Reach out to us if you need it.


Next, see how a Machine gets its network configuration from a Subnet in Subnet Addressing.