Summary
Several pods the API creates at runtime have no way to set Kubernetes resource requests/limits. The chart exposes resources for api, postgres, slackbot, tokenBroker, repoCache, ironControl, and the sandbox container, but not for the iron-proxy Pods (the API self-proxy and every per-sandbox proxy), the tool-server sidecar, or the workflow-run pod. The container specs in services/api/api/sandbox/kubernetes.py are hardcoded with no resources field and no env knob, so these pods run with no scheduler reservation and no OOM/throttle ceiling (the workflow-run pod only incidentally inherits the sandbox sizing).
Steps to reproduce
- Deploy Centaur with
toolServer.enabled=true and the kubernetes sandbox backend.
- Inspect container resources, e.g.
kubectl get pod <pod> -o jsonpath='{.spec.containers[*].resources}':
centaur-api-proxy-* and per-sandbox *-proxy-* (container iron-proxy) → {}
- sandbox
tool-server sidecar → {}
- workflow-run pods → inherit the sandbox sizing, not independently configurable
- Contrast the
sandbox container, which is sized via sandbox.resources → KUBERNETES_SANDBOX_* env → _pod_resources().
Root cause
_build_proxy_pod_spec, _build_tool_server_container, and _build_workflow_run_pod_spec build their containers without a configurable resources, and the chart's ironProxy/toolServer have no resources keys. There is no env knob analogous to the sandbox's _pod_resources() for these containers, so they cannot be sized and the workflow-run pod can only inherit the sandbox's values.
Expected outcome
- Each API-managed pod — the API self-proxy, every per-sandbox proxy, the tool-server sidecar, and the workflow-run pod — can be sized independently via chart values.
- Leaving the values unset preserves current behavior: the proxies and tool-server stay unconstrained, and the workflow-run pod keeps its prior sandbox-equivalent sizing.
- Partial specs work (e.g. memory request==limit, no CPU request).
Summary
Several pods the API creates at runtime have no way to set Kubernetes resource requests/limits. The chart exposes
resourcesforapi,postgres,slackbot,tokenBroker,repoCache,ironControl, and thesandboxcontainer, but not for the iron-proxy Pods (the API self-proxy and every per-sandbox proxy), thetool-serversidecar, or the workflow-run pod. The container specs inservices/api/api/sandbox/kubernetes.pyare hardcoded with noresourcesfield and no env knob, so these pods run with no scheduler reservation and no OOM/throttle ceiling (the workflow-run pod only incidentally inherits the sandbox sizing).Steps to reproduce
toolServer.enabled=trueand the kubernetes sandbox backend.kubectl get pod <pod> -o jsonpath='{.spec.containers[*].resources}':centaur-api-proxy-*and per-sandbox*-proxy-*(containeriron-proxy) →{}tool-serversidecar →{}sandboxcontainer, which is sized viasandbox.resources→KUBERNETES_SANDBOX_*env →_pod_resources().Root cause
_build_proxy_pod_spec,_build_tool_server_container, and_build_workflow_run_pod_specbuild their containers without a configurableresources, and the chart'sironProxy/toolServerhave noresourceskeys. There is no env knob analogous to the sandbox's_pod_resources()for these containers, so they cannot be sized and the workflow-run pod can only inherit the sandbox's values.Expected outcome