Release notes


Red Hat Service Interconnect 1.4

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 1.4 release.
Red Hat Service Interconnect is a Red Hat build of the open source Skupper project.

Chapter 1. New and changed features

The Red Hat build of Skupper is now known as Red Hat Service Interconnect. The documentation for previous Limited Availability releases are available at Product Documentation for Red Hat Application Interconnect.

This release includes the following changes:

  • Previous releases allowed you to expose services from other namespaces, however if the target of the service became unavailable skupper service status was unable to report the failure. With this release, skupper init --enable-cluster-permissions and skupper expose --target-namespace <ns> allows you to expose and monitor services with targets in other namespaces. See Exposing services from other namespaces for more information.
  • You can now encrypt traffic from the pod to the Skupper router.
  • You can now expose deploymentconfig objects from OpenShift 3.11 clusters.
  • By default, a console is not provisioned when you create a site. To enable a console, see Using the Skupper console.

Chapter 2. Long term support

Red Hat Service Interconnect 1.4 is available as a long term support (LTS) release version. Bug fixes and security advisories are provided for Red Hat Service Interconnect 1.4 in a series of micro releases (1.4.2, 1.4.3, 1.4.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.4.1 GA.

Chapter 3. 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 1.4.

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.

Podman sites
With this release of Red Hat Service Interconnect, you can create sites on RHEL hosts as well as Kubernetes namespaces. See Using Skupper podman for more information.
Console
With this release of Red Hat Service Interconnect, you can optionally provision a console to monitor traffic flows across the service network. See Using the Skupper console for more information. This early version of the console uses an in-memory prometheus instance to populate traffic visualizations. The prometheus instance and metrics are not intended for public use, Red Hat encourage you to test and provide feedback on the console features only.

Chapter 4. Supported configurations

Command-line interface

  • RHEL 8 x86-64
  • RHEL 9 x86-64

Router

For use in Kubernetes-based sites and as a gateway for containers or machines.

  • RHEL 8 x86-64
  • RHEL 9 x86-64

Note: RHSI is not supported for standalone use as a messaging router.

RHSI Operator

The operator is supported with OpenShift 4.x only.

OpenShift versions

  • OpenShift 3.11
  • OpenShift 4.10, 4.11 and 4.12
  • ROSA and ARO
  • OpenShift Container Platform and OpenShift Dedicated

Installing RHSI in a disconnected network by mirroring the required components to the cluster is supported.

Ingress types

  • LoadBalancer
  • OpenShift Routes

CPU architecture

  • x86-64

Podman sites:

Podman-based sites are a Technical Preview feature.

You can create Podman sites only on OS versions where the Skupper CLI and router are supported.

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.

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 5. Deprecated features

This section describes features that are supported, but have been deprecated from Red Hat Service Interconnect.

Protocols
The http and http2 protocols are deprecated and will be removed in a future release when a feature that provides similar observability becomes available. Red Hat recommends using the tcp protocol unless http or http2 observability is required.

Chapter 6. Upgrading sites from Red Hat Application Interconnect version 1

This release of Red Hat Service Interconnect is compatible with Red Hat Application Interconnect version 1, however Red Hat recommends upgrading all sites to version 1.4.

Note

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
Note

If you enabled the console previously, which was the default, the upgraded site will also have the console enabled. The default for Service Interconnect 1.4 is that the console is not enabled. The console for Service Interconnect is a Technology Preview feature as described in Chapter 3, Technology Preview features.

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 7. Fixed issues

See Red Hat Service Interconnect 1.4.x Resolved Issues for a list of issues that have been fixed in patch releases.

Chapter 8. Known issues

  • SKUPPER-1723 - Connection and status behaviors for 1.4 release

    Some behaviors of service networks are unexpected:

    • Unexposing a service does not terminate established connections.
    • The 'skupper network status' command displays output for services that have been unexposed.

    Workaround

    Manually close all connections associated with the service before unexposing that service.

    Note

    This issue is resolved for release 1.5.

  • SKUPPER-306 - Skupper network status doesn’t work with a large number of sites

    Depending on the topology of the service network, skupper network status might time-out and not provide the information required.

    Workaround

    You can extend the time-out to provide more time for the command to resolve, for example:

    skupper network status --timeout 10m

    Alternatively, upgrade to Red Hat Service Interconnect 1.5 which has a different mechanism for resolving network status.

  • SKUPPER-1069 - skupper init fails on non-OpenShift clusters

    If you create a site on a non-OpenShift cluster you might encounter a problem creating sites, with skupper status reporting pending.

    If you check the pods, you might see status similar to the following:

    $ kubectl get pods
    NAME                                         READY   STATUS                       RESTARTS   AGE
    skupper-router-698478664c-6xq72              0/2     CreateContainerConfigError   0          17s
    skupper-service-controller-698c785d7-dqc8m   0/1     CreateContainerConfigError   0          10s

    To confirm you are encountering this problem, search for a Kubernetes event similar to the following:

    $ kubectl get events| grep Warning
    
    Warning  Failed          17m (x4 over 17m)     kubelet            Error: container has runAsNonRoot and image will run as root

    Workaround

    Specify a user id as follows:

    $ skupper init --run-as-user 2000

    where 2000 is the id of the user you want to run the containers. You can assign any non-zero number as id.

    If you are creating sites using YAML, you specify the user in the data section:

      data:
        name: my-site
        run-as-user: "2000"
    Note

    This workaround does not enable you to deploy the Red Hat Service Interconnect console component on this site. You must deploy the console component on an OpenShift site until this issue is resolved.

  • 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 skupper CLI:
    ---
    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-06-04 15:04:56 UTC

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, 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, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.