Chapter 1. Using the Skupper CLI
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. USD 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 skupper CLI 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: USD 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: USD 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. Note The 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 skupper options 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 the console-user and console-password options. 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 to admin . --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 USD skupper init --create-network-policy Note All 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 projectA of clusterA and link that site to a service network where the database service is exposed, the database service is available to pods in projectB of clusterA . You can use the --create-network-policy option to restrict the database service access to projectA of clusterA . 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: USD 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. Note Access 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: USD skupper link create <filename> [-name <link-name>] where <filename> is the name of a YAML file generated from the skupper token create command and <link-name> is the name of the link. To check the link: USD skupper link status Link link1 not connected In this example no <link-name> was specified, the name defaulted to link1 . To delete a link: USD skupper link delete <link-name> where <link-name> is the name of the link specified during creation.
skupper version client version 1.8.1-rh-1 skupper init skupper status Skupper is enabled for namespace "west" in interior mode. It is not connected to any other sites. skupper init --create-network-policy skupper token create <filename> skupper link create <filename> [-name <link-name>] skupper link status Link link1 not connected skupper link delete <link-name>