Questo contenuto non è disponibile nella lingua selezionata.
Chapter 1. Using the Skupper CLI
Using the skupper command-line interface (CLI) allows you to create and manage Skupper sites from the context of the current namespace.
A typical workflow is to create a site, link sites together, and expose services to the service network.
1.1. Checking the Skupper CLI
Installing the skupper command-line interface (CLI) provides a simple method to get started with Skupper.
Procedure
Verify the installation.
$ skupper version client version 1.8.1-rh-1
1.2. Creating a site using the CLI
A service network consists of Skupper sites. This section describes how to create a site in a Kubernetes cluster using the default settings. See Using Skupper Podman for information about using the Skupper CLI to create Podman sites.
Prerequisites
-
The
skupperCLI is installed. - You are logged into the cluster.
- The services you want to expose on the service network are in the active namespace.
Procedure
Create a default site:
$ skupper init
Starting with Skupper release 1.3, the console is not enabled by default. To use the new console, see Using the console.
Check the site:
$ skupper status
The output should look similar to the following:
Skupper is enabled for namespace "west" in interior mode. It is not connected to any other sites.
NoteThe default message above is displayed when you initialize a site on a cluster that does not have a Skupper policy installed. If you install a Skupper policy as described in Securing a service network using policies, the message becomes
Skupper is enabled for namespace "west" in interior mode (with policies).By default, the site name defaults to the namespace name, for example,
west.
1.3. Custom sites
The default skupper init creates sites that satisfy typical requirements.
Starting with Skupper release 1.3, the console is not enabled by default. To use the new console, see Using the console.
If you require a custom configuration, note the following options:
Configuring console authentication. There are several
skupperoptions regarding authentication for the console:--console-auth <authentication-mode>Set the authentication mode for the console:
-
openshift- Use OpenShift authentication, so that users who have permission to log into OpenShift and view the Project (namespace) can view the console. -
internal- Use Skupper authentication, see theconsole-userandconsole-passwordoptions. -
unsecured- No authentication, anyone with the URL can view the console.
-
--console-user <username>-
Username for the console user when authentication mode is set to
internal. Defaults toadmin. --console-password <password>-
Password for the console user when authentication mode is set to
internal. If not specified, a random passwords is generated.
Configuring service access
$ skupper init --create-network-policy
NoteAll sites are associated with a namespace, called the active namespace in this procedure.
Services in the active namespace may be accessible to pods in other namespaces on that cluster by default, depending on your cluster network policies. As a result, you can expose services to pods in namespaces not directly connected to the service network. This setting applies a Kubernetes network policy to restrict access to services to those pods in the active namespace.
For example, if you create a site in the namespace
projectAofclusterAand link that site to a service network where thedatabaseservice is exposed, thedatabaseservice is available to pods inprojectBofclusterA.You can use the
--create-network-policyoption to restrict thedatabaseservice access toprojectAofclusterA.
1.4. Linking sites
A service network consists of Skupper sites. This section describes how to link sites to form a service network.
Linking two sites requires a single initial directional connection. However:
- Communication between the two sites is bidirectional, only the initial linking is directional.
- The choice of direction for linking is typically determined by accessibility. For example, if you are linking an OpenShift Dedicated cluster with a CodeReady Containers cluster, you must link from the CodeReady Containers cluster to the OpenShift Dedicated cluster because that route is accessible.
Procedure
- Determine the direction of the link. If both clusters are publicly addressable, then the direction is not significant. If one of the clusters is addressable from the other cluster, perform step 2 below on the addressable cluster.
Generate a token on the cluster that you want to link to:
$ skupper token create <filename>
where
<filename>is the name of a YAML file that is saved on your local filesystem.This file contains a key and the location of the site that created it.
NoteAccess to this file provides access to the service network. Protect it appropriately.
For more information about protecting access to the service network, see Using Skupper tokens.
Use a token on the cluster that you want to connect from:
To create a link to the service network:
$ skupper link create <filename> [-name <link-name>]
where
<filename>is the name of a YAML file generated from theskupper token createcommand and<link-name>is the name of the link.To check the link:
$ skupper link status Link link1 not connected
In this example no <link-name> was specified, the name defaulted to
link1.To delete a link:
$ skupper link delete <link-name>
where
<link-name>is the name of the link specified during creation.
