Installation


Red Hat Service Interconnect 1.8

Installing the CLI or the Operator

Abstract

This guide describes how to install Red Hat Service Interconnect 1.8.
Red Hat Service Interconnect is a Red Hat build of the open source Skupper project.

Chapter 1. Installing the CLI

The Skupper CLI provides a method to create both Kubernetes and Podman sites.

There are two methods to install the CLI:

1.1. Downloading binaries

Downloading the Skupper CLI binaries is a quick way to get started with Red Hat Service Interconnect. However, consider using Red Hat packages on Linux to receive the latest updates.

Procedure

  1. Download binary files for Linux, macOS or Windows, choose the latest Version for 1.8 at Software Downloads.

    For a Mac with Apple silicon, use Rosetta 2 and the Skupper CLI for Mac on x86-64 download.

  2. Unzip the downloaded file and place the Skupper executable on your PATH.
  3. Verify installation:

    $ skupper version
    client version                 1.8.1-rh-1

1.2. Using Red Hat packages

Installing Red Hat packages on Linux makes sure you receive the latest updates to the Skupper CLI.

Prerequisites

  • Make sure your subscription is activated and your system is registered. For more information about using the Customer Portal to activate your Red Hat subscription and register your system for packages, see Chapter 6, Using your subscription.

Procedure

  1. Use the subscription-manager command to subscribe to the required package repositories. Replace <version> with 1 for the main release stream or 1.4 for the long term support release stream.

    Note

    Replacing <version> with 1 installs 1.8, while 1.8 is the main release stream and changes after further releases.

    Red Hat Enterprise Linux 8
    $ sudo subscription-manager repos --enable=service-interconnect-_<version>_-for-rhel-8-x86_64-rpms
    Red Hat Enterprise Linux 9
    $ sudo subscription-manager repos --enable=service-interconnect-_<version>_-for-rhel-9-x86_64-rpms
    1. Use the yum or dnf command to install the skupper command:

      $ sudo dnf install skupper-cli

Additional information

  • See Examples for the 'Hello world' tutorial.
  • Use man containers.conf to view more information about podman configuration.

Chapter 2. Installing the Operator

The Red Hat Service Interconnect Operator creates and manages sites in OpenShift.

Note

The Red Hat Service Interconnect Operator is supported only on OpenShift version 4 as distinct from OpenShift version 3. Installing an Operator requires administrator-level privileges for your cluster.

2.1. Installing the Operator for all namespaces using the CLI

The steps in this section show how to use the kubectl command to install and deploy the latest version of the Red Hat Service Interconnect Operator in a given Kubernetes cluster. Installing the operator for all namespaces allows you create a site in any namespace.

Prerequisites

  • Access to a cluster using a cluster-admin account.
  • Operator Lifecycle Manager is installed. This is installed by default on OpenShift clusters. See QuickStart for more information about installation.

Procedure

  1. Log in as a cluster administrator.
  2. Complete the steps described in Red Hat Container Registry Authentication.
  3. Create a file named subscription-all.yaml with the following:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: skupper-operator
      namespace: openshift-operators
    spec:
      channel: stable-1
      installPlanApproval: Automatic
      name: skupper-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: skupper-operator.v1.8.1-rh-3
    Note

    If you want to keep updates confined to 1.8.x releases, set the value of channel to stable-1.8.

    If you do not specify startingCSV, the subscription defaults to the latest operator version.

    If you specify installPlanApproval as Manual, sites are not automatically upgraded to the latest version of Service Interconnect. See Chapter 4, Upgrading the Red Hat Service Interconnect Operator and sites for information on manually upgrading sites.

  4. Apply the subscription YAML:

    $ kubectl apply -f subscription-all.yaml

Additional information

  • See Using Skupper for instructions about using YAML to create sites.

2.2. Installing the Operator for a single namespace using the CLI

The steps in this section show how to use the kubectl command to install and deploy the latest version of the Red Hat Service Interconnect Operator in a given Kubernetes cluster. Installing the operator for a single namespaces allows you create a site in the specified namespace.

Prerequisites

  • Access to a cluster using a cluster-admin account.
  • Operator Lifecycle Manager is installed. This is installed by default on OpenShift clusters. See QuickStart for more information about installation.

