Cluster as a concept
The word “cluster” appears in every Flui doc, command and screen. This chapter pins down what Flui means by it.
What a Flui cluster is
A Flui cluster is the union of:
- At least one K3s node — one master, zero or more workers.
- A private network that ties the nodes together below the public IP layer.
- A firewall (when the provider supports one) restricting ingress to the master’s Kubernetes API and the ingress controller.
- A platform-components baseline — a fixed set of cluster workloads Flui considers part of the cluster itself: ingress, cert-manager, metrics, cluster DNS, optional authorization, and on the control cluster also the Flui control plane.
- A Flui-side identity — every cluster has a stable UUID, a
human-friendly name, and a
provider/regionbinding. Every provider resource that belongs to the cluster carries the Flui ownership labels (managed-by: flui-cloud, plus the cluster’s identifier).
That last item is the bright line. A K3s cluster you set up by hand on your own laptop — even if it works — is not a Flui cluster. Flui identifies its own clusters through those labels on every server, SSH key, firewall, private network and DNS record it provisions. Operations that delete or modify provider resources check the labels first; resources without them are off-limits.
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. App workloads are not forbidden here, but most installations keep it focused. |
| 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 is one logical thing, even when it runs on several machines.
The multi-cluster picture is covered in Multi-cluster topology.
What a cluster exposes
A cluster is not a single thing you interact with — it is a small set of dimensions you can read and act on. Each one is a surface in its own right:
| 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. |
| Autoscaling | Rules that add or remove workers in response to load. |
| Firewall | The ingress and egress rules attached to the cluster’s servers. |
| 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 further down the documentation. What matters here is that a cluster is the sum of these surfaces — when you operate one, you are usually operating one dimension at a time.
Where this concept goes from here
- Creating a cluster — the journey from “no cluster” to a healthy one, step by step.
- Multi-cluster topology — one control cluster, many workload clusters, and the consequences.
- Nodes and cluster topology — the cluster’s atoms.
- The control cluster — what makes the control cluster special.