Run a worker-less cluster

A worker-less cluster runs only control-plane nodes, with no worker pool. It fits a cluster that exists to host platform components rather than tenant workloads, a small management or tooling cluster, for example. It is a deliberate, narrow choice: know what still works and what stops before you run one.

Declare it by omitting the workers#

Leave the workers section out of the Cluster object entirely. The control plane comes up and the cluster is Ready with no worker Machines:

		apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: tooling
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["10.128.0.0/12"]
    pods:
      cidrBlocks: ["192.168.0.0/16"]
    serviceDomain: "cluster.local"
  topology:
    classRef:
      name: hetzner-apalla-1-36-v1
    version: v1.36.3
    controlPlane:
      class: hcloud
      replicas: 3
    variables:
      - name: region
        value: nbg1
      - name: controlPlaneMachineTypeHcloud
        value: cpx32
	

What runs, and what does not#

Control-plane nodes carry a NoSchedule taint that keeps ordinary pods off them. The in-cluster components that must run somewhere tolerate that taint, so they fall back onto the control-plane nodes when there is no worker to take them. Your own workloads, and anything that does not tolerate the control-plane taint, do not schedule at all.

Two consequences to plan for:

• No block storage. The CSI components that back Hetzner Cloud volumes cannot run on control-plane nodes, so a worker-less cluster has no dynamically provisioned block storage. The csi-controller Deployment stays Pending in kube-system for as long as the cluster has no workers. This is expected, not a fault. Do not run stateful workloads that need a PersistentVolume here.
• No tenant workloads. Your applications do not tolerate the control-plane taint and will sit Pending. A worker-less cluster is for the control plane and platform components, not for running your apps.

One or three control planes#

The control-plane count is the same decision as any cluster:

• One control-plane node for a disposable or non-production tooling cluster where control-plane downtime is acceptable.
• Three for anything that must stay available, so the in-cluster components running there keep a quorum and survive a node replacement. See High-availability control plane .

With everything running on the control plane, size those nodes with headroom for the in-cluster components, not just for etcd and the API server.

On three control planes, the platform spreads these in-cluster components across the nodes where it can, so losing one node does not necessarily take a component down. Single-replica in-cluster components simply restart on another control-plane node.

Add workers later#

A worker-less cluster is not a dead end. Add a machineDeployments entry when you need to run real workloads, and the in-cluster components move back onto the new workers. See Add cloud servers . For the full variable list, see Cluster variables .

Related#

• Autoscale a cluster , add and remove workers automatically once you add a pool
• High-availability control plane , sizing and quorum for the control plane