Using Service Interconnect

Procedure

1. Verify the installation.

   $ skupper version
   client version 1.5.3-rh-5

Procedure

1. 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.

2. 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.

   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.

Procedure

1. 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.

2. 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.

   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.

3. 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 the skupper token create command 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.

Procedure

1. Run your service locally.
2. Log into your cluster and change to the namespace for your site.

3. Expose the service on the service network:

   $ skupper gateway expose <service> localhost <port>

   • <service> - the name of the service on the service network.
   • <port> - the port that runs the service locally.
   Note

   You can also expose services from other machines on your local network, for example if MySQL is running on a dedicated server (with an IP address of 192.168.1.200), but you are accessing the cluster from a machine in the same network:

   $ skupper gateway expose mysql 192.168.1.200 3306

4. Check the status of Skupper gateways:

   $ skupper gateway status
   
   Gateway Definition:
   ╰─ machine-user type:service version:1.5
      ╰─ Bindings:
         ╰─ mydb:3306 tcp mydb:3306 localhost 3306

   This shows that there is only one exposed service and that service is only exposing a single port (BIND). There are no ports forwarded to the local host.

   The URL field shows the underlying communication and can be ignored.

1. If you want to create a service type gateway on Linux, you need the skrouterd binary in your path.

   Use the yum or dnf command to install the skupper-router package:

   $ sudo dnf install skupper-router

   For podman or docker type gateways, you can skip this step.

2. Create a Skupper gateway:

   $ skupper gateway init --type <gateway-type>

   By default a service type gateway is created, however you can also specify:

   • podman
   • docker

3. Create a service that can communicate on the service network:

   $ skupper service create <name> <port>

   where

   • <name> is the name of the service you want to create
   • <port> is the port the service uses

   For example:

   $ skupper service create mydb 3306

4. Bind the service on the service network:

   $ skupper gateway bind <service> <host> <port>

   • <service> - the name of the service on the service network, mydb in the example above.
   • <host> - the host that runs the service.
   • <port> - the port the service is running on, 3306 from the example above.

5. Check the status of Skupper gateways:

   $ skupper gateway status

   The output looks similar to the following:

   Gateway Definitions Summary
   
   Gateway Definition:
   ╰─ machine-user type:service version:1.5
      ╰─ Bindings:
         ╰─ mydb:3306 tcp mydb:3306 localhost 3306

   This shows that there is only one exposed service and that service is only exposing a single port (BIND). There are no ports forwarded to the local host.

   The URL field shows the underlying communication and can be ignored.

   You can create more services in the service network and bind more local services to expose those services on the service network.

6. Forward a service from the service network to the local machine.

   $ skupper gateway forward <service> <port>

   where

   • <service> is the name of an existing service on the service network.
   • <port> is the port on the local machine that you want to use.

Procedure

1. Log into your cluster from the first machine and change to the namespace for your site.

2. Create a service that can communicate on the service network:

   $ skupper service create <name> <port>

   where

   • <name> is the name of the service you want to create
   • <port> is the port the service uses

   For example:

   $ skupper service create database 5432

3. Create a YAML file to represent the service you want to expose, for example:

   name: database 1
   bindings:
       - name: database 2
         host: localhost 3
         service:
           address: database:5432 4
           protocol: tcp 5
           ports:
               - 5432 6
         target_ports:
           - 5432 7
   qdr-listeners:
       - name: amqp
         host: localhost
         port: 5672

   1

   Gateway name, useful for reference only.

   2

   Binding name, useful to track multiple bindings.

   3

   Name of host providing the service you want to expose.

   4

   Service name and port on service network. You created the service in a previous step.

   5

   The protocol you want to use to expose the service, tcp, http or http2.

   6

   The port on the service network that you want this service to be available on.

   7

   The port of the service running on the host specified in point 3.

4. Save the YAML file using the name of the gateway, for example, gateway.yaml.

5. Generate a bundle that can be applied to the machine that hosts the service you want to expose on the service network:

   $ skupper gateway generate-bundle <config-filename> <destination-directory>

   where:

   • <config-filename> - the name of the YAML file, including suffix, that you generated in the previous step.
   • <destination-directory> - the location where you want to save the resulting gateway bundle, for example ~/gateways.

   For example:

   $ skupper gateway generate-bundle database.yaml ./

   This bundle contains the gateway definition YAML and a certificate that allow access to the service network.

