Worker Pools

Worker pools define the node groups of a cluster. Each pool has its own machine configuration, scaling limits, and can be configured with taints or labels. A cluster can run multiple worker pools with different characteristics.

Basic Structure

spec:
  provider:
    workers:
      - name: worker-default
        cri:
          name: containerd
        machine:
          type: SCS-2V:4:100
          image:
            name: ubuntu
            version: 22.4.2
          architecture: amd64
        minimum: 1
        maximum: 5
        maxSurge: 1
        maxUnavailable: 0
        volume:
          size: 50Gi
        systemComponents:
          allow: true

Fields

Scaling

FieldTypeDescription
minimumintegerMinimum number of nodes in the pool (also applies when autoscaler is active)
maximumintegerMaximum number of nodes in the pool
maxSurgeintegerAdditional nodes started during a rolling update
maxUnavailableintegerNodes that may be simultaneously unavailable during an update

Machine

FieldTypeDescription
machine.typestringFlavor name (e.g. SCS-2V:4:100)
machine.image.namestringOperating system image (e.g. ubuntu)
machine.image.versionstringImage version
machine.architecturestringCPU architecture (amd64 or arm64)
volume.sizestringRoot volume size (e.g. 50Gi)
volume.typestringVolume type (default: default)

Kubernetes Version per Pool

kubernetes:
  version: "1.33"

Allows incremental upgrades: one pool can be updated to a newer K8s version while others remain on the previous version.

Taints and Labels

labels:
  node-role: gpu
taints:
  - key: dedicated
    value: gpu
    effect: NoSchedule

Labels are propagated to all nodes in the pool and can be used for nodeSelector or nodeAffinity. Taints prevent pods without matching tolerations from being scheduled onto the pool.

System Components

systemComponents:
  allow: true

Controls whether Gardener system components (e.g. CoreDNS, kube-proxy) are allowed to run on this pool. For dedicated workload pools, this can be set to false.

Multi-Pool Setup

Typical use case: one pool for general workloads, a second for specialized or resource-intensive workloads.

workers:
  - name: worker-general
    machine:
      type: SCS-2V:4:100
    minimum: 2
    maximum: 10
    systemComponents:
      allow: true

  - name: worker-gpu
    machine:
      type: SCS-8V:32:100
    minimum: 0
    maximum: 4
    taints:
      - key: dedicated
        value: gpu
        effect: NoSchedule
    labels:
      node-role: gpu
    systemComponents:
      allow: false

Notes

  • minimum: 0 is valid and allows a pool to scale down completely — useful for optional workload pools that are only active on demand.
  • Changes to machine.type or machine.image trigger a rolling node replacement.
  • Each pool must have a unique name.