Skip to content
flui.cloud

VNets and subnets, abstracted

Every cloud that offers private networking models the concept its own way: different names, different scoping rules, different granularity. Flui’s job is to give the cluster a coherent “private network with one or more subnets” view regardless of what the provider underneath is happy to call it.

This is one of the most concrete examples of the abstraction described in How Flui works across providers, and it is where the rest of the platform stops caring about provider-specific networking terminology.

The Flui-side model

In Flui terms, a cluster’s private network has just two ideas:

  • A VNet — a private address space (an IP range) reserved for the installation.
  • One or more subnets inside the VNet — each with its own IP range, into which nodes are placed.

That is the whole vocabulary. Nodes are attached to a subnet at creation time and receive a private address inside it; everything that needs to talk over the private network speaks through those addresses.

Where providers disagree — on how the geographic scope is named, on whether multiple subnets per network are a thing — Flui normalises into this same shape. The rest of the platform reads the same fields regardless of which cloud is underneath.

One VNet per installation

Flui provisions one VNet per installation, shared by the control cluster and every workload cluster the installation creates. The reason is straightforward: a single fast, private environment is what makes the control cluster and the workload clusters talk to each other with low latency, and what makes nodes within the same cluster talk to each other without ever touching the public internet. One VNet across the whole installation is the simplest shape that gives both of those properties at once.

Clusters in the same installation share the VNet and reach each other on their private interfaces; the provider firewall only filters the public perimeter, not this private traffic.

This shape follows naturally from the single-provider-per-installation choice covered in Multi-cluster topology: if every cluster lives on the same provider, sharing one VNet is the obvious move.

Default IP ranges

A fresh installation comes up with a default private range for the VNet and a default range for its first subnet. They are sized generously enough that you do not have to think about them, and because they are private addresses inside a single installation they do not collide with anything outside it.

If you need to override them, the values are configurable through environment variables read at bootstrap; the reference is in CLI: Environment variables.

What a node gets when it joins a cluster

When a node is created, the provider gives it two addresses:

  • A public address on the provider’s external network — used by the cluster’s ingress (HTTP/HTTPS for applications) and by the operator’s SSH access from outside.
  • A private address on the VNet’s subnet — used for everything intra-cluster and intra-installation: node-to-node, agents pushing to the central observability backend, the control plane reaching into a workload cluster.

The two addresses have distinct purposes: the public one carries the traffic that has to come from outside, the private one carries everything that stays inside the installation. They are not alternatives — each handles its own kind of traffic.

Where this chapter goes from here