6. Copy the gateway definition file, for example, mylaptop-jdoe.tar.gz to the machine that hosts the service you want to expose on the service network.

7. From the machine that hosts the service you want to expose:

   $ mkdir gateway
   
   $ tar -xvf <gateway-definition-file> --directory gateway
   $ cd gateway
   $ sh ./launch.py

   Note

   Use ./launch.py -t podman or ./launch.py -t docker to run the Skupper router in a container.

   Running the gateway bundle uses the gateway definition YAML and a certificate to access and expose the service on the service network.

8. Check the status of the gateway service:

   To check a service type gateway:

   $ systemctl --user status <gateway-definition-name>

   To check a podman type gateway:

   $ podman inspect

   To check a docker type gateway:

   $ docker inspect

   Note

   You can later remove the gateway using ./remove.py.

9. From the machine with cluster access, check the status of Skupper gateways:

   $ skupper gateway status
   Gateway Definition:
   ╰─ machine-user type:service version:1.5
      ╰─ Bindings:
         ╰─ mydb:3306 tcp mydb:3306 localhost 3306

   This shows that there is only one exposed service and that service is only exposing a single port (BIND). There are no ports forwarded to the local host.

Procedure

1. Create the service network router with a Kubernetes network policy:

   $ skupper init --create-network-policy

2. Check the site status:

   $ skupper status

   The output should be similar to the following:

   Skupper enabled for namespace 'west'. It is not connected to any other sites.

Procedure

1. Deploy your backend service.

2. Expose your backend deployment on the service network, enabling TLS.

   For example, if you want to expose a TCP service:

   $ skupper expose deployment <deployment-name> --port 443 --enable-tls

   Enabling TLS creates the necessary certificates required for TLS backends and stores them in a secret named skupper-tls-<deployment-name>.

3. Modify the backend deployment to include the generated certificates, for example:

   ...
       spec:
         containers:
         ...
           command:
           ...
           - "/certs/tls.key"
           - "/certs/tls.crt"
           ...
           volumeMounts:
           ...
           - mountPath: /certs
             name: certs
             readOnly: true
         volumes:
         - name: index-html
           configMap:
             name: index-html
         - name: certs
           secret:
             secretName: skupper-tls-<deployment-name>

   Each site creates the necessary certificates required for TLS clients and stores them in a secret named skupper-service-client.

4. Modify the frontend deployment to include the generated certificates, for example:

   spec:
     template:
       spec:
         containers:
         ...
           volumeMounts:
           - name: certs
             mountPath: /tmp/certs/skupper-service-client
         ...
         volumes:
         - name: certs
           secret:
             secretName: skupper-service-client

5. Test calling the service from a TLS enabled frontend.

Procedure

1. Set your session to use Skupper Podman:

   $ export SKUPPER_PLATFORM=podman

   To verify the skupper mode:

   $ skupper switch
   
   podman

2. Create a Skupper site:

   Use the following command to create a site where tokens are created to link on any network interface:

   $ skupper init

   Note

   By default, this command times out after 2 minutes for podman sites. You can increase the time with the --timeout option.

   The following output is displayed:

   It is recommended to enable lingering for <username>, otherwise Skupper may not start on boot.
   Skupper is now installed for user '<username>'.  Use 'skupper status' to get more information.

   Use the following command to start the site service at system start and persist over logouts:

   # loginctl enable-linger <username>

   By default, skupper init tries to include all IP addresses associated with local network interfaces as valid ingress hosts. You can use --ingress-host <IP/Hostname> to restrict token ingress to a specific network context:

   $ skupper init --ingress-host my-cloud-vm.example.com

   If you do not require that other sites can link to the site you are creating:

   $ skupper init --ingress none

   In this guide we assume you have enabled ingress using the first command. This allows you create tokens that allow links from every network interface on the host.

   Note

   When creating a token you can specify the ingress host.

   You can also restrict ingress to an IP address or hostname when initializing as described in the Skupper Podman CLI reference documentation.

3. Check the status of your site:

   $ skupper status
   Skupper is enabled for "<username>" with site name "<machine-name>-<username>" in interior mode. It is not connected to any other sites. It has no exposed services.

   Note

   You can only create one site per user. If you require a host to support many sites, create a user for each site.

Procedure

