Release notes
Latest information about features and issues in this release
Abstract
Chapter 1. New and changed features
Red Hat Service Interconnect is the Red Hat build of Skupper.
The following features were designated Technology Preview in version 1.5, but are now fully supported:
- Windows and macOS
-
You can use the
skupperCLI on Windows and macOS. - Multiarch
- You can create sites on 64-bit ARM clusters and Linux hosts (aarch64).
The following features are included in this release:
- Support for Podman version 5.
- Claim type tokens include an expiry date.
-
The
skupper token statuscommand allows you validate a token - Metrics are now documented.
- Better support for Podman sites, including console.
Chapter 2. Long term support
Red Hat Service Interconnect 1.8 is available as a long term support (LTS) release version. Bug fixes and security advisories are provided for Red Hat Service Interconnect 1.8 in a series of micro releases (1.8.2, 1.8.3, 1.8.4, and so on) for a period of at least 12 months.
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.
- The LTS version will be supported for at least 12 months from the time of the Red Hat Service Interconnect 1.8.1 GA.
Chapter 3. Supported configurations
Command-line interface
- Red Hat Enterprise Linux 8 x86-64 and aarch64
- Red Hat Enterprise Linux 9 x86-64 and aarch64
- Linux x86-64 and aarch64
- macOS x86-64
- Windows x86-64
Router
For use in Kubernetes-based sites and as a gateway for containers or machines.
- Red Hat Enterprise Linux 8 x86-64 and aarch64
- Red Hat Enterprise Linux 9 x86-64 and aarch64
Red Hat Service Interconnect is not supported for standalone use as a messaging router.
Red Hat Service Interconnect Operator
The operator is supported with OpenShift 4.x only.
OpenShift versions
- OpenShift 3.11
- OpenShift 4.12, 4.13, 4.14, 4.15 and 4.16
- ROSA and ARO
- OpenShift Container Platform and OpenShift Dedicated
Installing Red Hat Service Interconnect in a disconnected network by mirroring the required components to the cluster is supported.
Ingress types
- LoadBalancer
- OpenShift Routes
CPU architecture
- x86-64 and aarch64
Kubernetes distributions
Red Hat provides assistance running Red Hat Service Interconnect on any CNCF-certified distribution of Kubernetes.
Note, however, that Red Hat Service Interconnect is tested only on OpenShift.
Ingress types
- Contour
- Nginx - This requires configuration for TLS passthrough
- NodePort
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, we recommend upgrading all sites to latest version.
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. Deprecated features
This section describes features that are supported, but have been deprecated from Red Hat Service Interconnect.
- Protocols
-
The
httpandhttp2protocols are deprecated and will be removed in a future release when a feature that provides similar observability becomes available. Red Hat recommends using thetcpprotocol unlesshttporhttp2observability is required.
Chapter 5. Upgrading sites
This release of Red Hat Service Interconnect is compatible with previous versions, however Red Hat recommends upgrading all sites to version 1.8.
Update all sites to ensure the same version of Service Interconnect is running across your service network. You can expect some minimal downtime during the update process.
To upgrade a site:
$ skupper update
See the Installation for instructions about upgrading Operator based sites.
If you enabled the console using a release before 1.4, which was the default, the upgraded site will also have the console enabled. The default for Service Interconnect 1.4 and later is that the console is not enabled.
To upgrade a gateway, delete the gateway and recreate it.
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.
Chapter 6. Fixed issues
See Red Hat Service Interconnect Resolved Issues for 1.8.x for a list of issues that have been fixed in this release.
Chapter 7. Known issues
If you create a site in an OpenShift Container Platform version 4.12 namespace, a message starting with the following warning is displayed:
W0320 15:27:27.446084 48301 warnings.go:70] would violate PodSecurity "restricted:v1.24"
You can ignore this message as it relates to a future restriction in OpenShift.
SKUPPER-2077 - Skupper Console Prometheus scrape configuration broken for openshift auth
If you configure a site to use OpenShift authenication for console access, metrics are not displayed in the console.
Workaround
If you require console metrics, use
internalauthenication for the site where the console is enablePd. Another option isunsecured, however if you use that option, the console is available to unauthenticated users.SKUPPER-869 - Enable idle connection timeouts for the TCP transport
If an endpoint is terminated, for example a client is killed, the other endpoint observes a half-closed connection. If the other endpoint does not close the connection or attempt to send data to the connection, the Skupper router does not release the memory allocated to that connection
Workaround
Avoid client server configurations that use this behavior if possible. For example, if a server automatically closes dormant connections, or attempts to communicate with client, the Skupper router frees the memory when a client is terminated.
SKUPPER-805 - skupper init doesn’t work for ordinary user on OCP 3.11
Workaround
Two workarounds are available:
- Use YAML to configure a site.
-
Create a service account with the following permissions to run the
skupperCLI:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: skupper-non-admin rules: - apiGroups: - "" resources: - configmaps - pods - pods/exec - services - secrets - serviceaccounts verbs: - get - list - watch - create - update - delete - apiGroups: - apps resources: - deployments - statefulsets - daemonsets verbs: - get - list - watch - create - update - delete - apiGroups: - route.openshift.io resources: - routes verbs: - get - list - watch - create - delete - apiGroups: - networking.k8s.io resources: - ingresses - networkpolicies verbs: - get - list - watch - create - delete - apiGroups: - projectcontour.io resources: - httpproxies verbs: - get - list - watch - create - delete - apiGroups: - rbac.authorization.k8s.io resources: - rolebindings - roles verbs: - get - list - watch - create - delete
You can save the YAML above to
role.yaml, apply it and bind the role to a username using:$ oc apply -f role.yaml $ oc policy add-role-to-user skupper-non-admin <username> -n <namespace-name> --role-namespace=<namespace-name>
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 2024-10-04 10:03:13 UTC
