Skip to main content

Inside a Workload Cluster

Inspect 1.36

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 ; 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 with . 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"| TS

What 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 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 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 .
  • 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. 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#