Procedure

  1. Log in as a cluster administrator.
  2. Complete the steps described in Red Hat Container Registry Authentication.
  3. Create an Operator group in the namespace where you want to create a site:

    1. Create a file named operator-group.yaml with the following:

      kind: OperatorGroup
      apiVersion: operators.coreos.com/v1
      metadata:
        name: skupper-operator
        namespace: my-namespace
      spec:
        targetNamespaces:
        - my-namespace

      where my-namespace is the name of the namespace you want to create the site.

    2. Apply the Operator group YAML:

      $ kubectl apply -f operator-group.yaml
  4. Create a file named subscription-myns.yaml with the following:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: skupper-operator
      namespace: my-namespace
    spec:
      channel: stable-1
      installPlanApproval: Automatic
      name: skupper-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: skupper-operator.v1.8.1-rh-3

    where my-namespace is the name of the namespace you want to create the site.

    Note

    If you want to keep updates confined to 1.8.x releases, set the value of channel to stable-1.8.

    If you do not specify startingCSV, the subscription defaults to the latest operator version.

    If you specify installPlanApproval as Manual, sites are not automatically upgraded to the latest version of Service Interconnect. See Chapter 4, Upgrading the Red Hat Service Interconnect Operator and sites for information on manually upgrading sites.

  5. Apply the subscription YAML:

    $ kubectl apply -f subscription-myns.yaml

Additional information

  • See Using Skupper for instructions about using YAML to create sites.

2.3. Installing the Operator using the OpenShift console

The procedures in this section show how to use the OperatorHub from the OpenShift console to install and deploy the latest version of the Red Hat Service Interconnect Operator in a given OpenShift namespace.

Prerequisites

  • Access to an OpenShift cluster using a cluster-admin account. See Release Notes for supported OpenShift versions.

Procedure

  1. In the OpenShift web console, navigate to OperatorsOperatorHub.
  2. Choose Red Hat Service Interconnect Operator from the list of available Operators, and then click Install.
  3. On the Operator Installation page, two Installation mode options are available:

    • All namespaces on the cluster
    • A specific namespace on the cluster

      For this example, choose A specific namespace on the cluster.

  4. Choose an Update approval option.

    By default, Automatic approval is selected, and sites will upgrade to the latest version of Service Interconnect. If you choose Manual approval, sites will not be automatically upgraded to the latest version of Service Interconnect. See Chapter 4, Upgrading the Red Hat Service Interconnect Operator and sites for information on manually upgrading sites.

  5. Select the namespace into which you want to install the Operator, and then click Install.

    The Installed Operators page appears displaying the status of the Operator installation.

  6. Verify that the Red Hat Service Interconnect Operator is displayed and wait until the Status changes to Succeeded.
  7. If the installation is not successful, troubleshoot the error:

    1. Click Red Hat Service Interconnect Operator on the Installed Operators page.
    2. Select the Subscription tab and view any failures or errors.

For more information about installing Operators, see the OpenShift Documentation

Additional information

  • See Using Skupper for instructions about using YAML to create sites.

Chapter 3. Upgrading the CLI and sites

Upgrading sites requires the latest version of the Skupper CLI.

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.

Procedure

  1. Upgrade the skupper CLI:

    $ dnf upgrade skupper-cli
  2. Upgrade each site:

    1. Set the context to the site you want to upgrade.
    2. Run the upgrade command:

      $ skupper update
Note

Upgrading Technology Preview Podman sites is not supported.

Podman sites were introduced as a Technology Preview feature in version 1.4, however you cannot upgrade these sites to the fully supported Podman sites available in later releases. To workaround this, recreate the Podman site and recreate links and services.

Chapter 4. Upgrading the Red Hat Service Interconnect Operator and sites

You can now choose from the following channels:

  • stable-1.8 - Limit updates to 1.8.x (long term support).
  • stable-1 - Limit updates to 1.x.
  • stable - All releases.
Note

If you are using stable or stable-1, you can upgrade automatically.

To upgrade from the previous LTS version to 1.8, switch channel to stable-1.8.

If you install the Operator again as described in Installing the Operator, existing sites are not removed.

If you chose automatic updates when installing the Red Hat Service Interconnect Operator, sites are upgraded to future releases whenever a new version of Service Interconnect is available for the channel you chose. If you chose manual updates, complete this procedure to upgrade your sites.

Procedure

  1. Log into the OpenShift console.
  2. Navigate to the Installed Operators page.
  3. If Upgrade available is displayed as the Status for the Red Hat Service Interconnect Operator, click that text.
  4. On the InstallPlan details page, click Preview InstallPlan.
  5. Click Approve to upgrade sites.

Chapter 5. Installing the policy system

