Installation
Installing the CLI or the Operator
Abstract
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
Download binary files for Linux, macOS or Windows, choose the latest Version for 1.5 at Software Downloads.
For a Mac with Apple silicon, use Rosetta 2 and the Skupper CLI for Mac on x86-64 download.
- Unzip the downloaded file and place the Skupper executable on your PATH.
Verify installation:
$ skupper version client version 1.5.3-rh-5
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 7, Using your subscription.
Procedure
Use the
subscription-manager
command to subscribe to the required package repositories. Replace<version>
with1
for the main release stream or1.4
for the long term support release stream.NoteReplacing
<version>
with1
installs1.5
, while1.5
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
Use the
yum
ordnf
command to install theskupper
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.
The Red Hat Service Interconnect Operator is supported only on OpenShift 4. 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 oc
command to install and deploy the latest version of the Red Hat Service Interconnect Operator in a given OpenShift cluster. Installing the operator for all namespaces allows you create a site in any namespace. See Getting started with the OpenShift CLI for more information about the oc
command.
Prerequisites
-
Access to an OpenShift cluster using a
cluster-admin
account. See Release Notes for supported OpenShift versions.
Procedure
Log in to OpenShift as a cluster administrator. For example:
$ oc login -u system:admin
- Complete the steps described in Red Hat Container Registry Authentication.
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.5.3-rh-1
NoteIf you want to keep updates confined to 1.5.x releases, set the value of
channel
tostable-1.5
.If you do not specify
startingCSV
, the subscription defaults to the latest operator version.If you specify
installPlanApproval
asManual
, 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.Apply the subscription YAML:
$ oc apply -f subscription-all.yaml
Additional information
- See Using Service Interconnect 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 oc
command to install and deploy the latest version of the Red Hat Service Interconnect Operator in a given OpenShift cluster. Installing the operator for a single namespaces allows you create a site in the specified namespace. See Getting started with the OpenShift CLI for more information about the oc
command.
Prerequisites
-
Access to an OpenShift cluster using a
cluster-admin
account. See Release Notes for supported OpenShift versions.
Procedure
Log in to OpenShift as a cluster administrator. For example:
$ oc login -u system:admin
- Complete the steps described in Red Hat Container Registry Authentication.
Create an Operator group in the namespace where you want to create a site:
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.Apply the Operator group YAML:
$ oc apply -f operator-group.yaml
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.5.3-rh-1
where
my-namespace
is the name of the namespace you want to create the site.NoteIf you want to keep updates confined to 1.5.x releases, set the value of
channel
tostable-1.5
.If you do not specify
startingCSV
, the subscription defaults to the latest operator version.If you specify
installPlanApproval
asManual
, 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.Apply the subscription YAML:
$ oc apply -f subscription-myns.yaml
Additional information
- See Using Service Interconnect 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
- In the OpenShift web console, navigate to → .
-
Choose
Red Hat Service Interconnect Operator
from the list of available Operators, and then click . 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.
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.
Select the namespace into which you want to install the Operator, and then click
.The Installed Operators page appears displaying the status of the Operator installation.
- Verify that the Red Hat Service Interconnect Operator is displayed and wait until the Status changes to Succeeded.
If the installation is not successful, troubleshoot the error:
-
Click
Red Hat Service Interconnect Operator
on the Installed Operators page. - Select the Subscription tab and view any failures or errors.
-
Click
For more information about installing Operators, see the OpenShift Documentation
Additional information
- See Using Service Interconnect 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.
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
Upgrade the
skupper
CLI:$ dnf upgrade skupper-cli
Upgrade each site:
- Set the context to the site you want to upgrade.
Run the upgrade command:
$ skupper update
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 version 1.5.
To workaround this, recreate the Podman site and recreate links and services.
In future, skupper update
will be supported for Podman sites.
Chapter 4. Upgrading the Red Hat Service Interconnect Operator and sites
This release changes the Operator channel name from alpha
. You can now choose from the following channels:
-
stable-1.5
- Limit updates to 1.5.x. -
stable-1
- Limit updates to 1.x. -
stable
- All releases.
You must install the Operator again as described in Installing the Operator to use version 1.5.
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
- Log into the OpenShift console.
- Navigate to the Installed Operators page.
- If Upgrade available is displayed as the Status for the Red Hat Service Interconnect Operator, click that text.
- On the InstallPlan details page, click Preview InstallPlan.
- 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.
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
- Log into your cluster.
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. 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:
6.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.
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
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 CPU Description 1
Helps avoid issues with
BestEffort
on low resource clusters2
Suitable for production environments
5
Maximum performance
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
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
6.2. Creating a high availability site
By default, Kubernetes restarts any router that becomes unresponsive. (If you encounter router restarts, consider Section 6.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.
If you are using the Skupper CLI, set the number of routers to
2
using the--routers
option:$ skupper init --routers 2
If you are using YAML, set the number of routers to
2
by setting therouters
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.
Chapter 7. 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.
7.1. Accessing your account
Procedure
- Go to access.redhat.com.
- If you do not already have an account, create one.
- Log in to your account.
7.2. Activating a subscription
Procedure
- Go to access.redhat.com.
- Navigate to My Subscriptions.
- Navigate to Activate a subscription and enter your 16-digit activation number.
7.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
- Go to access.redhat.com.
- Navigate to Registration Assistant.
- Select your OS version and continue to the next page.
- 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:
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-02 11:45:46 UTC