/istio-routing

Generated by the Red Hat Developer Launch (https://developers.redhat.com/launch)

Primary LanguageHTML

Purpose

Showcases Istio’s dynamic routing capabilities with a minimal set of example applications.

Prerequisites

Note
 The istiooc cluster up --istio=true command from this project perfectly satisfy the above requirements.

Environment preparation

    oc new-project istio-mutual-tls

CAUTION: In order for Istio automatic sidecar injection to work properly the following Istio configuration needs to be in place:

  1. The policy field is set to disabled in the istio-inject configmap of the istio-system namespace

  2. The istio-sidecar-injector MutatingWebhookConfiguration should not limit the injection to properly labeled namespaces

  3. Expose services and Istio ingress

    oc expose svc istio-ingress -n istio-system

    The aforementioned configuration is not needed when the cluster has been setup using istiooc

Build and deploy the application

With Fabric8 Maven Plugin (FMP)

Execute the following command to build the project and deploy it to OpenShift:

mvn clean package fabric8:deploy -Popenshift

Configuration for FMP may be found both in pom.xml and src/main/fabric8 files/folders.

This configuration is used to define service names and deployments that control how pods are labeled/versioned on the OpenShift cluster. Labels and versions are key concepts for creating load-balanced or multi-versioned pods in a service.

With Source to Image build (S2I)

Run the following commands to apply and execute the OpenShift templates that will configure and deploy the applications:

find . | grep openshiftio | grep application | xargs -n 1 oc apply -f

oc new-app --template=spring-boot-istio-ab-tests-booster-client-service-consumer -p SOURCE_REPOSITORY_URL=https://github.com/snowdrop/spring-boot-istio-ab-testing-booster -p SOURCE_REPOSITORY_REF=master -p SOURCE_REPOSITORY_DIR=client-service-consumer
oc new-app --template=spring-boot-istio-ab-tests-booster-service-a -p SOURCE_REPOSITORY_URL=https://github.com/snowdrop/spring-boot-istio-ab-testing-booster -p SOURCE_REPOSITORY_REF=master -p SOURCE_REPOSITORY_DIR=service-a
oc new-app --template=spring-boot-istio-ab-tests-booster-service-b -p SOURCE_REPOSITORY_URL=https://github.com/snowdrop/spring-boot-istio-ab-testing-booster -p SOURCE_REPOSITORY_REF=master -p SOURCE_REPOSITORY_DIR=service-b

Use Cases

Configure an ingress Route to access the application

  1. Create a RouteRule to forward traffic to the demo application.

    This is only necessary if your application accepts traffic at a different port/url than the default. In this case, our application accepts traffic at /, but we will access it with the path /example.

    oc create -f rules/client-route-rule.yml

  2. Access the application

    Run the following command to determine the appropriate URL to access our demo. Make sure you access the url with the HTTP scheme. HTTPS is NOT enabled by default:

    echo http://$(oc get route istio-ingress -o jsonpath='{.spec.host}{"\n"}' -n istio-system)/example/

    The result of the above command is the istio-system istio-ingress URL, appended with the RouteRule path.

Transfer load between two versions of an application/service

  1. Access the application as described in the previous use case

    1. Click "Invoke Service" in the client UI (Do this several times.)

    2. Notice that the services are load-balanced at exactly 50%, which is the default cluster behavior.

  2. Configure a load-balancing RouteRule Sometimes it is important to slowly direct traffic to a new service over time, or use alternate weighting. In this case, we will supply another Istio RouteRule to control load balancing behavior.

    Run the following command:

    oc create -f rules/ab-test-rule.yml

    The RouteRule defined in the file above uses labels "a" and "b" to identify each unique version of the service. If multiple services match any of these labels, traffic will be divided between them accordingly. Additional routes/weights can be supplied using additional labels/service versions as desired.

  3. Click "Invoke Service" in the client UI

    Do this several times. You will notice that traffic is no longer routed at 50/50%, and more traffic is directed to service version B than service version A. Adjust the weights in the rule-file and re-run the command above. You should see traffic adjust accordingly.

    Note
    		 It could take several seconds for the RouteRule to be detected and applied by Istio.

Congratulations! You now know how to direct traffic between different versions of a service using Istio RouteRules.