openshift · eromanova97 · Mar 31, 2026 · Mar 29, 2026
diff --git a/.../serverless-integrating-service-mesh/serverless-integrating-ossm-3-x-setup.adoc b/.../serverless-integrating-service-mesh/serverless-integrating-ossm-3-x-setup.adoc
@@ -7,39 +7,15 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-The {ServerlessOperatorName} provides Kourier as the default ingress for Knative. However, you can use {SMProductShortName} with {ServerlessProductName} whether Kourier is enabled or not. Integrating with Kourier disabled allows you to configure additional networking and routing options that the Kourier ingress does not support, such as mTLS functionality.
+The {ServerlessOperatorName} uses Kourier as the default ingress for Knative. You can use {SMProductShortName} with {ServerlessProductName} whether you enable Kourier or disable it. If you disable Kourier, you can configure additional networking and routing options that Kourier does not support, such as mTLS.
 
-Note the following assumptions and limitations:
+include::modules/serverless-ossm-integration-3-x-assumption-limitations.adoc[leveloffset=+1]
 
-* All Knative internal components, as well as Knative Services, are part of the {SMProductShortName} and have sidecars injection enabled. This means that strict mutual Transport Layer Security (mTLS) is enforced within the whole mesh. All requests to Knative Services require an mTLS connection, with the client having to send its certificate, except calls coming from OpenShift Routing.
-
-* {ServerlessProductName} with {SMProductShortName} integration can only target one service mesh. Multiple meshes can be present in the cluster, but {ServerlessProductName} is only available on one of them.
-
-[id="prerequisites_serverless-integrating-ossm-3-x-setup"]
-== Prerequisites
-
-* You have access to an {product-title} account with cluster administrator access.
-
-* You have installed the OpenShift CLI (`oc`).
-
-* You have installed the {ServerlessProductShortName} Operator.
-
-* You have installed the {SMProductName} 3.x Operator.
-
-* The examples in the following procedures use the domain `example.com`. The example certificate for this domain is used as a certificate authority (CA) that signs the subdomain certificate.
-+
-To complete and verify these procedures in your deployment, you need either a certificate signed by a widely trusted public CA or a CA provided by your organisation. Example commands must be adjusted according to your domain, subdomain, and CA.
-
-* You must configure the wildcard certificate to match the domain of your {ocp-product-title} cluster. For example, if your {ocp-product-title} console address is `https://console-openshift-console.apps.openshift.example.com`, you must configure the wildcard certificate so that the domain is `*.apps.openshift.example.com`. For more information, see _Creating a certificate to encrypt incoming external traffic_.
-
-* If you want to use any domain name, including those which are not subdomains of the default {ocp-product-title} cluster domain, you must set up a domain mapping for those domains. For more information, see xref:../../knative-serving/config-custom-domains/create-domain-mapping.adoc#serverless-create-domain-mapping_create-domain-mapping[Creating a custom domain mapping {ServerlessProductName} documentation].
+include::modules/serverless-ossm-integration-prereqs-3-x-setup.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-external-certs.adoc[leveloffset=+1]
 
-[id="configuring-verifying-ossm-3-x-integration-with-serverless"]
-== Configuring and verifying {SMProductShortName} 3.x integration with {ServerlessProductName}
-
-You can integrate {SMProductShortName} 3.x with {ServerlessProductName} to enable advanced traffic management, security, and observability for your serverless applications. This section provides the steps to verify prerequisites, install and configure both components, and confirm that the integration is functioning as expected.
+include::modules/configure-verify-ossm-3-x-serverless-integration.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-verifying-installation-prerequisites.adoc[leveloffset=+2]
 
@@ -50,3 +26,8 @@ include::modules/serverless-ossm-installing-and-configuring-openshift-serverless
 include::modules/serverless-ossm-verifying-the-ossm-3-x-integration.adoc[leveloffset=+2]
 
 include::modules/serverless-ossm-disabling-network-policies.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+== Additional resources