Installing the Skupper policy system on a cluster allows you control how Skupper is used on the cluster.

Note

Applying the policy system in a cluster without specific policy rules prohibits site linking and service exposure. If you are installing the policy system on a cluster where there are existing sites, you must create policies before installing the policy system to avoid disruption.

Prerequisites

  • Access to a Kubernetes cluster with cluster-admin privileges.
  • The Red Hat Service Interconnect Operator is installed

Procedure

  1. Log into your cluster.
  2. Deploy the policy CRD:

    $ kubectl apply -f skupper_cluster_policy_crd.yaml
    
    customresourcedefinition.apiextensions.k8s.io/skupperclusterpolicies.skupper.io created
    clusterrole.rbac.authorization.k8s.io/skupper-service-controller created

    where the contents of skupper_cluster_policy_crd.yaml is specified in the Appendix A, YAML for the Skupper policy CRD appendix.

Additional information

See Securing a service network using policies for more information about using policies.

Chapter 6. Using your subscription

Red Hat Service Interconnect is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal.

6.1. Accessing your account

Procedure

  1. Go to access.redhat.com.
  2. If you do not already have an account, create one.
  3. Log in to your account.

6.2. Activating a subscription

Procedure

  1. Go to access.redhat.com.
  2. Navigate to My Subscriptions.
  3. Navigate to Activate a subscription and enter your 16-digit activation number.

6.3. Registering your system for packages

To install RPM packages for this product on Red Hat Enterprise Linux, your system must be registered. If you are using downloaded release files, this step is not required.

Procedure

  1. Go to access.redhat.com.
  2. Navigate to Registration Assistant.
  3. Select your OS version and continue to the next page.
  4. Use the listed command in your system terminal to complete the registration.

For more information about registering your system, see one of the following resources:

Chapter 7. Deployment options on Kubernetes

When you create a site on Kubernetes, there are many options you can use. For example, you can set the number of pods and the resources allocated to each pod. This guide focusses on the following goals:

7.1. Scaling for increased traffic

For optimal network latency and throughput, you can adjust the CPU allocation for the router using the router-cpu option. Router CPU is the primary factor governing Skupper network performance.

Note

Increasing the number of routers does not improve network performance. An incoming router-to-router link is associated with just one active router. Additional routers do not receive traffic while that router is responding

  1. Determine the router CPU allocation you require.

    By default, the router CPU allocation is BestEffort as described in Pod Quality of Service Classes.

    Consider the following CPU allocation options:

    Router CPUDescription

    1

    Helps avoid issues with BestEffort on low resource clusters

    2

    Suitable for production environments

    5

    Maximum performance

  2. If you are using the Skupper CLI, set the CPU allocation for the router using the --router-cpu option. For example:

    $ skupper init --router-cpu 2
  3. If you are using YAML, set the CPU allocation for the router by setting a value for the router-cpu attribute. For example:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: "skupper-site"
    data:
      name: "my-site"
      router-cpu: 2

7.2. Creating a high availability site

By default, Kubernetes restarts any router that becomes unresponsive. (If you encounter router restarts, consider Section 7.1, “Scaling for increased traffic” in order to improve responsiveness.)

If the cluster where you are running Skupper is very busy, it may take time for Kubernetes to schedule a new router pod. You can "preschedule" a backup router by deploying two routers in a site.

  1. If you are using the Skupper CLI, set the number of routers to 2 using the --routers option:

    $ skupper init --routers 2
  2. If you are using YAML, set the number of routers to 2 by setting the routers attribute:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: "skupper-site"
    data:
      name: "my-site"
      routers: 2

Setting the number of routers to more than two does not provide increased availability and can adversely affect performance.

Note: Clients must reconnect when a router restarts or traffic is redirected to a backup router.

7.3. Service synchronization

By default, creating a site enables that site to synchronize all services from other default sites. This means that all services exposed on the service network are available in the current site. For example, if you expose the backend service in the east site, that service is automatically created in the west site.

However, if you want more granular control over which services are available, you can disable service-sync. This might be required if:

  • You expose many services and not all are required on all sites.
  • You are concerned that a specific service is not available on a specific site.

To disable service synchronization:

$ skupper init --service-sync false

or use the following YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: skupper-site
data:
  name: my-site
  service-sync: false

To check whether synchronization is enabled, check the value for service-sync in the output from the following command:

$ kubectl get cm skupper-site -o json

If you disable service-sync and you want to consume an exposed service on a specific site, you can create that service using the following command:

skupper service create <name> <port>