1. Generate a token on one site:

   $ skupper token create <filename>

   If you created the site without specifying an ingress-host, the token is valid for all network contexts. You can use --ingress-host <IP/Hostname> to restrict token ingress to a specific network context:

   $ skupper token create <filename> --ingress-host <IP/Hostname>

2. Create a link from the other site:

   $ skupper link create <filename>

Procedure

1. Make sure you are logged in as the user that created the site:

   $ skupper status
   Skupper is enabled for "<username>" with site name "<machine-name>-<username>".

2. Delete the site and all podman resources (containers, volumes and networks) labeled with "application=skupper":

   $ skupper delete
   Skupper is now removed for user "<username>".

Procedure

1. Determine which site in your service network is best to enable the console.

   Enabling the console also requires that you enable the flow-collector component, which requires resources to process traffic data from all sites. You might locate the console using the following criteria:

   • Does the service network cross a firewall? For example, if you want the console to be available only inside the firewall, you need to locate the flow-collector and console on a site inside the firewall.
   • Is there a site that processes more traffic than other sites? For example, if you have a frontend component that calls a set of services from other sites, it might make sense to locate the flow collector and console on that site to minimize data traffic.
   • Is there a site with more or cheaper resources that you want to use? For example, if you have two sites, A and B, and resources are more expensive on site A, you might want to locate the flow collector and console on site B.

2. Create a site with the flow collector and console enabled:

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

Procedure

1. Determine the Service Interconnect Console URL using the skupper CLI, for example:

   $ skupper status
   
   Skupper is enabled for namespace "west" in interior mode. It is not connected to any other sites. It has no exposed services.
   The site console url is:  https://skupper-west.apps-crc.testing

2. Browse to the Service Interconnect Console URL. The credential prompt depends on how the site was created using skupper init:

   • Using the --console-auth unsecured option, you are not prompted for credentials.
   • Using the --console-auth openshift option, you are prompted to enter OpenShift cluster credentials.
   • Using the default or --console-user <user> --console-password <password> options, you are prompted to enter those credentials.

3. If you created the site using default settings, that is skupper init, a random password is generated for the admin user.

   To retrieve the password the admin user for a Kubernetes site:

   +

   $ kubectl get secret skupper-console-users -o jsonpath={.data.admin} | base64 -d
   
   JNZWzMHtyg

   To retrieve the password the admin user for a Podman site:

   +

   $ cat ~/.local/share/containers/storage/volumes/skupper-console-users/_data/admin
   
   JNZWzMHtyg

1. Check the Sites tab. All your sites should be listed. See the Topology tab to view how the sites are linked.
2. Check that all the services you exposed are visible in the Components tab.
3. Click a component to show the component details and associated processes.

4. Click on a process to display the process traffic.

   Note

   The process detail displays the associated image, host, and addresses. You can also view the clients that are calling the process.

5. Click Addresses and choose an address to show the details for that address. This shows the set of servers that are exposed across the service network.

Procedure

1. Create a YAML file to define the site, for example, my-site.yaml:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: skupper-site
   data:
     name: my-site
     console: "true"
     console-user: "admin"
     console-password: "changeme"
     flow-collector: "true"

   The YAML creates a site with a console and you can create tokens from this site.

   To create a site that has no ingress:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: skupper-site
   data:
     name: my-site
     ingress: "none"

2. Apply the YAML file to your cluster:

   kubectl apply -f ~/my-site.yml

1. Create a YAML file defining the ConfigMap of the site you want to create.

   For example, create skupper-site.yaml that provisions a site with a console:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: skupper-site
     namespace: my-namespace
   data:
     console: "true"
     flow-collector: "true"
     console-user: "admin"
     console-password: "changeme"

   Note

   Currently, you must enable the console on the same site as you enable the flow collector.

   You can also create a site without a console:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: skupper-site
     namespace: my-namespace

2. Apply the YAML to create a ConfigMap named skupper-site in the namespace you want to use:

   $ kubectl apply -f skupper-site.yaml

3. Verify that the site is created by checking that the Skupper router and service controller pods are running:

   $ kubectl get pods
   
   NAME                                          READY   STATUS    RESTARTS   AGE
   skupper-router-8c6cc6d76-27562                1/1     Running   0          40s
   skupper-service-controller-57cdbb56c5-vc7s2   1/1     Running   0          34s

   Note

   If you deployed the Operator to a single namespace, an additional site controller pod is also running.

Procedure

1. Log in to the cluster using a cluster-admin account.

