VNets and subnets, abstracted
Every cloud that offers private networking models it its own way, with different names, scoping rules and granularity. Flui gives the cluster one consistent view, a private network with one or more subnets, whatever the provider underneath calls it.
This is one of the clearest examples of the abstraction described in How Flui works across providers. Above this layer, the rest of the platform does not deal with provider-specific networking terms.
The Flui-side model
In Flui terms, a cluster’s private network has two parts:
- 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.
Nodes are attached to a subnet at creation time and receive a private address inside it. Everything that talks over the private network uses those addresses.
Where providers differ (in how the geographic scope is named, or in whether a network can have several subnets), Flui normalises them into this same shape, so the rest of the platform reads the same fields on any cloud.
One VNet per installation and provider
Flui provisions one VNet per installation and provider, shared by the control cluster and every workload cluster on that provider. A single private network lets the control cluster and the workload clusters talk to each other with low latency, and lets nodes in the same cluster talk to each other without touching the public internet. One VNet per provider is the simplest shape that gives both.
Clusters on the same provider share that VNet, and the same
subnet, and reach each other on their private interfaces. The
provider firewall filters only the public perimeter, not this
private traffic. A cluster on another provider reaches the
control cluster over the Flui network instead (see
Multi-cluster topology).
The private network is enforced: on a provider that requires
one, creating a cluster without a private network is rejected
with the code VNET_REQUIRED. The rest of the platform can
therefore rely on the shared VNet being there.
All of that assumes a provider with a private network to give. When the machine is your own there is none, and the shape changes; see When the server is your own.
Default IP ranges
A fresh installation uses 10.10.0.0/16 for the VNet and
10.10.1.0/24 for its subnet. They are large 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. They are not configurable.
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 inside the cluster and the installation: node-to-node traffic, agents pushing to the central observability backend, and the control plane reaching into a workload cluster.
The public address carries the traffic that has to come from outside, and the private one carries everything that stays inside the installation.
The cluster’s own control API is a good example. It listens on port 6443, but that port is never reachable from the public internet. When Flui records how to reach a cluster, it writes the master’s private VNet address as the API endpoint, so every control-plane operation against a workload cluster crosses the VNet instead of the open internet. The matching firewall rule keeps 6443 closed at the public perimeter and scoped to the subnet; see Firewalls.
When the server is your own
Everything above assumes a provider that has private networks to create. With your own server there is nothing to create: no network API, no address space to reserve, nothing to divide into subnets. The machine sits on whatever network you put it on, which may be no private network at all.
So Flui builds one: the Flui network, encrypted, created for the installation and given to the cluster. Flui does not derive it from the machine’s own address. The network Flui builds describes the mechanism; this section covers what it means for the model above.
An address on a machine tells you what that machine can reach, not what your machines have in common. On a host that runs containers it can even be a container bridge instead of a network two servers share. When Flui builds the network itself, it knows its shape.
In this case, three points from earlier in the chapter change.
One network for the installation, one subnet per cluster. The subnet is the isolation boundary: the machines of a cluster reach each other and the control cluster, and nothing else. A cluster cannot choose its subnet, because two clusters sharing one would silently be able to see each other.
The range is the installation’s. It is 10.250.0.0/16,
divided one /24 at a time. Before an address is handed out, it
is checked against every other network the installation knows
about, and a collision is refused rather than worked around (see
The network Flui builds).
Nothing filters at a provider edge. There is no managed
firewall in front of the machine, so the rules are applied on
the machine itself, and everything is closed unless a rule opens
it. Web traffic on 80 and 443, and SSH for you, stay public.
Traffic between the machines is accepted only over the network
Flui built, never from a public address, so a machine that has
not joined that network yet is not reachable by the others. That
is the safe way for that state to fail. flui env firewall status
shows what is applied on the host, and flui env firewall apply
puts it back.
On a single machine with a single address, the public and private pair described above becomes one address doing both jobs. That is normal here and not a misconfiguration.
Where this chapter goes from here
- Firewalls: what enforces isolation inside a shared VNet.
- How Flui works across providers: the broader abstraction this chapter is an example of.
- Creating a cluster from zero: when the VNet is set up during cluster creation.
- The network Flui builds: what happens when the provider has no private network to give, or when two clusters have none in common.