OpenShift Service Mesh, counted on the cluster.

Red Hat OpenShift Service Mesh is the productised Red Hat release of the upstream Istio project, packaged as a cluster operator on Red Hat OpenShift Container Platform. The mesh installs through the OpenShift Service Mesh operator, brings in the Kiali and Jaeger operators alongside it, and registers a control plane that governs the sidecars injected into the application pods1. The buyer reading the renewal line for OpenShift Service Mesh is reading an entitlement that attaches to the cluster where the operator is installed, not a feature of every OpenShift cluster in the estate.

The mesh in 2026 sits inside the OpenShift platform entitlement on the bundled tiers and reads as part of the per core line for the clusters in scope. On the standalone OpenShift Container Platform tier the mesh is included as a value added operator with no separate entitlement charge, but the audit posture still reads which clusters host the mesh and which do not. A buyer who installs the mesh on twelve of twenty clusters carries a mesh footprint of twelve clusters; the eight clusters without the operator do not carry the mesh in any audit reading.

The mesh entitlement should not be confused with the third party telemetry and observability backends that often sit alongside it. The Kiali and Jaeger operators are part of the Red Hat line. A separate commercial Datadog, Dynatrace, or New Relic install that ingests mesh telemetry carries its own commercial agreement with that vendor and is not part of the OpenShift Service Mesh reading.

The mesh entitlement footprint expands quietly through three operator patterns that the platform team often does not flag at the renewal table. The first pattern is the multi cluster mesh that federates control planes across two or more OpenShift clusters. A federated control plane installs the operator on every member cluster, and the entitlement footprint becomes the union of every cluster in the federation, not the cluster that hosts the primary control plane. The mesh on three federated clusters reads on the cores of three clusters.

The second pattern is the mesh evaluation that became permanent. A platform team installs the Service Mesh operator on a non production cluster for a proof of concept, the proof of concept produces a working mesh, the team migrates one or two production workloads onto the mesh, and the original evaluation cluster keeps the operator installed indefinitely. The mesh footprint on review reads both clusters. The operator state on the evaluation cluster carries the mesh attribution regardless of whether the proof of concept workload still runs there.

The third pattern is the ingress gateway extension. Red Hat OpenShift Service Mesh installs ingress and egress gateway pods that often run on dedicated worker nodes for traffic isolation. The dedicated gateway nodes carry the mesh entitlement on their cores even when the application workloads they front are not themselves in the mesh. A buyer who scaled gateway nodes to handle north south traffic pays the mesh line on the gateway node cores in addition to the cores that host the sidecar injected applications.

On the OpenShift Plus bundle the mesh sits inside the bundle entitlement for the cluster footprint where the bundle is purchased. The renewal table reads the bundle on the bundle clusters and the standalone platform line on any cluster outside the bundle scope. A buyer who deployed the mesh on bundle clusters reads the mesh inside the bundle line. A buyer who deployed the mesh on a cluster outside the bundle scope carries the mesh as a separate entitlement question for that cluster.

The trap inside the bundle is the bundle that is purchased across the entire OpenShift estate to cover one or two products in the bundle that the buyer plans to use. The mesh comes along inside the bundle scope at no incremental charge for the bundle clusters, but the bundle as a whole prices materially higher than the standalone OpenShift platform line on those clusters. A bundle purchased only to enable the mesh on three clusters can read as a higher renewal than the same three clusters on standalone OpenShift Container Platform with the mesh operator simply installed at no additional charge.

The reading at signature should name which clusters carry the mesh in production, which clusters carry the mesh as an evaluation, and which clusters are not in the mesh footprint at all. A subscription assessment in the ninety days before renewal produces the cluster by cluster operator inventory the line needs.

Three counting traps produce most of the audit exposure observed across OpenShift Service Mesh engagements in the trailing twelve months. Each is structural rather than situational and each is addressable at signature.

The first trap is the operator left enabled on legacy clusters. The Service Mesh operator state on a cluster is the audit signal that the mesh was in use, and an operator that was installed for an old project and never formally removed carries the mesh attribution on that cluster until the operator is uninstalled. The discipline is to track operator state across the cluster fleet quarterly and to formally remove operators that are not in production use4.

The second trap is the federated mesh that grew. A buyer who started with one federated mesh across two clusters and federated a third and fourth cluster across the contract term carries the mesh footprint across all federated clusters at audit. The original signature counted two clusters; the audit reads four. The expansion mechanics should be priced and named in the contract at signature so the federation can grow without a renegotiation under audit pressure.

The third trap is the dedicated gateway node footprint. Gateway nodes scale with north south traffic and tend to grow faster than the application workload footprint. A buyer who sized the mesh against the application core count and ignored the gateway node cores misreads the mesh footprint by the gateway scale factor, which can be ten to thirty percent of the cluster cores on a heavily trafficked cluster. Gateway node cores should be named in the mesh scope at signature or the audit reads them at the higher number.

The mesh line is read together with the OpenShift Container Platform line for the same clusters and, when present, with the bundle line for the bundle scope. The buyer who reads only the platform line signs the mesh scope without reading it. The discipline at the renewal table sets four protections that hold across the term.

The cluster footprint that carries the mesh is named in the contract record. The mesh scope is decoupled from the platform scope in the contract language so the mesh attribution cannot expand to clusters added later for non mesh workloads. The federation scope, if any, is named with expansion mechanics so federated growth does not become an audit event. A quarterly operator inventory captures Service Mesh operator state across every cluster so the audit notice arrives against a record the buyer can produce on demand.

The protections do not require the buyer to forecast mesh growth precisely. They require the buyer to forecast mesh growth deliberately and to write the forecast into the contract scope. For the broader cross product reading, see the OpenShift practice hub, the related work on Pipelines and Tekton , the GitOps entitlement , the logging stack on the same cluster, and the 3scale API management read when the mesh fronts a managed API surface. 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.