2. Download the CRD:

   $ wget https://raw.githubusercontent.com/skupperproject/skupper/1.5/api/types/crds/skupper_cluster_policy_crd.yaml

3. Apply the 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

4. To verify that a Skupper policy is active, use the skupper status command and check that the output includes the following line:

   Skupper is enabled for namespace "<namespace>" in interior mode (with policies).

1. Plan the CRD deployment for an appropriate time.

2. Search your cluster for sites:

   $ kubectl get pods --all-namespaces --selector=app=skupper

3. Document each service and resource exposed on the service network.
4. Install the CRD as described in Section 12.2, “Installing the Skupper policy CRD”. This step closes connections and removes all service network services and exposed resources.

5. If Skupper sites that were not created by cluster-admin exist in the cluster, you must grant permissions to read Skupper policies to avoid that site being blocked from the service network.

   For each site namespace:

   $ kubectl create clusterrolebinding skupper-service-controller-<namespace> --clusterrole=skupper-service-controller --serviceaccount=<namespace>:skupper-service-controller

   where <namespace> is the site namespace.

6. Create Skupper policy CRs as described in Section 12.4, “Creating Skupper policy CRs”
7. Recreate any services and exposed resources as required.

1. Section 12.4.1, “Implement a policy to allow incoming links”
2. Section 12.4.2, “Implement a policy to allow outgoing links to specific hosts”
3. Section 12.4.3, “Implement a policy to allow specific services”
4. Section 12.4.4, “Implement a policy to allow specific resources”

Procedure

1. Check the site status:

   $ skupper status --namespace west
   
   Skupper is enabled for namespace "west" in interior mode. It is connected to 2 other sites. It has 1 exposed services.

   The output shows:

   • A site exists in the specified namespace.
   • A link exists to two other sites.
   • A service is exposed on the service network and is accessible from this namespace.

2. Check the service network:

   $ skupper network status
   Sites:
   ├─ [local] a960b766-20bd-42c8-886d-741f3a9f6aa2(west)
   │  │ namespace: west
   │  │ site name: west
   │  │ version: 1.5.1
   │  ╰─ Linked sites:
   │     ├─ 496ca1de-0c80-4e70-bbb4-d0d6ec2a09c0(east)
   │     │  direction: outgoing
   │     ╰─ 484cccc3-401c-4c30-a6ed-73382701b18a()
   │        direction: incoming
   ├─ [remote] 496ca1de-0c80-4e70-bbb4-d0d6ec2a09c0(east)
   │  │ namespace: east
   │  │ site name: east
   │  │ version: 1.5.1
   │  ╰─ Linked sites:
   │     ╰─ a960b766-20bd-42c8-886d-741f3a9f6aa2(west)
   │        direction: incoming
   ╰─ [remote] 484cccc3-401c-4c30-a6ed-73382701b18a()
      │ site name: vm-user-c3d98
      │ version: 1.5.1
      ╰─ Linked sites:
         ╰─ a960b766-20bd-42c8-886d-741f3a9f6aa2(west)
            direction: outgoing

   Note

   If the output is not what you expected, you might want to check links before proceeding.

   The output shows:

   • There are 3 sites on the service network, vm-user-c3d98, east and west.
   • Details for each site, for example the namespace names.

3. Check the status of services exposed on the service network (-v is only available on Kubernetes):

   $ skupper service status -v
   Services exposed through Skupper:
   ╰─ backend:8080 (tcp)
      ╰─ Sites:
         ├─ 4d80f485-52fb-4d84-b10b-326b96e723b2(west)
         │  policy: disabled
         ╰─ 316fbe31-299b-490b-9391-7b46507d76f1(east)
            │ policy: disabled
            ╰─ Targets:
               ╰─ backend:8080 name=backend-9d84544df-rbzjx

   The output shows the backend service and the related target of that service.

   Note

   As part of output each site reports the status of the policy system on that cluster.