+
+* xref:../../knative-serving/config-custom-domains/create-domain-mapping.adoc#serverless-create-domain-mapping_create-domain-mapping[Creating a custom domain mapping {ServerlessProductName} documentation]
diff --git a/integrations/serverless-integrating-service-mesh/serverless-ossm-setup.adoc b/integrations/serverless-integrating-service-mesh/serverless-ossm-setup.adoc
@@ -7,62 +7,37 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-The {ServerlessOperatorName} provides Kourier as the default ingress for Knative. However, you can use {SMProductShortName} with {ServerlessProductName} whether Kourier is enabled or not. Integrating with Kourier disabled allows you to configure additional networking and routing options that the Kourier ingress does not support, such as mTLS functionality.
+The {ServerlessOperatorName} uses Kourier as the default ingress for Knative. You can use {SMProductShortName} with {ServerlessProductName} whether you enable Kourier or disable it. If you disable Kourier, you can configure additional networking and routing options, such as mTLS that Kourier does not support.
 
-Note the following assumptions and limitations:
+include::modules/serverless-ossm-integration-assumption-limitations.adoc[leveloffset=+1]
 
-* All Knative internal components, and Knative Services, are part of the {SMProductShortName} and have sidecars injection enabled. This means that strict mTLS is enforced within the whole mesh. All requests to Knative Services require an mTLS connection, with the client having to send its certificate, except calls coming from OpenShift Routing.
-
-* {ServerlessProductName} with {SMProductShortName} integration can only target *one* service mesh. Multiple meshes can be present in the cluster, but {ServerlessProductName} is only available on one of them.
-
-* Changing the target `ServiceMeshMemberRoll` that {ServerlessProductName} is part of, meaning moving {ServerlessProductName} to another mesh, is not supported. The only way to change the targeted Service mesh is to uninstall and reinstall {ServerlessProductName}.
-
-[id="prerequisites_serverless-ossm-setup"]
-== Prerequisites
-
-* You have access to an {product-title} account with cluster administrator access.
-
-* You have installed the OpenShift CLI (`oc`).
-
-* You have installed the {ServerlessProductShortName} Operator.
-
-* You have installed the {SMProductName} 2.x Operator.
-
-* The examples in the following procedures use the domain `example.com`. The example certificate for this domain is used as a certificate authority (CA) that signs the subdomain certificate.
-+
-To complete and verify these procedures in your deployment, you need either a certificate signed by a widely trusted public CA or a CA provided by your organization. Example commands must be adjusted according to your domain, subdomain, and CA.
-
-* You must configure the wildcard certificate to match the domain of your {ocp-product-title} cluster. For example, if your {ocp-product-title} console address is `https://console-openshift-console.apps.openshift.example.com`, you must configure the wildcard certificate so that the domain is `*.apps.openshift.example.com`. For more information about configuring wildcard certificates, see the following topic about _Creating a certificate to encrypt incoming external traffic_.
-
-* If you want to use any domain name, including those which are not subdomains of the default {ocp-product-title} cluster domain, you must set up domain mapping for those domains. For more information, see the {ServerlessProductName} documentation about xref:../../knative-serving/config-custom-domains/create-domain-mapping.adoc#serverless-create-domain-mapping_create-domain-mapping[Creating a custom domain mapping].
-
-[IMPORTANT]
-====
-{ServerlessProductName} only supports the use of {SMProductName} functionality that is explicitly documented in this guide, and does not support other undocumented features.
-
-Using {ServerlessProductShortName} 1.31 with {SMProductShortName} is only supported with {SMProductShortName} version 2.2 or later. For details and information about versions other than 1.31, see the "Red Hat OpenShift Serverless Supported Configurations" page.
-====
+include::modules/serverless-ossm-integration-prereqs-2-x-setup.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-external-certs.adoc[leveloffset=+1]
 
-// without kourier
-[id="serverless-ossm-setup_integrating-ossm-with-serverless"]
-== Integrating {SMProductShortName} with {ServerlessProductName}
-
-You can integrate {SMProductShortName} 2.x with {ServerlessProductName} to enable advanced traffic management, security, and observability for your serverless applications. This section provides the steps to verify prerequisites, install and configure both components, and confirm that the integration is functioning as expected.
+include::modules/serverless-ossm-integration-2-x-with-serverless.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-verifying-installation-prerequisites.adoc[leveloffset=+2]
+
 include::modules/serverless-ossm-installing-and-configuring-openshift-service-mesh.adoc[leveloffset=+2]
