Management and Workload Clusters

With Syself Autopilot you manage your clusters through the management cluster: Syself's control surface, and the one piece Syself runs and hosts for you. It exposes a Kubernetes API, so you declare the cluster you want the same way you declare any Kubernetes object, using the kubectl and GitOps you already know.

The workload cluster is what Syself builds from that declaration: a complete Kubernetes cluster on your own Hetzner servers, with its own control plane and its own worker nodes. Your applications run here, and your kubectl talks straight to it, like any Kubernetes cluster you have used before. (Inside a workload cluster shows what runs in one.)

You declare, Syself builds#

The object defines the cluster you want: its Kubernetes version, how many nodes, which machine types, and which region. Syself's controllers read it and build a matching workload cluster on your Hetzner servers, then keep it that way: when a machine fails they replace it, and when you change the object they roll out the change. How that reconciling works is declarative cluster management .

So you work in two places, depending on what you want to change:

• To change the shape of the cluster, its version, node counts, machine types, or region, you edit the object on the management cluster.
• To change what runs inside the cluster, your applications, you use the workload cluster's own API, exactly like any Kubernetes cluster.

flowchart LR
  YOU["You"]
  subgraph MC["Management cluster: Syself runs this"]
    D["The object:<br/>your cluster's shape"]
    C["Syself's controllers:<br/>build, heal, upgrade"]
    D --> C
  end
  subgraph WC["Workload cluster: yours, on your servers"]
    CP["Control plane"]
    W["Worker nodes: your apps"]
  end
  YOU -->|"edit the object"| D
  YOU -->|"deploy apps"| WC
  C -->|"builds and keeps it running"| WC

Your workload cluster stands on its own#

Your workload cluster runs its own control plane, etcd, networking, and storage on your own Hetzner servers. It does not depend on the management cluster to keep running.

It serves traffic, schedules pods, and answers your kubectl whether or not the management cluster is reachable. If the management cluster goes down for maintenance or loses its network, your applications keep serving. What pauses is the automation: building or scaling nodes, upgrades, and automatically replacing a failed machine. All of that resumes once the management cluster is back.

So a problem in Syself's operations layer never takes your applications down; at most, it delays a change until the layer is back.