- Shipped
- September 23, 2026 at 10:30 AM UTC
- Author
- Kamo
- Commit
- 3e76660
The deployment had no resources: block at all. No request, so the scheduler could not reason about this pod's footprint; no limit, so nothing capped the JVM's -XX:MaxRAMPercentage=70.0 heap short of the node's own RAM (each node here is ~126GiB). This service also fully buffers every request and response body it forwards in heap (readAllBytes / ByteArrayResource), buffers a multipart upload a SECOND time when it rebuilds it for the upstream hop, and allows uploads up to multipart.max-file-size: 500MB -- so a single large upload can transiently need roughly 1Gi just for body bytes, on the one service that fronts every /api/** call on the platform (2 replicas). request.memory: 512Mi. limit.memory: 4Gi -- above the 2Gi floor this Dockerfile template requires elsewhere (below that, heap-at-70%-of-limit plus non-heap overhead does not close and the pod OOMKills in normal use; see the emailservice/mediaservice deployment.yaml comments this one borrows), and sized like MediaService, the other large-body service on this template, rather than the floor other services use here. Current usage per pod is ~610Mi RSS (kubectl top), so this is headroom, not a correction of an observed OOM. This is a stopgap, not the real fix: streaming the proxy instead of buffering full bodies is the actual defense against a deliberate flood of large concurrent uploads, and is a larger change than this task covers. 500MB is an existing, already-deliberate cap (it sits below MediaService's own 3GB internal allowance and matches securityservice's own gateway-level cap), so it is left as is rather than narrowed as a substitute for streaming. DeploymentResourcesTest pins that the manifest actually has a resources block with a request and a limit; deleting it fails the test.