+
 include::modules/serverless-ossm-installing-and-configuring-openshift-serverless.adoc[leveloffset=+2]
+
 include::modules/serverless-ossm-verifying-the-integration.adoc[leveloffset=+2]
 
 include::modules/serverless-ossm-enabling-serving-metrics.adoc[leveloffset=+1]
+
 include::modules/serverless-ossm-disabling-network-policies.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-secret-filtering-net-istio.adoc[leveloffset=+1]
 
-[id="additional-resources_serverless-ossm-setup"]
 [role="_additional-resources"]
 == Additional resources
+
 * link:https://access.redhat.com/articles/4912821[Red Hat OpenShift Serverless Supported Configurations]
+
 * xref:../../knative-serving/kourier-and-istio-ingresses.adoc#kourier-and-istio-ingresses[Kourier and Istio ingresses]
+
+* xref:../../knative-serving/config-custom-domains/create-domain-mapping.adoc#serverless-create-domain-mapping_create-domain-mapping[Creating a custom domain mapping]
+
+* link:https://www.plural.sh/blog/manage-kubernetes-events-informers/[Informers]
diff --git a/...ions/serverless-integrating-service-mesh/serverless-ossm-traffic-isolation.adoc b/...ions/serverless-integrating-service-mesh/serverless-ossm-traffic-isolation.adoc
@@ -9,11 +9,7 @@ toc::[]
 [role="_abstract"]
 You can use {SMProductShortName} 2.x with {ServerlessProductName} to control and isolate network traffic between services. This integration helps you define fine-grained communication policies, enhance security through mutual TLS, and manage traffic flow within your serverless environment.
 
-:FeatureName: Using {SMProductShortName} to isolate network traffic with {ServerlessProductName}
-include::snippets/technology-preview.adoc[leveloffset=+2]
-:!FeatureName:
-
-{SMProductShortName} can be used to isolate network traffic between tenants on a shared {product-title} cluster by using Service Mesh `AuthorizationPolicy` resources. {ServerlessProductShortName} can also use this, using several {SMProductShortName} resources. A tenant is a group of one or multiple projects that can access each other over the network on a shared cluster.
+include::modules/serverless-ossm-network-traffic-isolation.adoc[leveloffset=+1]
 
 include::modules/serverless-ossm-traffic-isolation-architecture.adoc[leveloffset=+1]
 

diff --git a/modules/configure-verify-ossm-3-x-serverless-integration.adoc b/modules/configure-verify-ossm-3-x-serverless-integration.adoc
@@ -0,0 +1,10 @@
+// Module included in the following assemblies:
+//
+// * /serverless/integrations/serverless-integrating-ossm-3-x-setup.adoc
+
+:_mod-docs-content-type: REFERENCE
+[id="configure-verify-ossm-3-x-serverless-integration_{context}"]
+= Configure and verify {SMProductShortName} 3.x integration with {ServerlessProductName}
+
+[role="_abstract"]
+Integrate {SMProductShortName} 3.x with {ServerlessProductName} to enable advanced traffic management, security, and observability for serverless applications. Verify prerequisites, install and configure both components, and then verify the integration.
diff --git a/modules/serverless-ossm-disabling-network-policies.adoc b/modules/serverless-ossm-disabling-network-policies.adoc
@@ -43,7 +43,8 @@ The {ServerlessOperatorName} generates the required network policies by default.
 $ oc edit KnativeEventing -n knative-eventing
 ----
 +
-.Example `KnativeEventing` CR
+You get an output similar to the following example:
++
 [source,yaml]
 ----
 apiVersion: operator.knative.dev/v1beta1
@@ -62,7 +63,8 @@ metadata:
 $ oc edit KnativeServing -n knative-serving
 ----
 +
-.Example `KnativeServing` CR
+You get an output similar to the following example:
++
 [source,yaml]
 ----
 apiVersion: operator.knative.dev/v1beta1

