Deploying Multiple SAP Edge Integration Cell Instances on One OpenShift Cluster

Part of: SAP Edge Integration Cell on Red Hat OpenShift

Table of Contents

• Overview and Prerequisites
• Choose a Deployment Model
• Namespaces and Resource Application
• Scenario 1: One Edge Node with Multiple EIC Instances
• Scenario 2: Multiple Edge Nodes with Dedicated Meshes
• Upgrades and Removal
• Verify the Deployment

Overview and Prerequisites

An OpenShift cluster can host multiple SAP Edge Integration Cell (EIC) instances using two deployment models: multiple EIC instances under one Edge Node, or separate Edge Nodes with their own ELM installations and dedicated service meshes. This guide explains how to organize those deployments and their shared resources.

Required onboarding method: For both models, onboard every Edge Node using Restricted Access to Kubernetes Cluster. SAP limits other onboarding methods to one EIC instance per cluster. See Plan Your Setup of Edge Integration Cell.

Here, Edge Node means a registration in SAP Edge Lifecycle Management (ELM), not an OpenShift worker node. An ELM installation means the ELM components deployed inside the cluster for that registration. Each EIC instance is a separate solution deployment and runtime location; increasing pod replicas within one instance is a separate availability and scaling decision.

Use this guide with the restricted-access setup guide, which provides the resource application, service account, SCC, and OpenShift Service Mesh 3.x procedures. The procedures use an administrator-managed mesh.

Minimum releases for multiple Edge Nodes on one cluster: ELM 1.64 and EIC 8.48. Use these releases or later compatible versions, with a separate ELM namespace and dedicated mesh for each Edge Node.

SAP's EIC deployment instructions describe custom namespaces and additional EIC instances on an existing Edge Node. Check the applicable ELM release documentation, SAP Note 3618713, and the platform compatibility references for the releases being deployed.

Choose a Deployment Model

EIC quota: The deployment topology does not change SAP EIC quota consumption. The same EIC instances consume the same quota whether they share one Edge Node and mesh or run on separate Edge Nodes with dedicated meshes. Confirm the applicable EIC quota and entitlement requirements for your planned deployment with SAP.

Backing service isolation: Each EIC instance requires isolated backing services, whether the EIC instances run in the same Kubernetes cluster or in separate clusters.

• Database: Use a separate schema or database for each EIC instance, as supported by the selected database.
• Data store (Redis or Valkey): Use a separate Redis or Valkey instance for each EIC instance. These data stores do not provide equivalent schema-level isolation for this use case.

Follow SAP's EIC deployment instructions for the database and data store configuration.

Choose the first model when shared management and mesh maintenance suit the applications. Choose the second when each Edge Node needs its own ELM and mesh lifecycle. One EIC instance per Edge Node is a straightforward starting point for the second model; additional EIC instances share that Edge Node's dedicated mesh.

Both models share the OpenShift cluster and its infrastructure. Dedicated meshes separate control plane configuration and namespace discovery, but do not provide a separate cluster failure domain or complete network isolation. Apply the required network and access policies for the workloads; Red Hat documents that discovery selectors are not a security boundary.

Namespaces and Resource Application

The namespaces for edge components deployed on OpenShift are configurable in the Edge Lifecycle Management (ELM) user interface. Once configured, ELM generates downloadable Kubernetes resources that reference those customized namespaces. Download and apply the generated bundle for the relevant Edge Node and operation.

Follow the restricted-access setup guide to initialize each Edge Node and deploy its EIC instances in turn. For each operation, download the generated resource bundle and run its supplied apply-restricted-resources.sh script to create or update the required resources, including namespaces and RBAC.

After the script completes, apply the required SCC annotations and Istio labels to the relevant namespaces as described in the setup guide. Ensure the labels select the intended mesh for that Edge Node before continuing in ELM. For multiple Edge Nodes, each Edge Node's namespaces must use its own dedicated mesh settings.

SCC ranges are reused per component across instances. For example, the EIC namespaces of instances A and B use the same EIC UID and supplemental-group ranges; their EIC Services namespaces use the same Services ranges. Apply the component-specific SCC annotation values from the setup guide to each corresponding namespace. Separate EIC instances or Edge Nodes do not require separate SCC ranges.

The generated bundle and its apply script already use the namespaces configured in ELM; no manual namespace substitution is required when applying the bundle. ELM automatically manages each EIC instance's dependent components and their relationships.

Scenario 1: One Edge Node with Multiple EIC Instances

Register the cluster once and deploy multiple EIC instances under that Edge Node. All instances use the same Istio control plane.

The mesh is shared within the Edge Node. It can still be dedicated to this SAP deployment, excluding unrelated applications on the cluster. Each EIC instance has its own runtime identity and application namespace set.

1. Prepare the mesh and initialize one Edge Node. Follow the restricted-access setup guide.
2. Deploy the first EIC instance. Select its deployment name and namespaces in ELM. Apply the requested bundle and configure SCC annotations and mesh labels before continuing.
3. Deploy the next EIC instance on the same Edge Node. Choose another deployment name and separate application namespaces. Assign the new instance's namespaces to the same mesh.
4. Configure instance-specific endpoints and isolated backing services. Apply the backing service isolation requirements above. Follow SAP's EIC deployment instructions for each instance's endpoint, certificate, keystore, connectivity, database, and data store settings.
5. Apply and verify each requested resource update. Download the bundle for the particular deployment and operation. Reconcile every affected namespace with the same mesh configuration, then continue in ELM.

