Dedicate node pools per client

Namespaces separate clients logically, but their pods still share nodes. A namespace is a logical partition inside one cluster.

When tenants must not share hardware, give each client its own pool of nodes. This puts isolation at the machine level, not just the namespace level. It is the pattern agencies and MSPs (managed service providers) use for clients that need a hard boundary.

Why node-level isolation matters

Sensitive tenants, compliance rules, and noisy neighbors all need the same fix: separate machines. Short of a separate cluster, a dedicated pool is the strongest boundary, because a client's pods run only on that client's nodes.

Two levers: dedicated machines and sandboxed workloads

Dedicating machines is one lever. The other is the runtime a workload runs under. The secure runtime class runs each pod inside its own lightweight virtual machine, so a container escape stops at the VM boundary. Together, the two levers let a sensitive tenant run sandboxed workloads on its own dedicated hardware. See Run in the secure runtime .

One pool per client

Give each client a pool with a client label (see Label nodes and assign roles ):

		workers:
  machineDeployments:
    - class: workeramd64hcloud
      name: md-client-acme
      replicas: 3
      metadata:
        labels:
          node.cluster.x-k8s.io/client: acme
    - class: workeramd64hcloud
      name: md-client-globex
      replicas: 2
      metadata:
        labels:
          node.cluster.x-k8s.io/client: globex
	

Steer each client's pods, and keep others off

Pin a client's workloads to its nodes with a nodeSelector or node affinity . A nodeSelector is a rule that keeps a pod on nodes carrying a given label:

		spec:
  nodeSelector:
    node.cluster.x-k8s.io/client: acme
	

A label attracts but does not repel. A pod without a nodeSelector can still land on a client's node. Syself Autopilot does not support node taints (see Node taints are not supported ), so the boundary is the pool label plus discipline on your side: give every workload a nodeSelector, so nothing lands on a client's pool by accident.

For a boundary that does not depend on every pod being labelled correctly, put sensitive tenants on their own bare-metal pool, where the hardware itself is the separation.

Dedicated bare-metal pools for sensitive tenants

For a tenant that must be on physically separate hardware, not just a separate pod, give it a bare-metal pool. Bare-metal (Robot) servers are physical machines you own. A pool that only claims that tenant's hosts means no other tenant's pod can ever land on that hardware.

First label the tenant's HetznerBareMetalHost objects (see Add bare-metal servers ):

		$ kubectl label hbmh baremetal-1 client=acme
	

Then point the pool at those hosts with workerHostSelectorBareMetal:

		- class: workeramd64baremetal
  name: md-client-acme-bm
  replicas: 2
  variables:
    overrides:
      - name: workerHostSelectorBareMetal
        value:
          matchLabels:
            client: acme
	

This is a second, separate label mechanism from the client pool label:

You need both: the host selector picks which hardware becomes Acme's, the pool label steers Acme's pods onto it.

You can run several bare-metal pools in one cluster, each selecting a different set of hosts, so each sensitive tenant gets its own machines. Check kubectl get machines -o wide: a bare-metal machine shows an hrobot:// provider ID, confirming it landed on Robot hardware and not a cloud VM.

Failure isolation per pool

For cloud pools, a Hetzner placement group keeps a pool's VMs on separate physical hosts. Without one, Hetzner can put two of a client's VMs on the same physical host, so one hardware failure takes both. spread is the only placement group type Hetzner Cloud supports.

Declare a group under spec.topology.variables, then reference it by name from the client's pool:

		variables:
  - name: hcloudPlacementGroups
    value:
      - name: acme-spread
        type: spread
workers:
  machineDeployments:
    - class: workeramd64hcloud
      name: md-client-acme
      replicas: 3
      variables:
        overrides:
          - name: workerMachinePlacementGroupNameHcloud
            value: acme-spread
	

Give each client pool its own group. Then one physical-host failure takes at most one node from one client, and a single failure never spans tenants.

See Spread nodes with placement groups for how the groups are named and their limits.

Bare-metal pools do not need this. A Robot server already is one physical host, so the dedicated bare-metal pool above already gives you that isolation.

Cost attribution and hand-off

Each client's capacity is its own pool of named machines, so you can work out the cost per client from the machine type and count in that pool, and scale each pool on its own.

Keeping clusters on the customer's own Hetzner account makes the hand-off clean. The machines, and their bill, already sit with the customer.

Where to go next

• Label nodes and assign roles
• Mix cloud and bare-metal pools
• Size a cluster for cost
• Agencies and MSPs