diff --git a/modules/serverless-ossm-enabling-serving-metrics.adoc b/modules/serverless-ossm-enabling-serving-metrics.adoc
@@ -4,10 +4,10 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="serverless-ossm-enabling-serving-metrics_{context}"]
-= Enabling Knative Serving and Knative Eventing metrics when using Service Mesh with mTLS
+= Enabling Knative Serving and Knative Eventing metrics when using {SMProductShortName} with mTLS
 
 [role="_abstract"]
-If Service Mesh is enabled with Mutual Transport Layer Security (mTLS), metrics for Knative Serving and Knative Eventing are disabled by default, because Service Mesh prevents Prometheus from scraping metrics. You can enable Knative Serving and Knative Eventing metrics when using Service Mesh and mTLS.
+If you enable {SMProductShortName} with Mutual Transport Layer Security (mTLS), {SMProductShortName} prevents Prometheus from scraping metrics. As a result, Knative Serving and Knative Eventing metrics are unavailable by default. You can enable these metrics when you use {SMProductShortName} with mTLS.
 
 .Prerequisites
 
@@ -62,7 +62,7 @@ spec:
 ...
 ----
 
-. Modify and reapply the default Service Mesh control plane in the `istio-system` namespace, so that it includes the following spec:
+. Change and reapply the default Service Mesh control plane in the `istio-system` namespace, so that it includes the following spec:
 +
 [source,yaml]
 ----

