-
Notifications
You must be signed in to change notification settings - Fork 43
Mission: Routing Istio
| Group | Owner |
|---|---|
Testing |
Lincoln Baxter, III |
| ID | Short Name |
|---|---|
|
|
This mission showcases using Istio’s dynamic traffic routing capabilities with a set of example applications designed to simulate a real-world scenario.
The primary objectives are:
-
Deploy a client UI application (client-service-consumer) and a load-balanced service (my-service) with two pods running different implementations (versions): service-a, and service-b.
-
Demonstrate creation of an Istio Ingress rule to expose the client UI.
-
Demonstrate that pods are load-balanced with equal weights by default, using OpenShift’s default service clustering mechanism.
-
Demonstrate that Istio can be used to dynamically re-balance deployed pods in a service using a RouteRule.
We will demonstrate an A/B route, where a consumer is given access to either Service A or Service B depending on runtime conditions dictated by the Istio routing rules.)
In a microservice topology (MST), a/b type deployments are useful for managing and mitigating a number of scenarios.
The problem of managing upgrades and rollouts of new functionality, for example, becomes increasingly complex due to the increased complexity of a microservices-based. E.g. The more services that participate in the architecture, the most likely it will be that services will need to be independently upgraded and patched - this results in parts of the system being unavailable unless traffic can be routed to alternate endpoints dynamically. The operations processes required to take down the entire system are not practical for systems beyond a simple design. By using A/B deployments, however, this risk can be controlled.
During upgrades/rollouts of any given individual service in an MST, the goal of an A/B deployment is to serve two versions (A and B) of a service in parallel, then divert traffic either incrementally or via a hard-cutover to the new version of the service once it becomes fully available. The older version remains running in case of deployment failure, and traffic can be restored to its original pattern if errors are detected.
There are several benefits to this integration/deployment pattern. This prevents outage windows, and makes avoiding “the all night deployment” possible because updates can more reliably occur during normal working hours without disrupting system function. Due to the ease with which traffic can be re-routed, A/B routing also helps limit the duration of outages due to system failure that would traditionally only be restored by rolling back the newly deployed service to the prior version entirely.
A/B testing is another example where A/B deployments and dynamic traffic routing are useful. A/B tests are used to validate a hypothesis (for performance, customer conversions, or stability, etc). Two versions of a service are again deployed in parallel, then the effectiveness of each is measured to decide which service meets the goals more effectively. The lesser effective service is eventually scaled down, and the more effective service scaled up to handle 100% of the load over time.
-
Istio
-
A/B deployments
-
Application routing
-
Runtime configuration changes
-
Hot deployment
-
Version control
-
Minishift is installed and running on a the developer’s environment, or the developer has access to an OpenShift instance that meets all prerequisites.
-
Developer has installed Istio 0.7.0 onto the Minishift/OpenShift instance.
-
Developer is logged in to Minishift/OpenShift with the Admin user.
Next, build and deploy the application using the Fabric8 Maven Plugin (FMP). Configuration for the 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 A/B testing or multi-versioned pods in a service.
mvn clean package fabric8:deploy -Popenshiftfind . | 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-bCreate a route rule to properly 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 Finally, access the application via the istio-system istio-ingress application URL. Run this 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:
Now it’s time to take a look at what this application does, and how it works.
Click "Invoke Service" in the client UI; do this several times. You will notice that the services are currently load-balanced at exactly 50%. This is not always desireable for an A/B deployment. Sometimes it is important to slowly direct traffic to a new service over time. In this case, we can supply an Istio RouteRule to control load balancing behavior:
oc create -f rules/ab-test-rule.ymlNote that 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.
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.
Congratulations! You now know how to direct traffic between different versions of a service using Istio RouteRules.
Questions Can Istio configuration be updated at runtime? Can we dynamically update Istio configuration from the application/Pod space/environment (e.g. from within the application itself)?