Sizing for service-oriented add-ons

Red Hat OpenShift Serverless

OpenShift Serverless is a Red Hat OpenShift Container Platform (RHOCP) add-on that facilitates running serverless workloads in Red Hat OpenShift. For example, applications with a function-based, infrastructure-transparent architecture. The results show that except for a small static offset, performance is not expected to suffer when using OpenShift Serverless.

Sizing for Operator deployment

The following formula shows the overhead of deploying the Serverless Operator:

$DIFL=0.13 IFLs$

Sizing for Workloads

There is a negligible IFL demand of the Serverless Operator with a $±2%$ deviation to the baseline.

Red Hat OpenShift Service Mesh (OSSM)

The Red Hat OpenShift Service Mesh (OSSM) add-on makes it easier to employ microservice architectures on RHOCP by transparently managing network traffic between services, providing authentication facilities, and enabling security and observability features. The OSSM architecture consists of the service mesh itself, which is based on Istio® , the Kiali® management console, and the distributed tracing platform. Additionally, the Grafana® Tempo® backend and OpenTelemetry® collector can be used for telemetry features.

Sizing for Operator deployment

The following formula shows the overhead of deploying the OSSM core Operators:

$DIFL=0.13 IFLs$

This demand is increased by the full set of Operators:

$DIFL=0.55 IFLs$

Sizing for Workloads

The following equation reflects the IFL demand per thousand transactions-per-second (k tps):

$DIFL= N*0.58IFLsk tps$

If you plan to use OSSM with a service workload of 10.000 tps, you should provision at least 6 IFLs for OSSM alone.

Logging for Red Hat OpenShift

Logging for Red Hat OpenShift Container Platform (RHOCP) is critical for monitoring, troubleshooting, and auditing applications and system components. To ensure that logging is effectively managed, the Cluster Logging Operator handles the lifecycle and configuration of the logging stack, including Fluentd™, Elasticsearch™, and Kibana™.

Properly sizing the logging subsystem that is managed by the Cluster Logging Operator helps ensure:

• High availability of logging components, preventing data loss.
• Efficient storage management, optimizing the use of resources in the cluster.
• Optimal performance under heavy load, ensuring timely log processing and retrieval.

Kube-burner is a Kubernetes performance and scale test orchestration toolset, which allows to create or delete Kubernetes resources and trigger monitoring and alerts. With these capabilities, it is a suitable tool to evaluate the overhead of logging operators.

Sizing for Operator deployment

The IFL demand per running number of log transactions per second follows a linear equation:

$DynamicIFL(tpsLogs) = 0.5 IFL*tpsLog1000$

Table 1. Logging IFL demand

Log rate	Estimated IFLs (Fluentd + Elasticsearch)	Memory requirement
10k logs/sec	1.0 – 1.5 IFLs	~8 – 16 GB
50k logs/sec	3.0 – 4.0 IFLs	~32 – 48 GB
100k logs/sec	6.0 – 8.0 IFLs	~64 – 96 GB

The numbers assume a ~7-day retention and a compression ratio of ~2:1.

Red Hat OpenShift AI

Red Hat OpenShift AI (RHOAI) is an enterprise-grade Kubernetes-based platform that is designed to support model training and inference workloads on IBM Z and IBM® LinuxONE. RHOAI provides an integrated environment for developing, deploying, and scaling AI workloads while maintaining enterprise-grade security, reliability, and performance.

Properly sizing RHOAI ensures:

• High availability of AI components.
• Efficient resource management, optimizing the use of resources in the cluster.
• Optimal performance under heavy load.

The RHOAI sizing measurement is based on the following components:

• OpenShift AI Operator 3.0.0 (installs OpenShift Service Mesh)
• Secondary Scheduler Operator 1.4.1
• Spyre Operator 1.0.0-dev
• cert-manager Operator 1.18.0
• Node Feature Discovery (NFD) Operator 4.19.0

Without any workload, the following IFL demand has been measured: