Resource requirements

By default the charts set no resource requests or limits: pods are scheduled wherever they fit and may consume whatever the node has. That is acceptable for evaluation. For any environment carrying real traffic, set requests and limits explicitly.

Where the load actually is

The components have very different resource profiles.

Component	Profile
`ometascan` (MetaDefender Core)	By far the heaviest. Runs the scan engines: CPU-bound during scanning, memory-hungry per concurrent file, and writes scan temporary files to disk. Size this first.
`api-gateway`	Moderate. Handles file upload and hand-off; throughput scales with concurrent connections and file size.
`callback-service`	Light. Outbound webhook delivery.
`control-center`	Moderate and steady. Orchestration and database traffic, not file processing.
`identity-service`	Light. Authentication requests only.
`file-storage`	Moderate CPU, heavy disk. Store and retrieve scanned files.
`postgres`	Moderate to heavy depending on retention and throughput.

The published baseline

Per-component minimums are maintained in System requirements, which is the authoritative source. Those figures describe a conventional install — one component per host — but they translate directly into Kubernetes resource requests, because a request is exactly "the capacity this container needs to have to itself".

Component	CPU	Memory	Storage
`postgres`	8	16Gi	1Ti SSD/NVMe
`redis`	2	32Gi	20Gi
`rabbitmq`	4	8Gi	100Gi
`file-storage`	8	8Gi	1Ti SSD/NVMe
`control-center`	4	4Gi	100Gi
`identity-service`	4	4Gi	50Gi
`api-gateway`	4	8Gi	50Gi
`callback-service`	4	8Gi	50Gi
`ometascan`	See the MetaDefender Core requirements

Two things to read carefully there rather than from this page:

ometascan is not sized on that page at all — it defers to the MetaDefender Core requirements, because its needs scale with your licence type and the number of enabled engines.
The storage column is not ephemeral storage. For postgres and file-storage it is persistent-volume sizing — see Storage configuration. For the others it is host disk on a conventional install, and in Kubernetes maps to ephemeral-storage, which is far smaller in practice because logs are the only thing written there.

Note also that the published requirements track the conventional installer and may name different dependency versions than the charts ship. The charts currently deploy postgres:16, redis:8 and rabbitmq:4.2.5-management; check the requirements page for the versions supported by your release, and override postgres.image / redis.image / rabbitmq.image if you need to match them exactly.

Assigning CPU and memory

Requests and limits use the standard Kubernetes resources block. Every component in both charts accepts it.

workers: ometascan: resources: requests: cpu: "4" memory: 4Gi limits: cpu: "8" memory: 16Gi # The API Gateway and Callback Service have the same allowance. api-gateway: resources: requests: cpu: "4" memory: 8Gi limits: cpu: "4" memory: 8Gi callback-service: resources: requests: cpu: "4" memory: 8Gi limits: cpu: "4" memory: 8Gi

MetaDefender Core services and bundled infrastructure take the same block:

control-center: resources: requests: { cpu: "2", memory: 4Gi } limits: { cpu: "4", memory: 4Gi } identity-service: resources: requests: { cpu: "1", memory: 1Gi } limits: { cpu: "2", memory: 2Gi } file-storage: resources: requests: { cpu: "2", memory: 4Gi } limits: { cpu: "8", memory: 8Gi } postgres: resources: requests: { cpu: "4", memory: 8Gi } limits: { cpu: "8", memory: 8Gi }

Disk space: ephemeral storage

Set ephemeral-storage on any MetaDefender Cluster Worker that processes files, sized for the deployed engine plus peak concurrent scan temporary data. Keep the CPU and memory figures consistent with what you chose above — the block below adds only the storage line:

workers: ometascan: resources: requests: cpu: "4" memory: 4Gi ephemeral-storage: 200Gi limits: cpu: "8" memory: 16Gi ephemeral-storage: 200Gi

The MetaDefender Core services need a modest allowance too. Every service writes its log file to the container filesystem at /app/log and tails it to stdout. A long-running MetaDefender Cluster Control Center pod can therefore be evicted for log growth alone. Give them a bounded allowance:

control-center: resources: requests: { cpu: "2", memory: 4Gi, ephemeral-storage: 8Gi } limits: { cpu: "4", memory: 4Gi, ephemeral-storage: 8Gi }

Lowering the log level (see the Configuration reference] reduces the growth rate but does not bound it.

Persistent storage — for MetaDefender Cluster File Storage and PostgreSQL — is configured separately. See Storage configuration.

Database requirements

The bundled PostgreSQL holds four databases: md_cluster_control_center, md_cluster_datalake, md_cluster_datawarehouse and md_cluster_identity_service. It starts with max_connections=200.

Connection demand grows with the number of pods, since MetaDefender Cluster Control Center, MetaDefender Cluster Identity Service and each MetaDefender Cluster Worker all hold connections. If you raise replica counts substantially, raise the limit to match:

postgres: maxConnections: 400

Storage demand is driven by the datalake and data warehouse, which retain processing history — roughly 4 GB per million objects in a five-instance, eight-engine configuration. Size the volume for your retention policy; the published baseline is 1 TB on SSD or NVMe. See Storage configuration.

For production, run PostgreSQL externally rather than as the bundled single pod. See High availability.

Last updated on

Was this page helpful?