diff --git a/modules/serverless-ossm-installing-and-configuring-openshift-serverless.adoc b/modules/serverless-ossm-installing-and-configuring-openshift-serverless.adoc
@@ -9,7 +9,8 @@ After installing {SMProductShortName}, you need to install {ServerlessProductSho
 
 . Install Knative Serving with the following `KnativeServing` custom resource, which enables the Istio integration:
 +
-.Example `knative-serving-config.yaml` configuration file
+You get an output similar to the following example:
++
 [source,yaml]
 ----
 apiVersion: operator.knative.dev/v1beta1
@@ -22,8 +23,8 @@ metadata:
 spec:
   ingress:
     istio:
-      enabled: true <1>
-  deployments: <2>
+      enabled: true
+  deployments:
   - name: activator
     labels:
       "sidecar.istio.io/inject": "true"
@@ -35,15 +36,16 @@ spec:
     annotations:
       "sidecar.istio.io/rewriteAppHTTPProbers": "true"
   config:
-    istio: <3>
-      gateway.knative-serving.knative-ingress-gateway: istio-ingressgateway.<your-istio-namespace>.svc.cluster.local
-      local-gateway.knative-serving.knative-local-gateway: knative-local-gateway.<your-istio-namespace>.svc.cluster.local
+    istio:
+      gateway.knative-serving.knative-ingress-gateway: istio-ingressgateway.<your_istio_namespace>.svc.cluster.local
+      local-gateway.knative-serving.knative-local-gateway: knative-local-gateway.<your_istio_namespace>.svc.cluster.local
 ----
-<1> Enable Istio integration.
-<2> Enable sidecar injection for Knative Serving data plane pods.
-<3> If your istio is not running in the `istio-system` namespace, you need to set these two flags with the correct namespace.
 
-. Apply the `KnativeServing` resource:
+`enabled: true`:: Enable Istio integration.
+`deployments`:: Enable sidecar injection for Knative Serving data plane pods.
+`config.istio`:: If your istio is not running in the `istio-system` namespace, you need to set these two flags with the correct namespace.
+
+. Apply the `KnativeServing` resource by running the following command::
 +
 [source,terminal]
 ----
@@ -52,7 +54,8 @@ $ oc apply -f knative-serving-config.yaml
 
 . Install Knative Eventing with the following `KnativeEventing` object, which enables the Istio integration:
 +
-.Example `knative-eventing-config.yaml` configuration file
+You get an output similar to the following example:
++
 [source,yaml]
 ----
 apiVersion: operator.knative.dev/v1beta1
@@ -97,10 +100,11 @@ spec:
       annotations:
         sidecar.istio.io/rewriteAppHTTPProbers: "true"
 ----
-* `spec.config.features.istio` enables Eventing Istio controller to create a `DestinationRule` for each `InMemoryChannel` or `KafkaChannel` service.
-* `spec.workload` enables sidecar injection for Knative Eventing pods.
 
-. Apply the `KnativeEventing` resource:
+`spec.config.features.istio`:: enables Eventing Istio controller to create a `DestinationRule` for each `InMemoryChannel` or `KafkaChannel` service.
+`spec.workload`:: enables sidecar injection for Knative Eventing pods.
+
+. Apply the `KnativeEventing` resource by running the following command::
 +
 [source,terminal]
 ----
@@ -109,7 +113,8 @@ $ oc apply -f knative-eventing-config.yaml
 
 . Install Knative Kafka with the following `KnativeKafka` custom resource, which enables the Istio integration:
 +
-.Example `knative-kafka-config.yaml` configuration file
+You get an output similar to the following example:
++
 [source,yaml]
 ----
 apiVersion: operator.serverless.openshift.io/v1alpha1
@@ -120,18 +125,18 @@ metadata:
 spec:
   channel:
     enabled: true
-    bootstrapServers: <bootstrap_servers> <1>
+    bootstrapServers: <bootstrap_servers>
   source:
     enabled: true
   broker:
     enabled: true
     defaultConfig:
-      bootstrapServers: <bootstrap_servers> <1>
+      bootstrapServers: <bootstrap_servers>
       numPartitions: <num_partitions>
       replicationFactor: <replication_factor>
     sink:
       enabled: true
-  workloads: <2>
+  workloads:
   - name: kafka-controller
     labels:
       "sidecar.istio.io/inject": "true"
@@ -168,10 +173,11 @@ spec:
     annotations:
       "sidecar.istio.io/rewriteAppHTTPProbers": "true"
 ----
-<1> The Apache Kafka cluster URL, for example `my-cluster-kafka-bootstrap.kafka:9092`.
-<2> Enable sidecar injection for Knative Kafka pods.
 
-. Apply the `KnativeEventing` object:
+`bootstrapServers: <bootstrap_servers>`:: The Apache Kafka cluster URL, for example `my-cluster-kafka-bootstrap.kafka:9092`.
+`spec.workloads`:: Enable sidecar injection for Knative Kafka pods.
+
+. Apply the `KnativeEventing` object by running the following command::
 +
 [source,terminal]
 ----
@@ -180,7 +186,8 @@ $ oc apply -f knative-kafka-config.yaml
 
 . Install `ServiceEntry` to inform {SMProductShortName} of the communication between `KnativeKafka` components and an Apache Kafka cluster:
 +
-.Example `kafka-cluster-serviceentry.yaml` configuration file
+You get an output similar to the following example:
++
 [source,yaml]
 ----
 apiVersion: networking.istio.io/v1alpha3
@@ -189,11 +196,11 @@ metadata:
   name: kafka-cluster
   namespace: knative-eventing
 spec:
-  hosts: <1>
+  hosts:
     - <bootstrap_servers_without_port>
   exportTo:
     - "."
-  ports: <2>
+  ports:
     - number: 9092
       name: tcp-plain
       protocol: TCP
@@ -212,15 +219,16 @@ spec:
   location: MESH_EXTERNAL
   resolution: NONE
 ----
-<1> The list of Apache Kafka cluster hosts, for example `my-cluster-kafka-bootstrap.kafka`.
-<2> Apache Kafka cluster listeners ports.
+
+`spec.hosts`:: The list of Apache Kafka cluster hosts, for example `my-cluster-kafka-bootstrap.kafka`.
+`spec.ports`:: Apache Kafka cluster listeners ports.
 +
 [NOTE]
 ====
-The listed ports in `spec.ports` are example TPC ports. The actual values depend on how the Apache Kafka cluster is configured.
+The ports listed in `spec.ports` are example TCP (Transmission Control Protocol) ports. The actual values depend on the Apache Kafka cluster configuration.
 ====
 
-. Apply the `ServiceEntry` resource:
+. Apply the `ServiceEntry` resource by running the following command:
 +
 [source,terminal]
 ----