ELM and mesh maintenance can affect all EIC instances on this Edge Node. Coordinate this maintenance across those instances.

Scenario 2: Multiple Edge Nodes with Dedicated Meshes

Register separate Edge Nodes on the same OpenShift cluster, each with its own ELM installation, namespace ownership, and Istio control plane. The example deploys one EIC instance per Edge Node.

An additional EIC instance on Edge Node A joins mesh A. It does not use mesh B. Likewise, Edge Node B's ELM, gateway, and application namespaces remain assigned to mesh B.

Example Namespace and Mesh Plan

These names illustrate the selections to make in SAP and OpenShift configuration. They are not a replacement for the generated resource bundles.

Obtain each injection revision from the running control plane; do not assume that it always equals the Istio resource name. Recheck the active revision when upgrading the mesh.

Deployment Sequence

1. Prepare the shared cluster infrastructure once. Follow the Operator installation and the CNI setup commands at the start of Step 2. Reuse the Operator and cluster-wide Istio CNI for all dedicated meshes. Create the dedicated control planes in the following steps.
2. Create a dedicated mesh for Edge Node A. Follow the dedicated mesh procedure, substituting the control plane namespace, Istio resource name, and discovery value from the plan. Include any required corporate proxy configuration. Wait for the control plane to be ready.
3. Initialize Edge Node A with restricted access. Use its own ELM namespace and the bundle generated for its registration. After applying the bundle, configure SCC annotations and assign the ELM namespace to mesh A before completing initialization. Generate the runtime kubeconfig for the service account and namespace referenced by that bundle's RBAC.
4. Deploy EIC A. Configure its component namespaces and isolated backing services in ELM, following the backing service isolation requirements above. Apply its requested bundle, configure SCC annotations, and assign its namespaces to mesh A before continuing deployment.
5. Repeat for Edge Node B. Create mesh B, initialize a separate Edge Node with its own ELM namespace and kubeconfig, and deploy EIC B with separate namespaces. Reuse the cluster's Operator and CNI rather than installing another copy.

Keep bootstrap files, kubeconfigs, and resource downloads separate for each registration. The Kubernetes API endpoint can be the same while the Edge Node identity, namespace permissions, and runtime credentials differ.

Keep Mesh Assignments Separate

Configure each control plane's discoverySelectors to match only that Edge Node's namespace label value. Also inspect other control planes already on the cluster: a control plane with unrestricted discovery can still discover namespaces assigned to another mesh. Red Hat's multiple-mesh procedure describes this configuration.

After every bundle application, follow Assign SAP Namespaces to the Dedicated Mesh with the names and revision for the affected Edge Node. Apply discovery labels to its namespaces and revision-based injection to its workload namespaces. Keep the EIC secrets namespaces without injection-enabling labels, and remove any restored istio-injection labels before continuing in ELM. Preserve SAP ownership labels.

Create gateway Routes in the gateway namespace for the corresponding Edge Node. Apply corporate proxy ServiceEntries and other required mesh configuration within each dedicated mesh. A configuration present in mesh A should not be assumed to configure mesh B.

Upgrades and Removal

Use ELM to upgrade or remove an EIC instance; ELM handles its dependent components automatically. The scope of ELM, mesh, and cluster maintenance differs between the models:

After you initiate an upgrade, ELM changes the operation to Prepared and pauses if updated Kubernetes resources are required. Download the resources for that operation, apply them with the supplied script, reconcile SCC annotations and the appropriate mesh labels, and then resume in ELM. If no resource changes are needed, the upgrade proceeds without that manual step. Follow the resource update procedure.

Apply the complete bundle requested by ELM, including resources for dependent components, and configure OpenShift settings for all affected namespaces. Separate meshes do not make cluster-scoped resources, such as CRDs, independent: coordinate changes and use compatible component versions across the cluster.

Do not bulk-delete namespaces using only the product label edgelm.sap.com/product=edgelm; that label can select namespaces from several Edge Nodes. Remove a dedicated mesh only after ELM has completed removal of the Edge Node's deployments and the mesh is no longer in use. Retain the shared Operator and CNI while other meshes use them.

Verify the Deployment

Run these read-only checks with administrator access to the cluster:

# Inventory control planes, revisions, and the shared CNI.
oc get istios.sailoperator.io
oc get istiorevisions.sailoperator.io
oc get istiocni.sailoperator.io

# Inspect all discovery selectors, including those on pre-existing meshes.
oc get istios.sailoperator.io \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.namespace}{"\t"}{.spec.values.meshConfig.discoverySelectors}{"\n"}{end}'

# Compare namespace ownership and mesh assignments.
oc get namespaces \
  -L edgelm.sap.com/edge-node-id,istio-discovery,istio.io/rev,istio-injection

For each Edge Node, verify that its ELM and solution namespaces retain the correct ownership and belong to the intended mesh. In the dedicated-mesh model, check that discovery selectors do not overlap, workload namespaces select the correct active revision, and secrets namespaces have no injection-enabling labels.

Namespace labels determine injection for newly created pods. For running workloads, also verify that their sidecars connect to the intended control plane; changing namespace labels alone does not move existing pods between meshes.

Finally, check that each Edge Node is Available in ELM, each EIC appears as the intended runtime location, and a representative integration request reaches the correct instance. After ELM or mesh maintenance, verify all EIC instances on the affected Edge Node.