Release notes

Red Hat Service Interconnect 2.2

Latest information about features and issues in this release

Abstract

These release notes contain the latest information about new features, enhancements, fixes, and issues contained in the Red Hat Service Interconnect 2.2 release.

Red Hat Service Interconnect is a Red Hat build of the open source Content from skupper.io is not included.Skupper project.

Chapter 1. New and changed features

Red Hat Service Interconnect is the Red Hat build of Content from skupper.io is not included.Skupper.

The following features are included in Red Hat Service Interconnect version 2.2:

Multi-key listeners provide advanced load balancing and failover capabilities with two distribution strategies: priority for ordered failover and weighted for proportional traffic distribution across multiple routing keys. See Creating a multi-key listener using YAML.
HTTP proxy tunnel support allows Skupper links to traverse corporate HTTP CONNECT proxies, enabling deployment in restricted network environments. See Linking sites through an HTTP proxy.
Additional Network Observer configuration options provide more flexible observability settings.
Dynamic system controller for non-Kubernetes sites enables interactive configuration changes on local system sites without requiring service reloads when using --reload-type auto.

1.1. CRD changes

The internal.skupper.io/listener label value on listener Services has changed from true to the name of the listener.
When Skupper creates a Kubernetes Service for a listener, it sets the label internal.skupper.io/listener on that Service. Previously the value was always true; it is now set to the name of the listener resource.

Chapter 2. Long term support

Red Hat Service Interconnect 2.2 is available as a long term support (LTS) release version. Bug fixes and security advisories are provided for Red Hat Service Interconnect 2.2 in a series of micro releases (2.2.2, 2.2.3, 2.2.4, and so on) for a period of at least 12 months. See Red Hat Service Interconnect Life Cycle Policy for more information.

Note the following important points about the LTS release stream:

The LTS release stream provides only bug fixes. No new enhancements will be added to this stream.
To remain in a supported configuration, you must upgrade to the latest micro release in the LTS release stream.

Chapter 3. Supported configurations

Table 3.1. Red Hat Enterprise Linux CLI (using dnf)

	x86-64	aarch64	s390x	ppc64le
Red Hat Enterprise Linux 8	Yes	Yes	Yes	Yes
Red Hat Enterprise Linux 9	Yes	Yes	Yes	Yes
Red Hat Enterprise Linux 10

Kubernetes sites (primary support)

Service Interconnect is supported on all versions of Red Hat OpenShift Container Platform that are in Full or Maintenance support. For more information, see the following articles:

Support for Non-OpenShift distributions of Kubernetes requires Kubernetes version 1.28 or later.

Ingress types (primary support)

LoadBalancer
OpenShift Routes (supported only on OpenShift)

Other ingress types fall under commercially reasonable support.

Table 3.2. Red Hat Enterprise Linux Podman sites (primary support)

	x86-64	aarch64	s390x	ppc64le
Red Hat Enterprise Linux 8	Yes	Yes	Yes	Yes
Red Hat Enterprise Linux 9	Yes	Yes	Yes	Yes

Table 3.3. Router (primary support)

	x86-64	aarch64	s390x	ppc64le
Red Hat Enterprise Linux 8	Yes	Yes	Yes	Yes
Red Hat Enterprise Linux 9	Yes	Yes	Yes	Yes

For use in Kubernetes and local system sites.

Note

The Skupper router is not supported for standalone use as a messaging router.

Table 3.4. CLI (binary download)

	x86-64	aarch64	s390x	ppc64le
Linux	Yes	Yes	Yes	Yes
Mac	Yes
Windows	Yes

Kubernetes distributions (commercially reasonable support)

Red Hat will provide assistance running Service Interconnect on any CNCF-certified distribution of Kubernetes. Note, however, that our testing is done on OpenShift.

Content from www.cncf.io is not included.https://www.cncf.io/certification/software-conformance/#logos

Kubernetes Ingress types (commercially reasonable support)

