Skip to content

Commit

Permalink
added canary test
Browse files Browse the repository at this point in the history
  • Loading branch information
@VeerMuchandi
VeerMuchandi committed Oct 27, 2017
1 parent 9b5ff67 commit b4088dd
Show file tree
Hide file tree
Showing 4 changed files with 234 additions and 3 deletions.
98 changes: 98 additions & 0 deletions CanaryContentBasedRouting.md
View file
@@ -0,0 +1,98 @@
# Canary/Content based routing

Test the application in the browser. "Reviews" output is random each time you access the page.
* Sometimes it hits reviews v1 (No stars)
* Sometimes it hits reviews v2 (black stars)
* Sometimes it hits reviews v3 (red stars)

Default traffic from all users to reviews version v1

```
$ oc create -f create -f samples/bookinfo/kube/route-rule-all-v1.yaml
```

Look at the routerules that are created

```
$ oc get routerule
NAME KIND
details-default RouteRule.v1alpha2.config.istio.io
productpage-default RouteRule.v1alpha2.config.istio.io
ratings-default RouteRule.v1alpha2.config.istio.io
reviews-default RouteRule.v1alpha2.config.istio.io
```

Understand the the `reviews-default` routerule. Note the traffic goes to version reviews v1 by default. Test in browser and you'll see no stars now.

```
$ oc get routerule reviews-default -o yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
clusterName: ""
creationTimestamp: 2017-10-27T20:58:12Z
deletionGracePeriodSeconds: null
deletionTimestamp: null
name: reviews-default
namespace: bookinfo
resourceVersion: "6709"
selfLink: /apis/config.istio.io/v1alpha2/namespaces/bookinfo/routerules/reviews-default
uid: 8bad146c-bb59-11e7-9c32-1ad90b5af171
spec:
destination:
name: reviews
precedence: 1
route:
- labels:
version: v1
```

Redirect specific user to version v2 based on the content in the cookie

```
$ oc create -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml
```

An additional routerule is added.

```
$ oc get routerule
NAME KIND
details-default RouteRule.v1alpha2.config.istio.io
productpage-default RouteRule.v1alpha2.config.istio.io
ratings-default RouteRule.v1alpha2.config.istio.io
reviews-default RouteRule.v1alpha2.config.istio.io
reviews-test-v2 RouteRule.v1alpha2.config.istio.io
$ oc get routerule reviews-test-v2 -o yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
clusterName: ""
creationTimestamp: 2017-10-27T21:06:10Z
deletionGracePeriodSeconds: null
deletionTimestamp: null
name: reviews-test-v2
namespace: bookinfo
resourceVersion: "6905"
selfLink: /apis/config.istio.io/v1alpha2/namespaces/bookinfo/routerules/reviews-test-v2
uid: a89d1211-bb5a-11e7-9c32-1ad90b5af171
spec:
destination:
name: reviews
match:
request:
headers:
cookie:
regex: ^(.*?;)?(user=jason)(;.*)?$
precedence: 2
route:
- labels:
version: v2
```
Per this newly added rule, if the cookie has `user=jason`, traffic goes to reviews v2 (black stars) otherwise default applies.

Test by Signing in as user 'jason' in the browser. Use any password. You'll only see black starts i.e, reviews v2. If you sign out you will see no stars!!

**Summary:** Assume you created a new version of reviews service v2 and you want to test it as specific user before releasing it or making it generally available. You introduce it as a canary to specific users to test.
127 changes: 127 additions & 0 deletions DeployingSampleApplication.md
View file
@@ -0,0 +1,127 @@
# Deploying sample application

