Resources & Scheduling

Configure CPU and RAM

spec.resources.sm and spec.resources.rdb set the total CPU and RAM for the SM Pod and every RDB Pod.

Field	Required	Description
`spec.resources.sm.requests.cpu` / `.memory`	Required if `spec.resources.sm` is set	Requested CPU and RAM for the SM Pod
`spec.resources.sm.limits.cpu` / `.memory`	Required if `spec.resources.sm` is set	CPU and RAM limits for the SM Pod
`spec.resources.rdb.requests.cpu` / `.memory`	Required if `spec.resources.rdb` is set	Requested CPU and RAM for every RDB Pod
`spec.resources.rdb.limits.cpu` / `.memory`	Required if `spec.resources.rdb` is set	CPU and RAM limits for every RDB Pod

If you omit spec.resources.sm/spec.resources.rdb, the operator applies fixed minimums for both requests and limits: 6 CPU / 1200M memory for the SM Pod, 4 CPU / 8000M memory for every RDB Pod. Values below these minimums are rejected. CPU and memory values use standard Kubernetes quantity notation:

CPU: a whole or fractional number of cores, for example "2" for 2 cores or "0.5" for half a core; or millicores using an m suffix, for example "500m", which equals 0.5 cores. 1000m equals one full core.
Memory: a number followed by a size suffix. Binary suffixes Ki, Mi, Gi, and Ti are powers of 1024, for example "512Mi" or "8Gi". Decimal suffixes k, M, G, and T are powers of 1000, for example "500M". There is no plain MB unit; use Mi or M explicitly.

This quantity notation applies to spec.resources.*.requests/limits.memory and .cpu only. The module-level ram_MB field (for example spec.rdb.ram_MB) is different: it is a plain integer number of megabytes, for example 16000, not a Kubernetes quantity string. If you set num_threads or ram_MB on a module, spec.resources for that module’s Pod must cover the combined totals: spec.resources.sm for modules in the SM Pod, spec.resources.rdb for modules in the RDB Pod. SNA counts toward both, since it runs in every Pod type. There is no separate field to size RegattaDB’s memory-backed /dev/shm volume: the operator sets its sizeLimit equal to the same component’s effective requests.memory (spec.resources.sm.requests.memory for the SM Pod, spec.resources.rdb.requests.memory for every RDB Pod).

Schedule Pods

Use spec.resources.sm.scheduling and spec.resources.rdb.scheduling to influence where the operator’s SM and RDB Pods run. These are standard Kubernetes Pod scheduling settings; omit any setting you do not need:

Field	Effect
`nodeSelector`	Requires the Pod to run on a node with all listed labels.
`tolerations`	Allows the Pod to run on nodes with matching taints; tolerations do not select a node by themselves.
`affinity`	Sets Kubernetes node-affinity, Pod-affinity, or Pod-anti-affinity rules.
`topologySpreadConstraints`	Controls how matching Pods are distributed across topology domains such as zones or nodes.

For example, this places RDB Pods only on nodes labeled for database workloads, tolerates a matching taint, and spreads matching RDB Pods across availability zones:

spec:
  resources:
    rdb:
      scheduling:
        nodeSelector:
          workload: database
        tolerations:
          - key: workload
            operator: Equal
            value: database
            effect: NoSchedule
        topologySpreadConstraints:
          - maxSkew: 1
            topologyKey: topology.kubernetes.io/zone
            whenUnsatisfiable: DoNotSchedule
            labelSelector:
              matchLabels:
                app.kubernetes.io/component: rdb

The same fields and structure can be placed under spec.resources.sm.scheduling to apply to the combined SM Pod. Affinity, tolerations, and topology spread constraints use Kubernetes PodSpec syntax; refer to your Kubernetes documentation for available operators and details.

CPU and RAM: scheduling behavior

Kubernetes uses requests to decide where a Pod can run, and limits to cap what it can use once running:

If no Kubernetes node has enough unreserved CPU or memory to satisfy your requests, Kubernetes will not schedule the Pod there. A Pod stuck Pending while otherwise healthy often means no node currently has enough spare capacity.
A CPU limit is enforced by throttling: a container that tries to use more CPU than its limit is slowed down, not killed.
A memory limit is a hard ceiling: if a container tries to use more memory than its limit, Kubernetes kills it (OOM-killed) and restarts it. This is generic Kubernetes behavior that applies to any container, not something specific to RegattaDB.

num_threads and ram_MB are RegattaDB application-level settings: they tell RegattaDB how much CPU and RAM to plan for internally, per module. Both are optional - if you leave them unset, RegattaDB’s System Manager assigns them automatically. spec.resources is a separate, Kubernetes Pod-level setting: it is the boundary Kubernetes enforces around the whole container. Unlike num_threads/ram_MB, nothing auto-detects this for you, because the operator has no way to discover your Kubernetes node hardware. If you omit spec.resources.sm/spec.resources.rdb, the operator applies the fixed minimums from Configure CPU And RAM above, so RegattaDB Pods always get a real Kubernetes QoS guarantee - never BestEffort. Size them explicitly when your workload needs more than those minimums, even though you are not required to size every individual module’s num_threads/ram_MB to do so. If you do set num_threads/ram_MB, spec.resources.sm/spec.resources.rdb must at least cover their combined totals; RegattaDB’s own processes account for the headroom they need within that allocation.

Self-Hosted Deployment

Manual Deployment

Regatta Deployment Tool

Kubernetes Deployment

Resources & Scheduling

Configure CPU and RAM

Schedule Pods

CPU and RAM: scheduling behavior

​Configure CPU and RAM

​Schedule Pods

​CPU and RAM: scheduling behavior

Configure CPU and RAM

Schedule Pods

CPU and RAM: scheduling behavior