#Worker Pools

Worker pools define the compute layer of a Shoot cluster. Each pool describes a group of Kubernetes worker nodes with the same machine profile, scaling settings and placement rules.

A cluster can use several worker pools at the same time. This is useful when applications have different requirements. General-purpose services may run on standard workers, while memory-intensive or specialized workloads use a separate pool. Where supported, dedicated hardware capabilities can be exposed through a matching worker profile.

OSC maps worker pools to customer-specific compute capacity. The underlying physical hosts are managed by OSC and grouped into machine pools. Customers do not provision or administer those hosts directly. Instead, they define the worker capacity they need at Kubernetes level.

Zone placement is an important part of the design. Worker pools can be distributed across the three Availability Zones of a region. Kubernetes can then spread replicas across zones when applications use appropriate topology and scheduling settings. For more details, head over to the High Availability Concept part.

Scaling a worker pool changes the number of worker machines within the available physical capacity. Because the compute pool is dedicated, capacity planning still matters. Large or sudden increases should be aligned with the contracted and installed host capacity.

Worker pools provide flexibility, but they do not make applications highly available on their own. Applications should use multiple replicas, topology spread constraints, disruption budgets and storage choices that match their recovery objectives.