Resource requirements

Discover the resources necessary to run the StackRox Kubernetes Security Platform.

2 minute read

The StackRox Kubernetes Security Platform includes services across three tiers. All services are deployed using standard orchestrator APIs, such as Kubernetes Deployments and DaemonSets.

The exact resource usage depends on the number of clusters you monitor, the number of nodes your monitor, and certain behavioral attributes of the containerized workloads you monitor. See the Sizing guidelines section for recommend values.

This topic outlines requested resources, and the limits that are applied. Actual usage may be lower than the Request, but won’t be more than the specified Limit.

Centralized Services

Centralized services are deployed once and can monitor multiple separate clusters.

Central

A single containerized service called Central handles data persistence, API interactions, UI access, and other functions. Only Central uses persistent storage.

Central requires persistent storage:

  • You can provide storage with a PersistentVolumeClaim (pvc) or hostPath.
  • Use the host-mounted storage only if all your hosts (or a group of hosts) mount a shared filesystem, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node.
  • We recommend using Solid-State Drives (SSDs) for best performance. However, you can use another storage type if you don’t have SSDs available.

The following table lists the minimum memory and storage values required to install and run Central. Refer to Central’s sizing guidelines section to view the recommended values.

  • For the StackRox Kubernetes Security Platform version 3.0.50 and newer

    CentralCPUMemoryStorage
    Request1.5 cores4 GiB100 GiB
    Limit4 cores8 GiB100 GiB
  • For the StackRox Kubernetes Security Platform version 3.0.49 and older

    CentralCPUMemoryStorage
    Request1.5 cores4 GiB100 GiB
    Limit2 cores8 GiB100 GiB

For deploying Central, we recommend that you use a machine type with 4 or more cores and apply scheduling policies to launch Central on such nodes.

Sizing guidelines

We recommend the following compute resources and storage values depending upon the number of nodes in your cluster.

NodesDeploymentsCPUMemoryStorage
Up to 100Up to 10002 cores4 GiB100 GiB
Up to 500Up to 20004 cores8 GiB100 GiB
More than 500More than 20008 cores12 - 16 GiB100 - 200 GiB

Scanner

The StackRox Kubernetes Security Platform includes an image vulnerability scanner called StackRox Scanner. This service scans images that aren’t already scanned by scanners integrated into image registries.

  • For Scanner version 1.3.6 and older:

    ScannerCPUMemory
    Request.5 cores500 MiB
    Limit2 cores2000 MiB
  • For Scanner version 1.3.7 and newer:

    ScannerCPUMemory
    Request1.2 cores2700 MiB
    Limit5 cores8000 MiB

With the StackRox Kubernetes Security Platform version 3.0.39 and older, you could optionally deploy monitoring services alongside Central. These services receive telemetry from StackRox services in monitored clusters. Sidecar containers are deployed alongside per-cluster and per-node services, which adds a nominal resource request to each (0.05 cores and 50 MiB of RAM).

MonitoringCPUMemory
Request.6 cores600 MiB
Limit1.2 cores1200 MiB

Central services may be deployed in a separate cluster of their own, or in a cluster used for other purposes. For security reasons, customers may wish to deploy these services in a cluster to which administrative access is limited.

Per-Cluster Services

Per-cluster services are deployed into each monitored cluster.

Sensor

StackRox Sensor monitors your Kubernetes and OpenShift clusters. These services currently deploy in a single deployment, which handles interactions with the Kubernetes API and coordinates with Per-Node services.

Beginning from the StackRox Kubernetes Security Platform version 3.0.40, Sensor handles policy evaluation and deployment and image detection.

  • For the StackRox Kubernetes Security Platform version 3.0.44 and newer

    SensorCPUMemory
    Request1 core1 GiB
    Limit2 cores4 GiB
  • For the StackRox Kubernetes Security Platform version 3.0.43 and older

    SensorCPUMemory
    Request.5 cores500 MiB
    Limit1 core1000 MiB

Admission controller

The StackRox admission controller prevents users from creating workloads that violate policies you configure. By default, the admission control service runs 3 replicas. The following table lists the request and limits for each replica.

To use admission controller enforcement on OpenShift, you need the StackRox Kubernetes Security Platform version 3.0.49 or newer.

Admission controllerCPUMemory
Request.05 cores100 MiB
Limit.5 cores500 MiB

Per-Node Services (Collector)

StackRox Collector monitors runtime activity on each node in your secured clusters. It connects to StackRox Sensor to report this information.

CollectorCPUMemory
Request.05 cores320 MiB
Limit.75 cores1 GiB

Starting with the StackRox Kubernetes Security Platform version 2.5.31.0, Collector includes compliance data collection functions. In the StackRox Kubernetes Security Platform version 2.5.30.0 and older, a separate DaemonSet collects Compliance data. The resource requirements for Compliance are:

ComplianceCPUMemory
Request.1 cores10 MiB
Limit1 core2 GiB

Starting with the StackRox Kubernetes Security Platform version 2.5.32.0, Collector uses a mutable image tag (<version>-latest) so you get support for newer Linux kernel versions more easily. We don’t change code, preexisting kernel modules, or eBPF programs in image updates. We only add a single image layer with support for new kernel versions published after the initial release. See the Mutable image tags section for more information.

Questions?

We're happy to help! Reach out to us to discuss questions, issues, or feature requests.

© 2021 StackRox Inc. All rights reserved.