This is a cache of https://docs.openshift.com/acs/4.3/cloud_service/acscs-default-requirements.html. It is a snapshot of the page at 2024-11-22T17:54:34.423+0000.
Default resource requirements for RHACS Cloud Service | RHACS Cloud Service | Red Hat Advanced Cluster Security for Kubernetes 4.3
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Default resource requirements for Red Hat Advanced Cluster Security Cloud Service

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, or s390x

    Starting 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

    See 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.

    You 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 version command 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.

Secured cluster services

Secured cluster services contain the following components:

  • Sensor

  • Admission controller

  • Collector

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

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

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:

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