Update: This tutorial on Istio was updated for Rancher 2.0 here<\/a>.<\/p>\n One of the recent open source initiatives that has caught our interest Circuit breakers<\/a> Istio is Rancher includes and enterprise Kubernetes distribution makes it easy to helm repo add incubator http:\/\/storage.googleapis.com\/kubernetes-charts-incubator<\/p>\n Then you can simply run:<\/p>\n helm install -n istio incubator\/istio<\/p>\n OK, so lets try this thing out. So far all we have is plumbing. To kubectl apply -f <(istioctl kube-inject -f samples\/apps\/bookinfo\/bookinfo.yaml)<\/p>\n This deploys the kubernetes resources using kubectl while injecting some kubectl get services istio-ingress -o wide<\/p>\n This should show you the IP address of the istio ingress (under the http:\/\/$EXTERNAL_IP\/productpage<\/p>\n Try loading that in your browser. If everything worked you should see Now that we\u2019ve got our application working we can check out the built export POD_NAME=$(kubectl get pods –namespace default -l “component=istio-istio-grafana” -o jsonpath=”{.items[0].metadata.name}”)<\/p>\n kubectl port-forward $POD_NAME 3000:3000 –namespace default<\/p>\n You can then access Grafana at:
\nat Rancher Labs is Istio<\/em><\/a>, the micro-services
\ndevelopment framework. It\u2019s a great technology, combining some of the
\nlatest ideas in distributed services architecture in an easy-to-use
\nabstraction. Istio does several things for you. Sometimes referred to as
\na \u201cservice mesh\u201c, it has facilities for API
\nauthentication\/authorization, service routing, service discovery,
\nrequest monitoring, request rate-limiting, and more. It\u2019s made up of a
\nfew modular components that can be consumed separately or as a whole.
\nSome of the concepts such as \u201ccircuit breakers\u201d are so sensible I
\nwonder how we ever got by without them.<\/p>\n
\nare a solution to the problem where a service fails and incoming
\nrequests cannot be handled. This causes the dependent services making
\nthose calls to exhaust all their connections\/resources, either waiting
\nfor connections to timeout or allocating memory\/threads to create new
\nones. The circuit breaker protects the dependent services by
\n\u201ctripping\u201d when there are too many failures in a some interval of
\ntime, and then only after some cool-down period, allowing some
\nconnections to retry (effectively testing the waters to see if the
\nupstream service is ready to handle normal traffic again).<\/p>\n
\nbuilt with Kubernetes<\/a> in mind. Kubernetes is a
\ngreat foundation as it\u2019s one of the fastest growing platforms for
\nrunning container systems, and has extensive community support as well
\nas a wide variety of tools. Kubernetes is also built for scale, giving
\nyou a foundation that can grow with your application.<\/p>\nDeploying Istio with Helm<\/h2>\n
\nrun Istio. First, fire up a Kubernetes environment on Rancher (watch
\nthis
\ndemo<\/a>
\nor see our quickstart
\nguide<\/a> for
\nhelp). Next, use the helm chart from the Kubernetes Incubator for
\ndeploying Istio to start the framework\u2019s components. You\u2019ll need to
\ninstall helm, which you can do by following this
\nguide<\/a>.
\nOnce you have helm installed, you can add the helm chart repo from
\nGoogle to your helm client:<\/p>\n![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/08\/23130416\/istio-microservices-1024x612.png\")
<\/a>
\nA view in kube dash of the microservices that makeup Istio
\nThis will deploy a few micro-services that provide the functionality of
\nIstio. Istio gives you a framework for exchanging messages between
\nservices. The advantage of using it over building your own is you don\u2019t
\nhave to implement as much \u201cboiler-plate\u201d code before actually writing
\nthe business logic of your application. For instance, do you need to
\nimplement auth or ACLs between services? It\u2019s quite possible that your
\nneeds are the same as most other developers trying to do the same, and
\nIstio offers a well-written solution that just works. Its also has a
\ncommunity of developers whose focus is to make this one thing work
\nreally well, and as you build your application around this framework, it
\nwill continue to benefit from this innovation with minimal effort on
\nyour part.<\/p>\nDeploying an Istio Application<\/h2>\n
\nactually see it do something you\u2019ll want to deploy an Istio
\napplication. The Istio team have put together a nice sample application
\nthey call \u201dBookInfo<\/a>\u201d to
\ndemonstrate how it works. To work with Istio applications we\u2019ll need
\ntwo things: the Istio command line client, istioctl, and the Istio
\napplication templates. The istioctl client works in conjunction with
\nkubectl to deploy Istio applications. In this basic example,
\nistioctl serves as a preprocessor for kubectl, so we can dynamically
\ninject information that is particular to our Istio deployment.
\nTherefore, in many ways, you are working with normal Kubernetes resource
\nYAML files, just with some hooks where special Istio stuff can be
\ninjected. To make it easier to get started, you can get both istioctl
\nand the needed application templates from this repo:
\nhttps:\/\/github.com\/wjimenez5271\/rancher-istio<\/a>. Just clone it on your
\nlocal machine. This also assumes you have kubectl installed and
\nconfigured. If you need help installing that see our
\ndocs.<\/a> Now
\nthat you\u2019ve cloned the above repo, \u201ccd\u201d into the directory and run:<\/p>\n
\nistio specific values. It will deploy new services to K8 that will serve
\nthe \u201cBookInfo\u201d application, but it will leverage the Istio services
\nwe\u2019ve already deployed. Once the BookInfo services finish deploying we
\nshould be able to view the UI of the web app. We\u2019ll need to get the
\naddress first, we can do that by running<\/p>\n
\nEXTERNAL-IP column). We\u2019ll use this IP address to construct the URL to
\naccess the application. For example, my output with my local Rancher
\ninstall looks like: ![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/08\/23131711\/example-kubectl-output-getservices.png\")
<\/a>
\nExample output of kubectl get services istio-ingress -o wide
\nThe istio ingress is shared amongst your applications, and routes to the
\ncorrect service based on a URI pattern. Our application route is at
\n\/productpage so our request URL would be:<\/p>\n
\na page like this: ![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/08\/23130532\/bookinfo-istio-app-1024x452.png\")
<\/a>
\nSample application \u201cBookInfo\u201c, built on Istio<\/p>\nBuilt-in metrics system<\/h2>\n
\nin metrics system to see how its behaving. As you can see, Istio has
\ninstrumented our transactions automatically just by using their
\nframework. Its using the Prometheus metrics collection engine, but they
\nset it up for you out of the box. We can visualize the metrics using
\nGrafana. Using the helm chart in this article, accessing the endpoint of
\nthe Grafana pod will require setting up a local kubectl port forward
\nrule:<\/p>\n
\nhttp:\/\/127.0.0.1:3000\/dashboard\/db\/istio-dashboard<\/a> ![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/08\/23130627\/grafana-dash-1024x572.png\")
<\/a>
\nThe Grafana Dashboard with the included Istio template that highlights
\nuseful metrics Have you developed something cool with Istio
\non Rancher? If so, we\u2019d love to hear about it. Feel free to drop us a
\nline on twitter @Rancher_Labs<\/a>, or
\non our user slack.<\/p>\n