4. List the Skupper events for a site:

   $ skupper debug events
   NAME                         COUNT                                                          AGE
   GatewayQueryRequest          3                                                              9m12s
                                3     gateway request                                          9m12s
   SiteQueryRequest             3                                                              9m12s
                                3     site data request                                        9m12s
   ServiceControllerEvent       9                                                              10m24s
                                2     service event for west/frontend                          10m24s
                                1     service event for west/backend                           10m26s
                                1     Checking service for: backend                            10m26s
                                2     Service definitions have changed                         10m26s
                                1     service event for west/skupper-router                    11m4s
   DefinitionMonitorEvent       15                                                             10m24s
                                2     service event for west/frontend                          10m24s
                                1     service event for west/backend                           10m26s
                                1     Service definitions have changed                         10m26s
                                5     deployment event for west/frontend                       10m34s
                                1     deployment event for west/skupper-service-controller     11m4s
   ServiceControllerUpdateEvent 1                                                              10m26s
                                1     Updating skupper-internal                                10m26s
   ServiceSyncEvent             3                                                              10m26s
                                1     Service interface(s) added backend                       10m26s
                                1     Service sync sender connection to                        11m4s
                                      amqps://skupper-router-local.west.svc.cluster.local:5671
                                      established
                                1     Service sync receiver connection to                      11m4s
                                      amqps://skupper-router-local.west.svc.cluster.local:5671
                                      established
   IpMappingEvent               5                                                              10m34s
                                1     172.17.0.7 mapped to frontend-6b4688bf56-rp9hc           10m34s
                                2      mapped to frontend-6b4688bf56-rp9hc                     10m54s
                                1     172.17.0.4 mapped to                                     11m4s
                                      skupper-service-controller-6c97c5cf5d-6nzph
                                1     172.17.0.3 mapped to skupper-router-547dffdcbf-l8pdc     11m4s
   TokenClaimVerification       1                                                              10m59s
                                1     Claim for efe3a241-3e4f-11ed-95d0-482ae336eb38 succeeded 10m59s

   The output shows sites being linked and a service being exposed on a service network. However, this output is most useful when reporting an issue and is included in the Skupper debug tar file.

5. List the Kubernetes events for a site:

   kubectl get events | grep "deployment/skupper-service-controller"
   10m         Normal    ServiceSyncEvent               deployment/skupper-service-controller   Service sync receiver connection to amqps://skupper-router-local.private1.svc.cluster.local:5671 established
   10m         Normal    ServiceSyncEvent               deployment/skupper-service-controller   Service sync sender connection to amqps://skupper-router-local.private1.svc.cluster.local:5671 established
   10m         Normal    ServiceControllerCreateEvent   deployment/skupper-service-controller   Creating service productcatalogservice
   7m59s       Normal    TokenHandler                   deployment/skupper-service-controller   Connecting using token link1
   7m54s       Normal    TokenHandler                   deployment/skupper-service-controller   Connecting using token link2

   The output shows events relating to Kubernetes resources.

1. Check the link status:

   $ skupper link status --namespace east
   
   Links created from this site:
   -------------------------------
   Link link1 is connected

   A link exists from the specified site to another site, meaning a token from another site was applied to the specified site.

   Note

   Running skupper link status on a connected site produces output only if a token was used to create a link.

   If you use this command on a site where you did not create the link, but there is an incoming link to the site:

   $ skupper link status --namespace west
   
   Links created from this site:
   -------------------------------
   There are no links configured or connected
   
   Currently connected links from other sites:
   ----------------------------------------
   A link from the namespace east on site east(536695a9-26dc-4448-b207-519f56e99b71) is connected

2. Check the verbose link status:

   $ skupper link status link1 --verbose --namespace east
   
    Cost:          1
    Created:       2022-10-24 12:50:33 +0100 IST
    Name:          link1
    Namespace:     east
    Site:          east-536695a9-26dc-4448-b207-519f56e99b71
    Status:        Connected

   The output shows detail about the link, including a timestamp of when the link was created and the associated relative cost of using the link.

   The status of the link must be Connected to allow service traffic.

1. Check the status of Skupper gateways:

   $ skupper gateway status
   
   Gateway Definition:
   ╰─ machine-user type:podman version:1.5
      ╰─ Bindings:
         ╰─ mydb:3306 tcp mydb:3306 localhost 3306

   This shows a podman type gateway.

2. Check that the container is running:

   $ podman ps
   CONTAINER ID  IMAGE                                           COMMAND               CREATED         STATUS             PORTS                   NAMES
   4e308ef8ee58  quay.io/skupper/skupper-router:1.5             /home/skrouterd/b...  26 seconds ago  Up 27 seconds ago                          machine-user

   This shows the container running.

   Note

   To view stopped containers, use podman ps -a or docker ps -a.

3. Start the container if necessary:

   $ podman start machine-user

Procedure