We will deploy the sample bookinfo application explained in the istiodocs [https://istio.io/docs/guides/bookinfo.html](https://istio.io/docs/guides/bookinfo.html). The instructions are more or less the same as kubernetes with some slight variations. Hence I have documented the openshift deployment process here.

Create a new project for the application

```
$ oc new-project bookinfo
Now using project "bookinfo" on server "https://127.0.0.1:8443".
You can add applications to this project with the 'new-app' command. For example, try:
oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git
to build a new example application in Ruby.
```

When we install the bookinfo application, the application pods have init containers whose `proxy_init` runs in privileged mode and adds `NET_ADMIN`
as shown here. You will find this in the individual `deployment` artifacts.

```
initContainers:
- args:
- -p
- "15001"
- -u
- "1337"
image: docker.io/istio/proxy_init:0.2.7
imagePullPolicy: IfNotPresent
name: istio-init
resources: {}
securityContext:
capabilities:
add:
- NET_ADMIN
privileged: true
```
These application pods current run as `default` service account in a project. Hence we have to provide `privileged` access to the `default` account. Eventually, these examples should change to not require privileged access. But in the meanwhile, here is how you can set `default` service account to `privileged` security context constraint (scc) in the `bookinfo` project/namespace.

```
$ oc adm policy add-scc-to-user privileged -z default -n bookinfo
```

Let's now deploy the `bookinfo` application. We are using `istioctl kube-inject` to add `Envoy` sidecar proxies to each of the kubernetes deployment yamls and using the resultant deployment yamls to create an application.

```
$ oc apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml)
service "details" created
deployment "details-v1" created
service "ratings" created
deployment "ratings-v1" created
service "reviews" created
deployment "reviews-v1" created
deployment "reviews-v2" created
deployment "reviews-v3" created
service "productpage" created
deployment "productpage-v1" created
ingress "gateway" created
```

Give a few mins for the container images to be pulled and for the pods to come up. Note all the components that are running.

```
$ oc get pods
NAME READY STATUS RESTARTS AGE
details-v1-1597718389-zztwb 0/2 Init:0/2 0 3m
productpage-v1-2620897829-1557j 0/2 Init:0/2 0 3m
ratings-v1-3229318905-5klb7 0/2 Init:0/2 0 3m
reviews-v1-359063641-xwd16 0/2 Init:0/2 0 3m
reviews-v2-1816415585-jd63g 0/2 Init:0/2 0 3m
reviews-v3-1743560369-kf4bf 0/2 Init:0/2 0 3m
$ oc get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
details 172.30.37.29 <none> 9080/TCP 2m
productpage 172.30.168.188 <none> 9080/TCP 2m
ratings 172.30.35.113 <none> 9080/TCP 2m
reviews 172.30.130.102 <none> 9080/TCP 2m
$ oc get ingress
NAME HOSTS ADDRESS PORTS AGE
gateway * 172.29.101.193 80 2m
```

Note that there is an ingress gateway for this application. To understand this let us describe the ingress.

```
$ oc describe ingress
Name: gateway
Namespace: bookinfo
Address: 172.29.251.55
Default backend: default-http-backend:80 (<none>)
Rules:
Host Path Backends
---- ---- --------
*
/productpage productpage:9080 (<none>)
/login productpage:9080 (<none>)
/logout productpage:9080 (<none>)
/api/v1/products productpage:9080 (<none>)
/api/v1/products/.* productpage:9080 (<none>)
Annotations:
Events: <none>
```

It shows that we can access product page at `/productpage` extension. This extension is for the Istio ingress i.e.,

```
$ oc get route -n istio-system istio-ingress
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
istio-ingress istio-ingress-istio-system.127.0.0.1.nip.io istio-ingress http None
```

So you can access the product page at the URL [http://istio-ingress-istio-system.127.0.0.1.nip.io/productpage](http://istio-ingress-istio-system.127.0.0.1.nip.io/productpage)

Familiarize with this application a little bit. Use it a few times. Go back an check the service graph at [http://servicegraph-istio-system.127.0.0.1.nip.io/dotviz](http://servicegraph-istio-system.127.0.0.1.nip.io/dotviz)
You will see that the graph as below:
![servicegraph](./images/servicegraph.jpeg)

Also notice the data collected by Prometheus and displayed on Grafana at [http://grafana-istio-system.127.0.0.1.nip.io/dashboard/db/istio-dashboard](http://grafana-istio-system.127.0.0.1.nip.io/dashboard/db/istio-dashboard)

We have application running now. It is now time to test the awesomeness of Istio.




Binary file added images/servicegraph.jpeg
View file
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
12 changes: 9 additions & 3 deletions readme.md
View file
@@ -1,14 +1,20 @@
# Istio on Openshift

This write up covers my notes on running Istio on OpenShift. As I test with different implementations of OpenShift, I'll add additional links here.
This write up covers my notes on running Istio on OpenShift. As I test with different implementations of OpenShift (such as minishift or a real openshift cluster), I'll add additional links here.

## Deploying Istio

* [Deploying Istio with `oc cluster up`](./DeployingIstioWithOcclusterup.md)
* Deploying Istio with minishift
* Deploying Istio with OpenShift Cluster
* Deploying Istio on OpenShift Cluster

## Infrastructure components on Istio
* [Deploy infrastructure components for metrics and tracing](./InstallInfrastructureComponents.md)

## Sample Application and Testing
* [Deploy Sample BookInfo Application](./DeployingSampleApplication.md)

For testing, you will run the same steps in [Istio Documentation](https://istio.io/docs/guides/intelligent-routing.html) except that you will replace `istioctl` with `oc`. As an example
instead of running `istioctl create -f samples/bookinfo/kube/route-rule-all-v1.yaml`, you will run `oc create -f samples/bookinfo/kube/route-rule-all-v1.yaml`

* Testing Canary, Content based routing [Istio Docs](https://istio.io/docs/tasks/traffic-management/request-routing.html#content-based-routing) [openshift commands](./CanaryContentBasedRouting.md)
* More tests to be added

0 comments on commit b4088dd

Please sign in to comment.