Istio is installed in two parts. The first part involves the CLI tooling that will be used to deploy and manage Istio backed services. The second part configures the Kubernetes cluster to support Istio.

Install CLI tooling

The following command will install the Istio 0.7.1 release.

curl -L http://assets.joinscrapbook.com/istio/getLatestIstio | sh -

After it has successfully run, add the bin folder to your path.

export PATH="$PATH:/root/istio-0.7.1/bin"

Configure Istio

The core components of Istio are deployed via istio.yaml.

kubectl apply -f istio/istio.yaml

This will deploy Pilot, Mixer, Ingress-Controller, and Egress-Controller, and the Istio CA (Certificate Authority). These are explained in the next step.

If you see errors such as unable to recognize "istio/istio.yaml": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2" then re-run the deployment.

Check Status

All the services are deployed as Pods. Once they're running, Istio is correctly deployed.

kubectl get pods -n istio-system

The previous step deployed the Istio Pilot, Mixer, Ingress-Controller, and Egress-Controller, and the Istio CA (Certificate Authority).

• Pilot - Responsible for configuring the Envoy and Mixer at runtime.

• Envoy - Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement and telemetry recording/reporting functions.

• Mixer - Create a portability layer on top of infrastructure backends. Enforce policies such as ACLs, rate limits, quotas, authentication, request tracing and telemetry collection at an infrastructure level.

• Ingress/Egress - Configure path based routing.

• Istio CA - Secures service to service communication over TLS. Providing a key management system to automate key and certificate generation, distribution, rotation, and revocation

The overall architecture is shown below.

To collect and view metrics provided by Mixer, install Prometheus Grafana and ServiceGraph addons.

Prometheus gathers metrics from the Mixer. kubectl apply -f istio/addons/prometheus.yaml

Grafana produces dashboards based on the data collected by Prometheus. kubectl apply -f istio/addons/grafana.yaml

ServiceGraph delivers the ability to visualise dependencies between services. kubectl apply -f istio/addons/servicegraph.yaml

Zipkin offers distributed tracing. kubectl apply -f istio/addons/zipkin.yaml

Check Status

As with Istio, these addons are deployed via Pods.

kubectl get pods -n istio-system

To showcase Istio, a BookInfo web application has been created. This sample deploys a simple application composed of four separate microservices which will be used to demonstrate various features of the Istio service mesh.

When deploying an application that will be extended via Istio, the Kubernetes YAML definitions are extended via kube-inject. This will configure the services proxy sidecar (Envoy), Mixers, Certificates and Init Containers.

kubectl apply -f <(istioctl kube-inject -f istio/bookinfo/bookinfo.yaml)

Check Status

kubectl get pods

When the Pods are starting, you may see initiation steps happening as the container is created. This is configuring the Envoy sidebar for handling the traffic management and authentication for the application within the Istio service mesh.

Once running the application can be accessed via the path /productpage.

https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/productpage

The ingress routing information can be viewed using kubectl describe ingress

The architecture of the application is described in the next step.

The BookInfo sample application deployed is composed of four microservices:

• The productpage microservice is the homepage, populated using the details and reviews microservices.
• The details microservice contains the book information.
• The reviews microservice contains the book reviews. It uses the ratings microservice for the star rating.
• The ratings microservice contains the book rating for a book review.

The deployment included three versions of the reviews microservice to showcase different behaviour and routing:

• Version v1 doesn’t call the ratings service.
• Version v2 calls the ratings service and displays each rating as 1 to 5 black stars.
• Version v3 calls the ratings service and displays each rating as 1 to 5 red stars.

The services communicate over HTTP using DNS for service discovery. An overview of the architecture is shown below.

The source code for the application is available on Github

One of the main features of Istio is its traffic management. As a Microservice architectures scale, there is a requirement for more advanced service-to-service communication control.

User Based Testing

One aspect of traffic management is controlling traffic routing based on the HTTP request, such as user agent strings, IP address or cookies.

The example below will send all traffic for the user "jason" to the reviews:v2, meaning they'll only see the black stars.

