Skip to content
flui.cloud

The network Flui builds

A provider’s private network stops at the edge of that provider. Two clusters inside it reach each other without touching the internet. A cluster at another provider cannot reach them that way.

This matters as soon as an installation uses more than one provider. The control cluster still has to reach the workload cluster’s API to deploy anything, and the workload cluster still has to send its logs and metrics back. Without a private network in common, both would have to cross the public internet. Flui builds the missing network itself.

What it is

The Flui network is an encrypted point-to-point network that Flui creates, addresses and maintains on top of whatever is underneath. Every node that joins it gets an address in a private range the installation owns. Traffic between those addresses is encrypted before it leaves the machine and decrypted after it arrives.

It works whatever lies in between. Two machines at two providers, in two countries, with nothing private between them, get private addresses that reach each other. To the platform they are neighbours.

Inside one provider the traffic never leaves the provider provider private network Private because it never reaches the internet. Between providers the traffic crosses the internet, sealed internet provider A provider B Flui network, encrypted
Inside one provider, traffic stays on the provider's private network. Between providers it has to cross the internet, so the Flui network encrypts it before it leaves the machine.

The default range is 10.250.0.0/16. Before an address is handed out, the range is checked against every other network the installation knows about, including the ranges your clusters use internally. Flui refuses a collision instead of working around it: a management address that silently shadows a route you already have tends to surface weeks later as an unrelated fault.

Who dials whom

The control cluster is the fixed point. Workload clusters dial it; it does not dial them.

A workload cluster’s address can change: providers reassign addresses, machines are replaced, a node comes back with a different public address after maintenance. The control cluster is the part of the installation Flui already treats as stable, since everything else points at it.

So the control end waits, the workload ends call in, and the control cluster learns where each one is calling from. A workload cluster that changes address reconnects on its own and keeps the same private address. No configuration has to change.

As a result, workload clusters do not reach each other over this network. Each has a path to the control cluster and none to the others. The network carries management traffic and telemetry, and your clusters stay isolated from each other.

What travels on it

Only three kinds of traffic use it:

  • Cluster management. Every deployment, status read and restart the control cluster performs against a workload cluster.
  • Logs. Every line your applications write, on its way to the installation’s log store.
  • Metrics. Every measurement the nodes and your applications produce.

Your applications’ own traffic does not use it. A request from the internet reaches your application’s cluster directly.

The exchange, in the right order

What matters most is when the public path is closed.

Before this network is in place, a cross-provider workload cluster is reachable on its public address, and the control cluster talks to it there. Closing that path as soon as a tunnel appears would be a mistake. A tunnel that has completed its handshake may still not carry traffic, and a cluster reachable at neither address is a cluster you have lost.

Flui works in this order:

  1. The tunnel is established, and the workload cluster’s identity certificate is reissued to cover its new private address.
  2. The control cluster tries the new address with a real connection that validates the certificate, not a ping.
  3. Only if that succeeds does the control cluster switch to the workload cluster’s private address.
  4. Only after the switch is the public opening withdrawn.

Each step waits for the one before it. If a step does not happen, the public path stays open and the installation keeps working while Flui tries again.

Your telemetry ports, the ones that receive logs and metrics, are reachable only over this network. They are never open on your public address, not even briefly during setup.

When it is not used

Flui routes management traffic over this network only when it has to.

Two clusters on the same provider already share that provider’s private network, which is faster and simpler than anything Flui could build. There, management traffic uses the provider’s network and the tunnel carries nothing. The tunnel is still established and maintained, so it is there if the provider’s own network is not, but traffic does not use it.

The cluster’s network view shows which case applies: a cluster reached privately through its provider and a cluster reached through the Flui network have different labels.

S Control cluster Scaleway Flui network S Scaleway 2 servers · 5 apps S Scaleway private network S Firewall at Scaleway's edge O OVHcloud 2 servers · 4 apps O OVHcloud private network Flui firewall Ubuntu servers you own 3 servers · 5 apps Flui network Flui firewall from the provider supplied by Flui a server Flui may buy when the cluster runs out of room, within your spending ceiling
The Scaleway cluster shares the control cluster's provider, so its management traffic stays on Scaleway's private network. The OVHcloud cluster and the Ubuntu servers you own are reached over the Flui network. The Ubuntu servers have no private network of their own, so there the Flui network also carries the traffic inside the cluster.

Inside a cluster too

The same mechanism covers a second case.

When you install Flui on machines you already own, those machines may have no private network between them. Two rented servers in two datacentres have public addresses and nothing else, so traffic between the parts of your cluster would cross the internet unencrypted.

Flui builds a network for them with the same mechanism, and the cluster binds to it. Your applications’ internal traffic (one component calling another, a service reaching its database) travels encrypted between machines that have no private network of their own.

VNets and subnets, abstracted describes this case as a network Flui provides instead of one a provider hands over. Between clusters, the Flui network connects clusters that have no path to each other. Inside a cluster, it gives the cluster the private network its provider does not offer.

What you have to do

Nothing. There is no command to create this network, no setting to enable it and no address to choose. Flui establishes it when a cluster is created, repairs it when a machine is replaced and takes it down when a cluster is destroyed.

It also survives a reboot. A machine that restarts comes back with the same private address and rejoins on its own.

What to look at when something is wrong

The network is rarely the cause. If a workload cluster stops reporting, start with the usual checks: the cluster’s status, its nodes, and whether its firewall still has the rules Flui put there.

Flui reconciles on a cycle. A cluster created a minute ago may not have joined yet, and a cluster whose address just changed may take a pass or two to settle. Both correct themselves. Wait ten minutes before treating a gap as a fault.

A cluster can be healthy and silent at the same time. A working network means the two ends can reach each other. It does not mean your logs are arriving, which also depends on the cluster’s own telemetry configuration. Check the cluster’s Monitoring and Logs views. If the connection is up but no data arrives, look at telemetry, not the network.

Where this chapter goes from here