Inside a Workload Cluster
A workload cluster runs your applications on your own Hetzner servers. This page shows what is inside one: what runs on a control-plane node, what runs on a worker, and how the parts connect. The split between this cluster and the management cluster Syself runs is covered in Management and workload clusters ; here we look inside the workload cluster itself.
Most of what runs here is standard upstream Kubernetes. Syself adds a few of its own pieces and arranges them so the cluster is safe on the public internet with no private network . Each piece is explained in depth on its own page, linked below.
flowchart LR
YOU["You: kubectl, Helm, CI"]
LB["Control-plane load balancer"]
subgraph CP["Control-plane node"]
KG["KubeGate (public address)"]
API["API server (local only)"]
ETCD["etcd"]
CTRL["scheduler and controller-manager"]
TS["tunnel server"]
end
subgraph WK["Worker node"]
KUBELET["kubelet: runs your pods"]
FP["failover proxy"]
TA["tunnel agent"]
end
EVERY["On every node: Cilium and syself-agent"]
YOU -->|"API request"| LB
LB --> KG --> API
TA -->|"dials out, mTLS"| TSWhat runs on a control-plane node#
A control-plane node runs the parts that manage the cluster and hold its state:
- The API server, the entry point for every command. It is bound to a local-only address, so nothing on the network reaches it directly.
- etcd, the database that holds the cluster's state.
- The scheduler and the controller-manager, the standard Kubernetes controllers that place pods and drive the cluster toward its declared state.
- KubeGate, Syself's gate. It sits on the node's public address, in front of the API server, and checks every connection before it reaches the API server. It is the only way in.
- The tunnel server, one end of the reverse tunnel. Nodes dial into it. See Platform components for how KubeGate and the tunnel work.
What runs on a worker node#
A worker node runs your pods and the pieces that keep it healthy and connected:
- kubelet, the standard Kubernetes agent that runs the containers.
- The failover proxy, which keeps the worker talking to a control plane when the normal path through the load balancer fails.
- The tunnel agent, the worker's end of the reverse tunnel. It dials out to the tunnel server. See Platform components for the failover proxy and the tunnel in depth.
What runs on every node#
Two pieces run on both roles:
- Cilium, the single network layer: pod networking, load balancing, and the host firewall. What Cilium does is in Networking and Cilium .
- syself-agent, Syself's on-node health agent. It checks the node, restarts what it can, and reports the node's condition so the management cluster can heal it.
How you reach the cluster#
Your kubectl, Helm, and CI talk to the workload cluster's own API server, never through the management cluster. The request takes the path in the diagram above. Commands that need the API server to reach back into a node, like kubectl logs and kubectl exec, travel over the reverse tunnel each node holds open. Every node dials that tunnel outward to the control plane, so no node needs an address the internet can reach.
The control plane and etcd quorum#
etcd keeps working while more than half of its members are up. That majority is the quorum. Run three control-plane nodes and the cluster survives losing one, because two of three is still a majority. Run one and losing it takes the control plane down until it is replaced. High-availability control plane covers how many nodes to run and where to place them.
Losing a control-plane node does not stop your applications. They keep serving on the worker nodes. What pauses is control-plane work, like scheduling new pods, until the quorum is back.
Where to read more#
- KubeGate, the node agent, and the tunnel : KubeGate, syself-agent, the failover proxy, and the tunnel in depth.
- Networking and Cilium : pod networking, the host firewall, and load balancing.
- The security model : why this is safe on the public internet.
- Minimal provider dependency : the no-private-network decision and what Syself takes from Hetzner.
- Management and workload clusters : the split between this cluster and the management cluster.
- Ports and listeners : the exact address and port each piece binds to.
Management and Workload Clusters
Your workload cluster is a complete Kubernetes cluster on your own Hetzner servers; the management cluster is where Syself runs the automation that builds and looks after it.
Cluster Stacks
One version number pins the node OS, the cluster topology, and the cluster components together, so every cluster runs a combination Syself tested as a whole.