cat istio/bookinfo/route-rule-reviews-test-v2.yaml

Similarly to deploying Kubernetes configuration, routing rules can be applied using istioctl.

istioctl create -f istio/bookinfo/route-rule-reviews-test-v2.yaml

Visit the product page and signin as a user jason (password jason)

Traffic Shaping for Canary Releases

The ability to split traffic for testing and rolling out changes is important. This allows for A/B variation testing or deploying canary releases.

The rule below ensures that 50% of the traffic goes to reviews:v1 (no stars), or reviews:v3 (red stars).

cat istio/bookinfo/route-rule-reviews-50-v3.yaml

Likewise, this is deployed using istioctl.

istioctl create -f istio/bookinfo/route-rule-reviews-50-v3.yaml

Note: The weighting is not round robin, multiple requests may go to the same service.

New Releases

Given the above approach, if the canary release were successful then we'd want to move 100% of the traffic to reviews:v3.

cat istio/bookinfo/route-rule-reviews-v3.yaml

This can be done by updating the route with new weighting and rules.

istioctl replace -f istio/bookinfo/route-rule-reviews-v3.yaml

List All Routes

It's possible to get a list of all the rules applied using istioctl get routerules

With Istio's insight into how applications communicate, it can generate profound insights into how applications are working and performance metrics.

Generate Load

Make view the graphs, there first needs to be some traffic. Execute the command below to send requests to the application.

while true; do curl -s https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/productpage > /dev/null echo -n .; sleep 0.2 done

Access Dashboards

With the application responding to traffic the graphs will start highlighting what's happening under the covers.

Grafana

The first is the Istio Grafana Dashboard. The dashboard returns the total number of requests currently being processed, along with the number of errors and the response time of each call.

https://[[HOST_SUBDOMAIN]]-3000-[[KATACODA_HOST]].environments.katacoda.com/dashboard/db/istio-dashboard

As Istio is managing the entire service-to-service communicate, the dashboard will highlight the aggregated totals and the breakdown on an individual service level.

Zipkin

Zipkin provides tracing information for each HTTP request. It shows which calls are made and where the time was spent within each request.

https://[[HOST_SUBDOMAIN]]-9411-[[KATACODA_HOST]].environments.katacoda.com/zipkin/?serviceName=productpage

Click on a span to view the details on an individual request and the HTTP calls made. This is an excellent way to identify issues and potential performance bottlenecks.

Service Graph

As a system grows, it can be hard to visualise the dependencies between services. The Service Graph will draw a dependency tree of how the system connects.

https://[[HOST_SUBDOMAIN]]-8088-[[KATACODA_HOST]].environments.katacoda.com/dotviz

Before continuing, stop the traffic process with Ctrl+C

While Service Graph displays a high-level overview of how systems are connected, a tool called Weave Scope provides a powerful visualisation and debugging tool for the entire cluster.

Using Scope it's possible to see what processes are running within each pod and which pods are communicating with each other. This allows users to understand how Istio and their application is behaving.

Deploy Scope

Scope is deployed onto a Kubernetes cluster with the command kubectl create -f 'https://cloud.weave.works/launch/k8s/weavescope.yaml'

Wait for it to be deployed by checking the status of the pods using kubectl get pods -n weave

Make Scope Accessible

Once deployed, expose the service to the public.

pod=$(kubectl get pod -n weave --selector=name=weave-scope-app -o jsonpath={.items..metadata.name}) kubectl expose pod $pod -n weave --external-ip="[[HOST_IP]]" --port=4040 --target-port=4040

Important: Scope is a powerful tool and should only be exposed to trusted individuals and not the outside public. Ensure correct firewalls and VPNs are configured.

View Scope on port 4040 at https://[[HOST_SUBDOMAIN]]-4040-[[KATACODA_HOST]].environments.katacoda.com/

Generate Load

Scope works by mapping active system calls to different parts of the application and the underlying infrastructure. Create load to see how various parts of the system now communicate.

while true; do curl -s https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/productpage > /dev/null echo -n .; sleep 0.2 done