Worker Pools

2 Minuten Lesezeit

Worker Pools definieren die Node-Gruppen eines Clusters. Jeder Pool hat eine eigene Machine-Konfiguration, Skalierungsgrenzen und kann mit Taints oder Labels versehen werden. Ein Cluster kann mehrere Worker Pools mit unterschiedlichen Eigenschaften betreiben.

Grundstruktur

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

Felder

Skalierung

Feld	Typ	Beschreibung
`minimum`	integer	Minimale Anzahl Nodes im Pool (auch bei aktivem Autoscaler)
`maximum`	integer	Maximale Anzahl Nodes im Pool
`maxSurge`	integer	Zusätzliche Nodes, die während eines Rolling Updates hochgefahren werden
`maxUnavailable`	integer	Nodes, die während eines Updates gleichzeitig nicht verfügbar sein dürfen

Machine

Feld	Typ	Beschreibung
`machine.type`	string	Flavor-Name (z.B. `SCS-2V:4:100`)
`machine.image.name`	string	Betriebssystem-Image (z.B. `ubuntu`)
`machine.image.version`	string	Image-Version
`machine.architecture`	string	CPU-Architektur (`amd64` oder `arm64`)
`volume.size`	string	Root-Volume-Größe (z.B. `50Gi`)
`volume.type`	string	Volume-Typ (Standard: `default`)

Kubernetes-Version pro Pool

kubernetes:
  version: "1.33"

Ermöglicht schrittweise Upgrades: ein Pool kann auf eine neuere K8s-Version aktualisiert werden, während andere noch auf der alten Version laufen.

Taints und Labels

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

Labels werden an alle Nodes des Pools weitergegeben und können für nodeSelector oder nodeAffinity genutzt werden. Taints verhindern, dass Pods ohne passende Tolerations auf dem Pool geschedult werden.

System Components

systemComponents:
  allow: true

Legt fest, ob Gardener-interne Systemkomponenten (z.B. CoreDNS, kube-proxy) auf diesem Pool laufen dürfen. Bei dedizierten Workload-Pools kann dieser Wert auf false gesetzt werden.

Multi-Pool-Setup

Typischer Anwendungsfall: ein Pool für allgemeine Workloads, ein zweiter für spezialisierte oder ressourcenintensive 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

Hinweise

minimum: 0 ist möglich und ermöglicht das vollständige Herunterskalieren eines Pools — sinnvoll für optionale Workload-Pools, die nur bei Bedarf aktiv sind.
Änderungen an machine.type oder machine.image lösen einen rollenden Node-Austausch aus.
Jeder Pool muss einen eindeutigen name haben.

Zuletzt geändert 20.04.2026: Resturcturing and enhancing the PSKE documentation. (ca65914)