3.4. Using route-based deployment strategies

Procedure

1. Navigate to the Networking Routes page.
2. Click the Actions menu next to the route you want to edit and select Edit Route.
3. Edit the YAML file. Update the weight to be an integer between 0 and 256 that specifies the relative weight of the target against other target reference objects. The value 0 suppresses requests to this back end. The default is 100. Run oc explain routes.spec.alternateBackends for more information about the options.
4. Click Save.

1. Navigate to the Networking Routes page.
2. Click Create Route.
3. Enter the route Name.
4. Select the Service.
5. Click Add Alternate Service.
6. Enter a value for Weight and Alternate Service Weight. Enter a number between 0 and 255 that depicts relative weight compared with other targets. The default is 100.
7. Select the Target Port.
8. Click Create.

Procedure

1. To manage the services and corresponding weights load balanced by the route, use the oc set route-backends command:

   $ oc set route-backends ROUTENAME \
       [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

   For example, the following sets ab-example-a as the primary service with weight=198 and ab-example-b as the first alternate service with a weight=2:

   $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2

   This means 99% of traffic is sent to service ab-example-a and 1% to service ab-example-b.

   This command does not scale the deployment. You might be required to do so to have enough pods to handle the request load.

2. Run the command with no flags to verify the current configuration:

   $ oc set route-backends ab-example

   Example output

   NAME                    KIND     TO           WEIGHT
   routes/ab-example       Service  ab-example-a 198 (99%)
   routes/ab-example       Service  ab-example-b 2   (1%)

3. To alter the weight of an individual service relative to itself or to the primary service, use the --adjust flag. Specifying a percentage adjusts the service relative to either the primary or the first alternate (if you specify the primary). If there are other backends, their weights are kept proportional to the changed.

   The following example alters the weight of ab-example-a and ab-example-b services:

   $ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10

   Alternatively, alter the weight of a service by specifying a percentage:

   $ oc set route-backends ab-example --adjust ab-example-b=5%

   By specifying + before the percentage declaration, you can adjust a weighting relative to the current setting. For example:

   $ oc set route-backends ab-example --adjust ab-example-b=+15%

   The --equal flag sets the weight of all services to 100:

   $ oc set route-backends ab-example --equal

   The --zero flag sets the weight of all services to 0. All requests then return with a 503 error.

   注意

   Not all routers may support multiple or weighted backends.

Procedure

1. Create a new application, adding a label ab-example=true that will be common to all shards:

   $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA
   $ oc delete svc/ab-example-a

   The application is deployed and a service is created. This is the first shard.

2. Make the application available via a route, or use the service IP directly:

   $ oc expose deploymentconfig ab-example-a --name=ab-example --selector=ab-example\=true
   $ oc expose service ab-example

3. Browse to the application at ab-example-<project_name>.<router_domain> to verify you see the v1 image.

4. Create a second shard based on the same source image and label as the first shard, but with a different tagged version and unique environment variables:

   $ oc new-app openshift/deployment-example:v2 \
       --name=ab-example-b --labels=ab-example=true \
       SUBTITLE="shard B" COLOR="red" --as-deployment-config=true
   $ oc delete svc/ab-example-b

5. At this point, both sets of pods are being served under the route. However, because both browsers (by leaving a connection open) and the router (by default, through a cookie) attempt to preserve your connection to a back-end server, you might not see both shards being returned to you.

   To force your browser to one or the other shard:

   1. Use the oc scale command to reduce replicas of ab-example-a to 0.

      $ oc scale dc/ab-example-a --replicas=0

      Refresh your browser to show v2 and shard B (in red).

   2. Scale ab-example-a to 1 replica and ab-example-b to 0:

      $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0

      Refresh your browser to show v1 and shard A (in blue).

6. If you trigger a deployment on either shard, only the pods in that shard are affected. You can trigger a deployment by changing the SUBTITLE environment variable in either DeploymentConfig object:

   $ oc edit dc/ab-example-a

   or

   $ oc edit dc/ab-example-b