The cluster as a concept
The word “cluster” appears in every Flui doc, command and screen. This chapter explains what Flui means by it.
What a Flui cluster is
A Flui cluster is made of:
- At least one K3s node. One master and zero or more workers.
- A private network that ties the nodes together below the public IP layer. It is the provider’s own network, or the Flui network where the servers have none.
- A firewall. It sits at the provider’s edge where the provider has one Flui can drive, and otherwise is the Flui firewall on the machines themselves. Either way the cluster gets the same rules.
- A baseline of platform components. A fixed set of cluster workloads Flui treats as part of the cluster itself: ingress, cert-manager, metrics, cluster DNS, optional authorization, and, on the control cluster, the Flui control plane.
- An identity in Flui. Every cluster has a stable UUID, a
readable name, and a
provider/regionbinding. Every provider resource that belongs to the cluster and can carry labels carries the Flui ownership labels (managed-by: flui-cloud, plus the cluster’s identifier).
The two cluster types
A Flui installation has two kinds of cluster, with different roles:
| Type | Role | What it carries |
|---|---|---|
| Control cluster | One per installation | The Flui control plane: API, dashboard, identity provider, database, queue, metrics and log stack, ingress, cert-manager. You can run apps here, but most installations keep it for the control plane. |
| Workload cluster | Zero or many | User application clusters. They run the apps you deploy plus the platform components needed to run them safely. |
Both kinds start with a single master node and can grow by adding workers. A cluster stays one logical unit even when it runs on several machines.
The multi-cluster picture is covered in Multi-cluster topology.
What a cluster exposes
You work with a cluster through a small set of surfaces you can read and act on. In the dashboard they are the tabs of the cluster’s page. The Overview summarizes most of them, each with a link to the full surface:
| Surface | What lives there |
|---|---|
| Overview | Health at a glance: nodes, average CPU and memory, firewall sync state, backups. |
| Monitoring | Live metrics and log streams for the cluster and the apps on it. |
| Network | The private network and subnets the nodes attach to. |
| Storage | The shared storage volume and the storage classes apps can use. |
| Nodes | The individual master and worker nodes, their roles and their server types. |
| Scaling | The cluster’s scaling groups, which say what the cluster may buy for itself and where it must stop: a floor, a target and a ceiling in machines; the regions and machine shapes it may choose from; how it picks between them; a spending ceiling in money; and whether it may act on its own or must ask you first. |
| Firewall | The ingress and egress rules attached to the cluster’s servers, and, apart from them, the ports your applications may reach outside the cluster (open unless you limit them; the platform’s own services are not affected). |
| DNS | The zones and records associated with the cluster, when the provider exposes DNS. |
| Variables | Cluster-scoped configuration injected into the apps that run on it. |
| Pricing | The provider-side monthly cost of every resource the cluster owns. |
Each surface has its own chapter later in the documentation. When you operate a cluster, you usually work on one surface at a time.
Scaling decides whether a cluster’s size ever changes. On a provider Flui can buy from, every cluster has a scaling group from the start, set to hold the nodes it already has, so nothing is bought or given back until somebody changes it. Raise its floor and the cluster buys a machine. Let it act on its own and it follows its load, within the bounds, places, shapes and budget the group names. On your own servers there is no group: a node joins when you attach it. See What a cluster may buy for itself.
Where this concept goes from here
- Creating a cluster: how you go from no cluster to a healthy one, step by step.
- Multi-cluster topology: one control cluster, many workload clusters, and what follows from that.
- Nodes and cluster topology: the machines a cluster is built from.
- The control cluster: what makes the control cluster different.
- What a cluster may buy for itself: the scaling group, why its ceiling is money rather than a number of machines, and why nothing scales until somebody allows it.