OpenShift Serverless and Knative, read on the cluster.

Red Hat OpenShift Serverless is the productised release of the upstream Knative project, packaged as two cluster operators on Red Hat OpenShift Container Platform: the Knative serving operator and the Knative eventing operator. Knative serving manages revision based autoscaling for request driven workloads. Knative eventing manages event driven invocation through the eventing broker, channels, and triggers. Both operators install on the cluster and run their controllers as cluster scoped components1.

The reading in 2026 is that OpenShift Serverless does not carry a per request, per function, or per invocation charge. The product is included as a value added operator inside Red Hat OpenShift Container Platform on the clusters where the operators run2. The cluster cores carry the platform line regardless of whether Knative revisions serve zero requests per minute or many thousands.

The structural difference from a hyperscaler function service matters at the renewal table. A buyer who built a serverless architecture on AWS Lambda or Azure Functions pays per invocation and per gigabyte second. A buyer who built the same architecture on OpenShift Serverless pays through the platform line on the cluster cores. The latter pricing is steady state irrespective of invocation volume, which favours sustained workloads and disadvantages truly bursty workloads where scale to zero would have produced a hyperscaler bill of pennies.

Knative serving supports scale to zero, where a revision with no active requests drops to zero replicas and resumes on the next request3. The scale to zero behaviour produces operational efficiency on the cluster: idle workloads do not consume worker node capacity, and the cluster autoscaler can shed worker nodes that no longer have workloads to run.

The audit reading does not capture the scale to zero floor. The audit reading captures the maximum cluster size observed across the audit window. A cluster that idled at twenty worker cores most of the time and burst to one hundred and twenty cores during a marketing campaign reads at the burst size, not the idle size. The cluster autoscaler that grew worker nodes to absorb the burst becomes the platform line exposure at audit.

The mitigation at signature is to name the burst capacity in the contract scope, agree the per core true up rate that applies inside the burst band, and refresh the band annually. The discipline does not require the buyer to suppress scale to zero use; it requires the contract scope to absorb the realistic burst behaviour of the workloads.

Knative eventing introduces a broker that buffers events between sources and sinks. The broker is itself a workload that runs on the cluster, and its sizing scales with event throughput rather than with the count of event handlers. A high throughput eventing deployment can consume significant cluster capacity in the broker workload alone before the event handler revisions are counted.

The eventing pattern often introduces a multi cluster topology. A central eventing cluster handles event ingestion and routing, and worker clusters receive routed events for handler execution. The central eventing cluster carries the platform line on its cores. The worker clusters carry their own platform lines independently. A buyer who scoped the serverless workload as a single cluster signature misses the central eventing cluster cost when the eventing topology grew across the term.

A subscription assessment in the ninety days before renewal produces a cluster by workload inventory that distinguishes serverless serving clusters from serverless eventing clusters and reconciles the platform line against the actual topology.

The cross product reading on a mixed eventing and serving cluster adds a second consideration. Channels and brokers can be backed by in memory implementations, by Apache Kafka, or by other messaging substrates. A Kafka backed broker carries the Red Hat AMQ Streams entitlement question alongside the Knative eventing operator. A buyer who scoped serverless against Knative eventing and ignored the Kafka substrate signs a renewal that does not absorb the messaging line. The two entitlements move on different cycles and the messaging line at audit reads independently of the serverless cluster footprint.

The eventing broker capacity plan should name the messaging substrate, the expected throughput at the renewal date, the broker partition count, and the retention behaviour. A documented plan, reviewed annually, keeps the eventing line readable across renewal cycles and prevents the silent growth pattern from surprising the buyer at the next audit notice.

Three counting traps produce most of the exposure observed across OpenShift Serverless engagements in the trailing twelve months.

The first trap is the burst capacity that read on review as the steady state size. The cluster autoscaler grew worker nodes during a load spike, the audit window captured the post spike cluster size, and the platform line at signature did not absorb the spike. The mitigation is the burst capacity band at signature.

The second trap is the eventing broker that scaled silently. The eventing broker workload grew as event throughput grew, the broker consumed an increasing share of cluster capacity, and the cluster cores rose to accommodate. The audit reads the cluster at its current size; the signature carried the original. A documented broker capacity plan, reviewed quarterly, closes the silent growth.

The third trap is the serverless operator left enabled on a cluster after the workload migrated to a hyperscaler function service. The operator state on the cluster is the audit signal that serverless was in use. A formal operator removal on the migration date closes the attribution at the migration date rather than at the next renewal.

OpenShift Serverless is read through the platform line on the clusters where the Knative serving or Knative eventing operator is installed. The buyer who reads only the steady state cluster size, without checking the burst behaviour and the eventing broker capacity, signs a renewal that may not absorb the live workload pattern.

The discipline at signature sets four protections that hold across the term. The cluster footprint that runs the serverless operators is named in the contract record. The burst capacity for scale up driven workloads is priced into the platform line through an expansion band. The eventing broker capacity plan is documented so silent growth does not become an audit event. A quarterly operator inventory captures serverless operator state across the fleet so a workload that migrated to a hyperscaler function service does not continue to carry the attribution.

For the broader cross product reading, see the OpenShift practice hub, the Pipelines entitlement, the Service Mesh read, the sandboxed containers entitlement on the same clusters, and the RHEL image mode read when image mode underpins the serverless runtime. For the engagement protocol, see contact.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.