Questo contenuto non è disponibile nella lingua selezionata.

Chapter 2. Specifying link cost

When linking sites, you can assign a cost to each link to influence the traffic flow. By default, link cost is set to 1 for a new link. In a service network, the routing algorithm attempts to use the path with the lowest total cost from client to target server.

If you have services distributed across different sites, you might want a client to favor a particular target or link. In this case, you can specify a cost of greater than 1 on the alternative links to reduce the usage of those links.
Note
The distribution of open connections is statistical, that is, not a round robin system.
If a connection only traverses one link, then the path cost is equal to the link cost. If the connection traverses more than one link, the path cost is the sum of all the links involved in the path.
Cost acts as a threshold for using a path from client to server in the network. When there is only one path, traffic flows on that path regardless of cost.
Note
If you start with two targets for a service, and one of the targets is no longer available, traffic flows on the remaining path regardless of cost.
When there are a number of paths from a client to server instances or a service, traffic flows on the lowest cost path until the number of connections exceeds the cost of an alternative path. After this threshold of open connections is reached, new connections are spread across the alternative path and the lowest cost path.

Prerequisite

You have set your Kubernetes context to a site that you want to link from.
A token for the site that you want to link to.

Procedure

Create a link to the service network:
```
$ skupper link create <filename> --cost <integer-cost>
```
where <integer-cost> is an integer greater than 1 and traffic favors lower cost links.
Note
If a service can be called without traversing a link, that service is considered local, with an implicit cost of 0.
For example, create a link with cost set to 2 using a token file named token.yaml:
```
$ skupper link create token.yaml --cost 2
```

Check the link cost:

$ skupper link status link1 --verbose

The output is similar to the following:

 Cost:          2
 Created:       2022-11-17 15:02:01 +0000 GMT
 Name:          link1
 Namespace:     default
 Site:          default-0d99d031-cee2-4cc6-a761-697fe0f76275
 Status:        Connected

Observe traffic using the console.
If you have a console on a site, log in and navigate to the processes for each server. You can view the traffic levels corresponding to each client.
Note
If there are multiple clients on different sites, filter the view to each client to determine the effect of cost on traffic. For example, in a two site network linked with a high cost with servers and clients on both sites, you can see that a client is served by the local servers while a local server is available.

2.1. Exposing services on the service network from a namespace

After creating a service network, exposed services can communicate across that network.

The skupper CLI has two options for exposing services that already exist in a namespace:

expose supports simple use cases, for example, a deployment with a single service. See Section 2.1.1, “Exposing simple services on the service network” for instructions.
service create and service bind is a more flexible method of exposing services, for example, if you have multiple services for a deployment. See Section 2.1.2, “Exposing complex services on the service network” for instructions.

2.1.1. Exposing simple services on the service network

This section describes how services can be enabled for a service network for simple use cases.

Procedure

Create a deployment, some pods, or a service in one of your sites, for example:
```
$ kubectl create deployment hello-world-backend --image quay.io/skupper/hello-world-backend
```
This step is not Skupper-specific, that is, this process is unchanged from standard processes for your cluster.
Create a service that can communicate on the service network:
Deployments and pods
```
$ skupper expose [deployment <name>|pods <selector>]
```
where
- <name> is the name of a deployment
- <selector> is a pod selector
Kubernetes services
Specify a resulting service name using the --address option.
```
$ skupper expose service <name> --address <skupper-service-name>
```
where
- <name> is the name of a service
- <skupper-service-name> is the name of the resulting service shared on the service network.
StatefulSets
You can expose a statefulset using:
```
$ skupper expose statefulset <statefulsetname>
```
A StatefulSet in Kubernetes is often associated with a headless service to provide stable, unique network identifiers for each pod. If you require stable network identifiers for each pod on the service network, use the --headless option.
```
$ skupper expose statefulset  --headless
```
Note
When you use the '--headless" option, only one statefulset in the service network can be exposed through the address (routing key).
For the example deployment in step 1, you can create a service using the following command:
```
$ skupper expose deployment/hello-world-backend --port 8080
```
Options for the expose command include:
- --port <port-number>:: Specify the port number that this service is available on the service network. NOTE: You can specify more than one port by repeating this option.
- --target-port <port-number>:: Specify the port number of pods that you want to expose.
- --protocol <protocol> allows you specify the protocol you want to use, tcp, http or http2
Note
If you do not specify ports, skupper uses the containerPort value of the deployment.

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

2.1.2. Exposing complex services on the service network

This section describes how services can be enabled for a service network for more complex use cases.

Procedure

Create a deployment, some pods, or a service in one of your sites, for example:
```
$ kubectl create deployment hello-world-backend --image quay.io/skupper/hello-world-backend
```
This step is not Skupper-specific, that is, this process is unchanged from standard processes for your cluster.
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 the example deployment in step 1, you create a service using the following command:
```
$ skupper service create hello-world-backend 8080
```
Bind the service to a cluster service:
```
$ skupper service bind <service-name> <target-type> <target-name>
```
where
- <service-name> is the name of the service on the service network
- <target-type> is the object you want to expose, deployment, statefulset, pods, or service.
- <target-name> is the name of the cluster service
For the example deployment in step 1, you bind the service using the following command:
```
$ skupper service bind hello-world-backend deployment hello-world-backend
```

2.1.3. Exposing services from a different namespace to the service network

This section shows how to expose a service from a namespace where Skupper is not deployed.

Skupper allows you expose Kubernetes services from other namespaces for any site. However, if you want to expose workloads, for example deployments, you must create a site as described in this section.

Prerequisites

A namespace where Skupper is deployed.
A network policy that allows communication between the namespaces
cluster-admin permissions if you want to expose resources other than services

Procedure

Create a site with cluster permissions if you want to expose a workload from a namespace other than the site namespace:
Note
The site does not require the extra permissions granted with the --enable-cluster-permissions to expose a Kubernetes service resource.
```
$ skupper init --enable-cluster-permissions
```
To expose a Kubernetes service from a namespace other than the site namespace:
```
$ skupper expose service <service>.<namespace> --address <service>
```
- <service> - the name of the service on the service network.
- <namespace> - the name of the namespace where the service you want to expose runs.
For example, if you deployed Skupper in the east namespace and you created a backend Kubernetes service in the east-backend namespace, you set the context to the east namespace and expose the service as backend on the service network using:
```
$ skupper expose service backend.east-backend --port 8080 --address backend
```
To expose a workload from a site created with --enable-cluster-permissions:
```
$ skupper expose <resource> --port <port-number> --target-namespace <namespace>
```
- <resource> - the name of the resource.
- <namespace> - the name of the namespace where the resource you want to expose runs.
For example, if you deployed Skupper in the east namespace and you created a backend deployment in the east-backend namespace, you set the context to the east namespace and expose the service as backend on the service network using:
```
$ skupper expose deployment/backend --port 8080 --target-namespace east-backend
```

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 2. Specifying link cost

2.1. Exposing services on the service network from a namespace

2.1.1. Exposing simple services on the service network

2.1.2. Exposing complex services on the service network

2.1.3. Exposing services from a different namespace to the service network

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Rendiamo l’open source più inclusivo

Informazioni su Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links