where <name> is the service name on the site where the service is exposed and <port> is the port used to expose that service.

Notes:

  • When considering whether services are synchronized between two sites, service-sync must be enabled on both sites.
  • If you use the command skupper service delete on a site, that command only works if the service was created on that site.
  • Podman sites do not support service-sync.

Chapter 8. Creating a Podman site in a restricted environment

In a production environment which has no or limited internet access, you might need to mirror the required images to create a site.

This procedure outlines how to use Podman and tar files for managing container images. If a registry is available in the restricted environment, the same process can be followed. Ensure that the environment variables are set to reference the images in the registry after they have been populated.

Note

If you want to use a Linux machine with a proxy to pull images, you can configure Podman to use a proxy:

$ systemctl --user edit podman

Add the following to the service definition:

[Service]
Environment="HTTP_PROXY=<proxy-domain>:<proxy-port>"
Environment="HTTPS_PROXY=<proxy-domain>:<proxy-port>"

To ensure that podman uses the new configuration:

$ systemctl --user daemon-reload
$ systemctl --user restart podman

Prerequisites

  • A Linux machine with internet access to download the images.
  • A Linux machine in a restricted environment where you want to create the site.

This can be one machine, where the machine is moved to the restricted environment.

Procedure

  1. Log in to registry.redhat.io on the machine with internet access:

    $ podman login -u USERNAME -p PASSWORD registry.redhat.io
  2. Download the images required for a Podman site by creating a site:

    $ skupper init

    If you require a console, use the following command to ensure the extra images are downloaded

    $ skupper init --enable-console --enable-flow-collector

    After creating the site, the following images are listed using podman image ls -a:

    • registry.redhat.io/service-interconnect/skupper-router-rhel9
    • registry.redhat.io/service-interconnect/skupper-controller-podman-rhel9
    • registry.redhat.io/service-interconnect/skupper-flow-collector-rhel9 (console only)
    • registry.redhat.io/openshift4/ose-prometheus (console only)

    The tags are determined by the version of the skupper CLI.

  3. Create tar files for each image, for example:

    $ podman save -o skupper-controller.tar  registry.redhat.io/service-interconnect/skupper-controller-podman-rhel9:<tag>

    where <tag> is the tag shown from using the podman image ls -a command.

  4. Copy the tar files to the machine in the restricted environment.
  5. On the machine in the restricted environment, load the image from the tar files, for example:

    podman load -i skupper-controller.tar
  6. Change the image tags to remove reference to registry.redhat.io:

    podman tag registry.redhat.io/service-interconnect/skupper-router-rhel9:<tag> service-interconnect/skupper-router-rhel9:<tag>

    This step is required to avoid the machine attempting to pull images from registry.redhat.io.

  7. Configure the skupper CLI to use the mirrored images by setting the following environment variables:

    $ export SKUPPER_CONTROLLER_PODMAN_IMAGE=service-interconnect/skupper-controller-podman-rhel9:<tag>
    $ export QDROUTERD_IMAGE=service-interconnect/skupper-router-rhel9:<tag>

    If you require a console, you also require the following environment variables:

    $ export SKUPPER_FLOW_COLLECTOR_IMAGE=service-interconnect/skupper-flow-collector-rhel9:<tag>
    $ export PROMETHEUS_SERVER_IMAGE=openshift4/ose-prometheus:<tag>
  8. Create a site, for example:

    $ skupper init

Appendix A. YAML for the Skupper policy CRD

The policy system allows a cluster administrator restrict Skupper usage on a cluster. It is not required for typical Skupper usage.

The following YAML applies the Skupper policy CRD to a cluster.

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: skupperclusterpolicies.skupper.io
spec:
  group: skupper.io
  versions:
    - name: v1alpha1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                namespaces:
                  type: array
                  items:
                    type: string
                allowIncomingLinks:
                  type: boolean
                allowedOutgoingLinksHostnames:
                  type: array
                  items:
                    type: string
                allowedExposedResources:
                  type: array
                  items:
                    type: string
                allowedServices:
                  type: array
                  items:
                    type: string
  scope: Cluster
  names:
    plural: skupperclusterpolicies
    singular: skupperclusterpolicy
    kind: SkupperClusterPolicy
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    application: skupper-service-controller
  name: skupper-service-controller
rules:
  - apiGroups:
      - skupper.io
    resources:
      - skupperclusterpolicies
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - namespaces
    verbs:
      - get

Appendix B. 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-29 11:25:54 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.