1. Log into a namespace where a Skupper site has been initialized.

2. Check whether incoming links are permitted:

   $ kubectl exec deploy/skupper-service-controller -- get policies incominglink
   
   ALLOWED POLICY ENABLED ERROR                                                   ALLOWED BY
   false   true           Policy validation error: incoming links are not allowed

   In this example incoming links are not allowed by policy.

3. Check other policies:

   $ kubectl exec deploy/skupper-service-controller -- get policies
   Validates existing policies
   
   Usage:
     get policies [command]
   
   Available Commands:
     expose       Validates if the given resource can be exposed
     incominglink Validates if incoming links can be created
     outgoinglink Validates if an outgoing link to the given hostname is allowed
     service      Validates if service can be created or imported

   As shown, there are commands to check each policy type by specifying what you want to do, for example, to check if you can expose an nginx deployment:

   $ kubectl  exec deploy/skupper-service-controller -- get policies expose deployment nginx
   ALLOWED POLICY ENABLED ERROR                                                       ALLOWED BY
   false   true           Policy validation error: deployment/nginx cannot be exposed

   If you allowed an nginx deployment, the same command shows that the resource is allowed and displays the name of the policy CR that enabled it:

   $ kubectl  exec deploy/skupper-service-controller -- get policies expose deployment nginx
   ALLOWED POLICY ENABLED ERROR                                                       ALLOWED BY
   true    true                                                                       allowedexposedresources

1. Create the debug tar file:

   $  skupper debug dump my-site
   
   Skupper dump details written to compressed archive:  `my-site.tar.gz`

2. You can expand the file using the following command:

   $ tar -xvf kind-site.tar.gz
   
   k8s-versions.txt
   skupper-versions.txt
   skupper-router-deployment.yaml
   skupper-router-867f5ddcd8-plrcg-skstat-g.txt
   skupper-router-867f5ddcd8-plrcg-skstat-c.txt
   skupper-router-867f5ddcd8-plrcg-skstat-l.txt
   skupper-router-867f5ddcd8-plrcg-skstat-n.txt
   skupper-router-867f5ddcd8-plrcg-skstat-e.txt
   skupper-router-867f5ddcd8-plrcg-skstat-a.txt
   skupper-router-867f5ddcd8-plrcg-skstat-m.txt
   skupper-router-867f5ddcd8-plrcg-skstat-p.txt
   skupper-router-867f5ddcd8-plrcg-router-logs.txt
   skupper-router-867f5ddcd8-plrcg-config-sync-logs.txt
   skupper-service-controller-deployment.yaml
   skupper-service-controller-7485756984-gvrf6-events.txt
   skupper-service-controller-7485756984-gvrf6-service-controller-logs.txt
   skupper-site-configmap.yaml
   skupper-services-configmap.yaml
   skupper-internal-configmap.yaml
   skupper-sasl-config-configmap.yaml

   These files can be used to provide support for Skupper, however some items you can check:

   versions

   See *versions.txt for the versions of various components.

   ingress

   See skupper-site-configmap.yaml to determine the ingress type for the site.

   linking and services

   See the skupper-service-controller-*-events.txt file to view details of token usage and service exposure.

1. Delete your site or create a new site in a different namespace.

   Note all configuration and delete your existing site:

   $ skupper delete

   As an alternative, you can create a new namespace and configure a new site with optimized Skupper router performance. After validating the performance improvement, you can delete and recreate your original site.

2. Create a site with optimal performance CPU settings:

   $ skupper init --router-cpu 5

3. Recreate your configuration from step 1, recreating links and services.

1. Create a token on the AWS cluster site.
2. Create the link on the site inside the firewall.

Procedure

1. Navigate to the context where the service was exposed.

2. Delete the service:

   $ skupper service delete <service-name>

   where service-name is the name of the service you want to remove.

   Note

   TCP connections can remain active for an extended duration. After deleting the service, existing connections continue to communicate until the TCP connection is terminated. For example, if you exposed a database connection over the service network, and then delete the service. New database connections cannot be established. However, deleting the service does not affect existing connections. To terminate the existing connection, manually stop the database connection.

3. Check that the service is removed.

   $ skupper service status

   The service should not be listed.

   Note

   Typically, if the service is still listed, it is because you issued the delete command from the wrong site context. By default, when you expose a service from a site, that service becomes available on all other sites, however you can delete the service only from the original site context.