Chapter 2. Default resource requirements for Red Hat Advanced Cluster Security for Kubernetes
2.1. General requirements
RHACS has some system requirements that must be met before you can install it.
You must not install Red Hat Advanced Cluster Security for Kubernetes on:
- Amazon Elastic File System (Amazon EFS). Use the Amazon Elastic Block Store (Amazon EBS) with the default gp2 volume type instead.
- Older CPUs that do not have the Streaming SIMD Extensions (SSE) 4.2 instruction set. For example, Intel processors older than Sandy Bridge and AMD processors older than Bulldozer. (These processors were released in 2011.)
To install Red Hat Advanced Cluster Security for Kubernetes, you must have one of the following systems:
- OpenShift Container Platform version 4.11 or later, and cluster nodes with a supported operating system of Red Hat Enterprise Linux CoreOS (RHCOS) or Red Hat Enterprise Linux (RHEL).
a supported managed Kubernetes platform, and cluster nodes with a supported operating system of Amazon Linux, CentOS, Container-Optimized OS from Google, Red Hat Enterprise Linux CoreOS (RHCOS), Debian, Red Hat Enterprise Linux (RHEL), or Ubuntu.
For more information, see Red Hat Advanced Cluster Security for Kubernetes Support Policy.
Cluster nodes minimum requirements:
Architecture:
amd64,ppc64le, ors390xNoteStarting with RHACS 4.3, both Central and secured cluster services are supported on IBM Power(
ppc64le), IBM Z(s390x), and IBM® LinuxONE(s390x) clusters.- Processor: 3 CPU cores
Memory: 6 GiB of RAM
NoteSee the default memory and CPU requirements for each component and ensure that the node size can support them.
Persistent storage by using persistent volume claim (PVC):
Use Solid-State Drives (SSDs) for best performance. However, you can use another storage type if you do not have SSDs available.
ImportantYou must not use Ceph FS storage with Red Hat Advanced Cluster Security for Kubernetes. Red Hat recommends using RBD block mode PVCs for Red Hat Advanced Cluster Security for Kubernetes.
To install using Helm charts:
-
You must have Helm command-line interface (CLI) v3.2 or newer, if you are installing or configuring Red Hat Advanced Cluster Security for Kubernetes using Helm charts. Use the
helm versioncommand to verify the version of Helm you have installed. -
You must have access to the Red Hat Container Registry. For information about downloading images from
registry.redhat.io, see Red Hat Container Registry Authentication.
2.2. Central services (self-managed)
If you are using Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service), you do not need to review the requirements for Central services, because they are managed by Red Hat. You only need to look at the requirements for secured cluster services.
Central services contain the following components:
- Central
- Scanner
2.2.1. Central
A containerized service called Central handles API interactions and RHACS web portal access while a containerized service called Central DB (PostgreSQL 13) handles data persistence.
Central DB requires persistent storage.
You can provide storage with a persistent volume claim (PVC).
NoteYou can use a hostPath volume for storage only if all your hosts (or a group of hosts) mount a shared file system, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node. Red Hat does not recommend using a hostPath volume.
- Use Solid-State Drives (SSD) for best performance. However, you can use another storage type if you do not have SSDs available.
If you use a web proxy or firewall, you must configure bypass rules to allow traffic for the
definitions.stackrox.ioandcollector-modules.stackrox.iodomains and enable Red Hat Advanced Cluster Security for Kubernetes to trust your web proxy or firewall. Otherwise, updates for vulnerability definitions and kernel support packages will fail.Red Hat Advanced Cluster Security for Kubernetes requires access to:
-
definitions.stackrox.iofor downloading updated vulnerability definitions. Vulnerability definition updates allow Red Hat Advanced Cluster Security for Kubernetes to maintain up-to-date vulnerability data when new vulnerabilities are discovered or additional data sources are added. -
collector-modules.stackrox.ioto download updated kernel support packages. Updated Kernel support packages ensure that Red Hat Advanced Cluster Security for Kubernetes can monitor the latest operating systems and collect data about the network traffic and processes running inside the containers. Without these updates, Red Hat Advanced Cluster Security for Kubernetes might fail to monitor containers if you add new nodes in your cluster or if you update your nodes' operating system.
-
For security reasons, you should deploy Central in a cluster with limited administrative access.
Memory, CPU, and storage requirements
The following table lists the minimum memory and storage values required to install and run Central.
| Central | CPU | Memory | Storage |
|---|---|---|---|
| Request | 1.5 cores | 4 GiB | 100 GiB |
| Limit | 4 cores | 8 GiB | 100 GiB |
Central requires Central DB to store data. The following table lists the minimum memory and storage values required to install and run Central DB.
| Central DB | CPU | Memory | Storage |
|---|---|---|---|
| Request | 4 cores | 8 GiB | 100 GiB |
| Limit | 8 cores | 16 GiB | 100 GiB |
2.2.2. Scanner
Red Hat Advanced Cluster Security for Kubernetes includes an image vulnerability scanner called Scanner. This service scans images that are not already scanned by scanners integrated into image registries.
Memory and CPU requirements
| Scanner | CPU | Memory |
|---|---|---|
| Request | 1 core | 1500 MiB |
| Limit | 2 cores | 4000 MiB |
Scanner requires Scanner-DB to store data. The following table lists the minimum memory and storage values required to install and run Scanner-DB.
| Scanner-DB | CPU | Memory |
|---|---|---|
| Request | .2 cores | 200 MiB |
| Limit | 2 cores | 4000 MiB |
2.3. Secured cluster services
Secured cluster services contain the following components:
- Sensor
- Admission controller
- Collector
2.3.1. Sensor
Sensor monitors your Kubernetes and OpenShift Container Platform clusters. These services currently deploy in a single deployment, which handles interactions with the Kubernetes API and coordinates with Collector.
Memory and CPU requirements
The following table lists the minimum memory and storage values required to install and run sensor on secured clusters.
| Sensor | CPU | Memory |
|---|---|---|
| Request | 2 cores | 4 GiB |
| Limit | 4 cores | 8 GiB |
2.3.2. Admission controller
The Admission controller prevents users from creating workloads that violate policies you configure.
Memory and CPU requirements
By default, the admission control service runs 3 replicas. The following table lists the request and limits for each replica.
| Admission controller | CPU | Memory |
|---|---|---|
| Request | 0.05 cores | 100 MiB |
| Limit | 0.5 cores | 500 MiB |
2.3.3. Collector
Collector monitors runtime activity on each node in your secured clusters. It connects to Sensor to report this information. The collector pod has three containers. The first container is collector, which actually monitors and reports the runtime activity on the node. The other two are compliance and node-inventory.
Collection requirements
To use the CORE_BPF collection method, the base kernel must support BTF, and the BTF file must be available to collector. In general, the kernel version must be later than 5.8 (4.18 for RHEL nodes) and the CONFIG_DEBUG_INFO_BTF configuration option must be set.
Collector looks for the BTF file in the standard locations shown in the following list:
Example 2.1. BTF file locations
/sys/kernel/btf/vmlinux /boot/vmlinux-<kernel-version> /lib/modules/<kernel-version>/vmlinux-<kernel-version> /lib/modules/<kernel-version>/build/vmlinux /usr/lib/modules/<kernel-version>/kernel/vmlinux /usr/lib/debug/boot/vmlinux-<kernel-version> /usr/lib/debug/boot/vmlinux-<kernel-version>.debug /usr/lib/debug/lib/modules/<kernel-version>/vmlinux
If any of these files exists, it is likely that the kernel has BTF support and CORE_BPF is configurable.
Memory and CPU requirements
By default, the admission control service runs 3 replicas. The following table lists the request and limits for each replica.
| Collector | CPU | Memory | |
|---|---|---|---|
| Collector Container | Request | 0.05 cores | 320 MiB |
| Limit | 0.75 cores | 1000 MiB | |
| Compliance Container | Request | 0.01 cores | 10 MiB |
| Limit | 1 core | 2000 MiB | |
| Node-Inventory Container | Request | 0.01 cores | 10 MiB |
| Limit | 1 core | 500 MiB | |
| Total | Request | 0.07 cores | 340 MiB |
| Limit | 2.75 cores | 3500 MiB |
