Overview
Key features and supported configurations
Abstract
Chapter 1. Key features
Red Hat Service Interconnect is a Red Hat build of the open source Skupper project. Skupper introduces an application network, linking services across the hybrid cloud.
An application network enables communication between services running in different network locations. It allows geographically distributed services to connect as if they were all running in the same site.

The following are key features of Skupper:
- Private to public site connectivity: You expose only specific services and ports to a remote site.
-
Minimal effort: A few
skupper
CLI commands to expose services from one site to another, or define services in YAML. - Security: mTLS for all cross site communication.
- Load balancing and failover of services.
Chapter 2. Supported standards and protocols
Red Hat Service Interconnect supports the following TLS versions for site links:
- TLS 1.2
- TLS 1.3
Chapter 3. Supported configurations
3.1. Primary support
3.1.1. CLI
x86-64 | aarch64 | s390x | ppc64le | |
---|---|---|---|---|
RHEL 8 | Yes | Yes | Yes | |
RHEL 9 | Yes | Yes | Yes |
3.1.2. Kubernetes sites
3.1.2.1. Distributions
Supported | Tested | |
---|---|---|
OpenShift 4.x (OCP) | Yes | Yes |
OpenShift on AWS (ROSA) | ||
OpenShift on Google Cloud (OSD) | ||
OpenShift on IBM Cloud (RHOIC) | ||
OpenShift on Microsoft Azure (ARO) | ||
Amazon EKS | ||
Azure AKS | ||
Google GKE |
OpenShift 4.x support includes the latest release and latest EUS release.
Support for Non-OpenShift distributions of Kubernetes requires Kubernetes version 1.28 or later.
3.1.2.2. Ingress types
- LoadBalancer
- OpenShift Routes (supported only on OpenShift)
Other ingress types for non-OpenShift distributions of Kubernetes fall under commercially reasonable support.
3.1.2.3. Operator
The operator is supported with OpenShift 4.x only.
3.1.3. Podman sites
x86-64 | aarch64 | s390x | ppc64le | |
---|---|---|---|---|
RHEL 8 | Yes | Yes | Yes | |
RHEL 9 | Yes | Yes | Yes |
3.1.4. Router
For use in Kubernetes sites and as a gateway for containers or machines.
x86-64 | aarch64 | s390x | ppc64le | |
---|---|---|---|---|
RHEL 8 | Yes | Yes | Yes | |
RHEL 9 | Yes | Yes | Yes |
The Skupper router is not supported for standalone use as a messaging router.
3.2. Commercially reasonable support
3.2.1. CLI
x86-64 | aarch64 | s390x | ppc64le | |
---|---|---|---|---|
Linux | Yes | Yes | Yes | |
Mac | Yes | |||
Windows | Yes |
3.2.2. Kubernetes sites
3.2.2.1. Distributions
Red Hat will provide assistance running Service Interconnect on any CNCF-certified distribution of Kubernetes. Note, however, that our testing is done on OpenShift.
https://www.cncf.io/certification/software-conformance/#logos
3.2.2.2. Ingress types
- Gateway
- Contour
- Nginx (This requires configuration for TLS passthrough.)
- NodePort
3.2.3. Podman sites
Service Interconnect requires Podman version 4 or later.
x86-64 | aarch64 | s390x | ppc64le | |
---|---|---|---|---|
Linux | Yes | Yes |
3.2.4. Router
The router has commercially reasonable support when run as a container on Linux.
3.3. Upgrades
- Red Hat supports upgrades from one downstream minor version to the next, with no jumps.
- While Red Hat aims to have compatibility across minor versions, Red Hat recommends upgrading all sites to the latest version.
3.4. Disconnected operation
Red Hat supports deployment of Service Interconnect in disconnected environments.
If you have applications that require long lived connections, for example Kafka clients, consider using a load balancer as ingress instead of a proxy ingress such as OpenShift route. If you use an OpenShift route as ingress, expect interruptions whenever routes are configured.
For information about the latest release, see Red Hat Service Interconnect Supported Configurations.
Port negotiation limitation
If your protocol negotiates the communication port, for example active FTP, you cannot use that protocol to communicate across a service network.
Appendix A. About Service Interconnect documentation
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Revised on 2025-04-28 13:58:48 UTC