Gateway
Contour
Nginx (This requires configuration for TLS passthrough.)
NodePort

Table 3.5. Podman sites (commercially reasonable support)

	x86-64	aarch64	s390x	ppc64le
Linux	Yes	Yes	Yes	Yes

Service Interconnect requires Podman version 4 or later.

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.

Disconnected operation

Red Hat supports deployment of Service Interconnect in disconnected environments.

Note

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.

Chapter 4. Technology Preview features

Some features in this release are currently in Technology Preview. This section describes the Technology Preview features in Red Hat Service Interconnect 2.2.

Important

Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Certificate rotation: You can now rotate certificates as described in Content from github.com is not included.README.

Chapter 5. Upgrading sites

To upgrade a site, you need to upgrade the controller using the same method you used to install the Red Hat Service Interconnect, that is, one of the following:

Updating the operator
Applying the latest YAML

Chapter 6. Upgrading local system sites

There are two distinct procedures for updating your Skupper installation: updating the site configuration and manually updating the controller.

6.1. Standard Site Update

To update an existing site to the latest images or configuration matching your current CLI version:

Procedure

Ensure you have the latest version of the Skupper CLI installed.
Run the reload command:
```
skupper system reload
```
This command refreshes the site definition and pulls the latest images associated with the CLI version.

6.2. Updating the Controller

Currently, skupper system uninstall protects active sites by refusing to run if a site is detected. However, if you need to force an update to the controller itself (to pick up a new controller version) without deleting your sites, follow this manual workaround.

Prerequisites

Ensure your CLI is updated to the target version.

Procedure

Stop and remove the controller container. The container is named <user>-skupper-controller.
Podman
```
podman rm -f <user>-skupper-controller
```
Docker
```
docker rm -f <user>-skupper-controller
```
Note
Replace <user> with the specific username under which Skupper is running.
Re-install the controller.
Run the install command to recreate the controller using the new CLI version.
```
skupper system install
```
Verify the controller is recreated with the updated version.

Chapter 7. Gathering data about your application network

When opening a support case, it is helpful to provide debugging information about your application network to Red Hat Support.

Provide the following information when opening a support case:

Gathering cluster data - OpenShift sites
Output of `skupper debug dump' - Kubernetes and local system sites

Chapter 8. Fixed issues

See Content from redhat.atlassian.net is not included.Red Hat Service Interconnect Resolved Issues for 2.2.x for a list of issues that have been fixed in this release.

Chapter 9. Known issues

Content from redhat.atlassian.net is not included.SKUPPER-2873 - Collector not reporting traffic correctly
The collector may not accurately report traffic metrics in certain scenarios.
Workaround
To workaround this issue you can restart the deployment with:
```
# Replace <your-namespace> with the site namespace.
kubectl rollout restart deployment skupper-network-observer -n <your-namespace>
```
Content from redhat.atlassian.net is not included.SKUPPER-2771 - Basic HTTP authentication does not work with NetObs operator
If you install the Red Hat Service Interconnect Network Observer Operator and create a CR with spec.auth.strategy set to basic, you cannot log into console.
Workaround
To workaround this issue you can create a CR with:
```
spec:
...
  auth:
    strategy: basic
  nginx:
    command:
      - nginx
      - -g
      - daemon off;
```
Content from redhat.atlassian.net is not included.SKUPPER-2988 - Docker is not supported on IBM Power ppc64le
Docker is not supported on IBM Power ppc64le.
Workaround
To workaround this issue, use Podman instead of Docker.
Content from redhat.atlassian.net is not included.SKUPPER-2584 - Multiple Skupper Links
You can create multiple links from one site to another. However, the links do not perform as expected. For example, traffic flow across multiple links with different costs might not be as expected.
Workaround
To workaround this issue, make sure a link does not exist before creating a new link.

Revised on 2026-06-30 11:34:52 UTC

Legal Notice

Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.

The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.

All other trademarks are the property of their respective owners.