Red Hat maps the isolation choices for multiple SAP integration runtimes on OpenShift

Red Hat has published a detailed deployment guide for running multiple SAP Edge Integration Cell (EIC) instances on one OpenShift cluster. The useful part is not simply that several runtimes fit on one cluster; it is the guide’s boundary map for what operators can share, what they must isolate and what remains a cluster-wide concern.

Two deployment models

The first model registers one SAP Edge Node and deploys multiple EIC instances beneath it. Those instances use separate application namespaces and isolated backing services, but share one Edge Lifecycle Management (ELM) installation and one Istio control plane. Red Hat positions this model for teams willing to coordinate ELM and service-mesh maintenance across the runtimes.

The second model registers multiple Edge Nodes on the same OpenShift cluster. Each registration gets its own ELM installation, namespace set and Istio control plane. Red Hat lists ELM 1.64 and EIC 8.48 as the minimum releases for this topology. The OpenShift cluster, Service Mesh Operator and Istio CNI still remain shared infrastructure.

That distinction matters operationally: separate meshes isolate control-plane configuration and namespace discovery, but they do not create independent cluster failure domains or complete network isolation. Red Hat explicitly warns that service-mesh discovery selectors are not a security boundary.

Isolation extends beyond namespaces

Each EIC instance needs isolated backing services under either topology. The guide calls for a separate database or schema per instance, where the chosen database supports it, and a separate Redis or Valkey instance for every EIC runtime.

The guide also requires SAP’s restricted-access onboarding method when a cluster will host multiple EIC instances. ELM generates the Kubernetes resources for each operation, while administrators apply those resources and reconcile OpenShift security context constraint annotations and Istio labels before continuing the deployment.

For dedicated meshes, operators must make discovery selectors non-overlapping, keep workload namespaces on the correct active Istio revision and avoid injection labels on secrets namespaces. Changing namespace labels alone does not move already-running pods to another control plane, so verification must include the sidecars used by running workloads.

What platform teams should decide

The practical choice is between shared maintenance and stronger lifecycle separation. A single Edge Node reduces ELM and mesh overhead but couples maintenance across its EIC instances. Multiple Edge Nodes let teams plan ELM and mesh work independently, while still requiring coordination for cluster-scoped resources such as operators, CNI components and custom resource definitions.

Before deploying, teams should settle ownership for ELM, mesh upgrades and backing services—not merely choose namespace names. Red Hat’s verification commands inventory Istio control planes and revisions, compare namespace ownership and mesh labels, and check that representative integration traffic reaches the intended runtime. That turns the article from a conceptual topology note into an actionable runbook.